I have a custom view that extends EditText that has ToggleButtons for rich text editing. If I allow autocomplete, which I want to do, the indicator for the current word triggers my detection for style spans.
For example on most devices the autocorrect eligible word is an underline. As you type I have a text watcher that keeps track of the current styles that are applied to the text and adds new spannables if the user toggles a style button. This ends up detecting the underline and turning the toggle on.
I can write code to check if the underline toggle was set before we found the span. (I would actually need to do this for all my styles really since some devices use a background color to indicate the current autocorrect word.) But I'm unsure what I would use to trigger turning the toggle back to off. Check if they typed space? What happens when you select a suggested word?
Has anyone done this? Is there a way to ask if the span is from autocomplete or any other notifications to know the OS drew the span?
This is an old question, but just now I had a similar problem, namely eliminating the unwanted underline before converting the spans into HTML. I found the answer in the source to TextView.
There is a method TextView#clearComposingText() that will remove all styles applied by the IME during autosuggest, preserving all other styles. You could likely call it after every user keystroke, which would remove the underlines.
Hope this helps someone.
Related
I have been building relatively simple Android Keyboard from ground up following this Android SoftKeyboard sample. I can't seem to find any solution that would allow me to disable spell-checking functionality with my custom keyboard. Every text typed has a black underline indicating possible spell error even though I have not implemented spell-checking services.
Tried to find appropriate code fragment that disables spell-checking in Android/LatinIME but in vain.
Any tips are highly appreciated
The black underline is called composing text. Its used to show text that may be replaced by an autocorrect or other action- it isn't fully finished text yet. Its done by calling setComposingText. Instead of using that, use commitText and it won't use the underline version (and a dozen other differences under the hood).
Note that if you're exactly following the linked code you'll have to make a lot of other changes too, to move from word at a time to letter at a time input (composing text is completely replaced each time a new input is made, so you need to send down the entire word until you commitText of complete the composing text. SO you probably have a but of work to change it to use commitText).
I'm trying to apply ForegroundColorSpan with Spannable.EXCLUSIVE_INCLUSIVE flag when using TextWatcher at a specific index range.
With my device's default input (Samsung Keyboard) there are no issues and everything works as expected, however when using Google Keyboard as input that's a different story.
From my debugging I found that Google Keyboard places whole words, even if you change one character - I guess that's because of the word correction feature. As a result, if the Span was applied at some point in the word (even at the end), and a user enters more text, the span disappears.
The only exception is when the span is applied to the last character in the word, and the user enters a space ("ends" the word).
The workaround I found is to simply check if the input is a whole word, and whenever it is - apply the Span again. While that does work, it's not a very good solution since I need to set the caret at the end every time, and the fact that I have to re-apply the spin when it could be avoided (that's why I use Spannable.EXCLUSIVE_INCLUSIVE flag).
P.S. I tried other flags such as INCLUSIVE_INCLUSIVE and it sorta works - however it applies the span backwards as-well, resulting the Span to be applied to the entire word, rather than the index I specified.
Are there better solutions to this issue?
Okay so I found a different solution - turning off keyboard's input suggestion. Doing so prevents the input from being whole word and instead just a single character every time.
To do so I had to add textNoSuggestions flag to EditText's inputType attribute.
android:inputType="textNoSuggestions|<other_flags>"
I found more information about this inputType here: Turn off autosuggest for EditText?
I have an EditText in which the user can type freeform text, alongside programmatically created Spannable tokens that the user can delete but not modify.
Unfortunately, these tokens still get spell checked and underlined, even though my app does not let the user modify them. They do not contain English words.
Is there a way to turn off this new red underline?
Is there a way to turn off this new red underline only for certain text spans?
Adding the textNoSuggestions flag to the android:inputType field turns off the red line on 4.3, but also turns off the spelling suggestions that appear above the keyboard as the user types, which I want to keep. On 4.1 this flag does not disable spelling suggestions.
Thanks!
Hey guy's
First of all thanks for reading this.
I'm having trouble to find a way to change my EditText when I loose focus to it.
I would like it to be greyed out when this happens, but I don't want it to be disabled because the user can touch it and edit the text later.
Anyone?
Greetings!
You can set different colors to the text based on an OnFocusChangeListener
Another option is to set a style in xml. See this question for details: Android: change style when focused
To change the opacity, use setAlpha. In this answer I show it how to do it in an animation: Two questions about custom app ui's and AlphaAnimation
What I'd like to do is change the state (really, the background) of an EditText to reflect validity of its contents. E.g. if the user enters 999 where 999 is contextually invalid, the EditText should have a red border in place of the default orange border, likewise once the text is valid it should have a green border.
Methods I've explored:
Changing the style of the EditText programmatically via something like editor.setStyle(R.styles.SomeID). Seems to be impossible within android.
Adding custom states (state_valid, state_invalid) in R.attr, associating them with red/ green 9-patches, then calling drawable.setState() with one of these states. This worked in the sense that the state could be read back via getState(), but the border did not change colour.
Setting the background resource directly upon detection of (in)validity. This works ok, causing the correct visual effect, but seems a little hokey, and allows only one state (e.g. I have to manually check for whether the EditText is pressed, enabled etc).
Given limited UI real-estate I am hesitant to introduce a separate UI element to visually feedback the text's validity to the user, hence my desire to display it in the EditText itself.
So.. is this something that's even feasible? It seems like a fairly common use case, so has anyone achieved what I'm trying to do in a straightforward and elegant manner?
I would recommend changing the text color to indicate validity, rather than changing the color of the focus ring by any of the techniques you describe (of which only #3 seems practical).
Another possibility is to try setCompoundDrawablesWithIntrinsicBounds() to modify an icon on the left or right side of the EditText contents to indicate validity. I remember discussing this technique with somebody a few months back and forget if they got it working or not.
And, of course, another option is to not allow invalid input, via a custom input filter or listener or something.
Well, I'd just extend the EditText class and build the desired functionality on top ( using the third approach you are suggesting, because it works :-) ). Doing this, you have to walk the way only once, and are open to change your implementation once you know the best way ( I would have personally solved it also using the third approach, seems fine to me ).
i think a call to invalidateDrawable(yourDrawable) would work with approach number 2.
i didn't try .. but it make sense