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).
Related
I am using the input event on a textarea to apply some logic that mutates the value of the textarea. This works as expected in local dev environment in a browser.
However, my target platform is android. On this platform, I'm noticing that instead of event.inputType being insertText, sometimes it is insertCompositionText. Android is apparently trying to be efficient by not actually mutating the textarea's value until you press space. How can I disable this behavior?
I found someone in a similar situation here who tried to use blur and focus events quickly. I can't use this because (1) it's hacky, hope there is a better solution (2) it resets the cursor position and degrades the user experience.
For reference, using ionic vue, but this is just an html <textarea>:
<textarea v-model="input" #input="onInput" />
onInput(event) {
console.log("onInput", event);
//more logic
}
You can't. That behavior comes from the keyboard, which is a separate app on Android. Not implementing the composing text functionality correctly will likely screw it up, breaking autocomplete, tap to correct, and the delete key, which all behave much differently due to composing text. It might even break normal typing- the idea of composing text is that it's temporary until you make it permanent. If so, when it does autocorrect on space it would assume the old stuff is deleted and recommit the entire word, causing duplication.
I was able to handle this issue by adding a hidden password input and route all the focus, events and value of my text input to the password input
The browsers will not show any predictive for password inputs and no insertCompositionText anymore
My Android app contains a custom slider control based on the SeekBar, and I want to attach a custom text phrase to my control to explain its use for Accessibility.
I have done this successfully using View.setContentDescription(text), and TalkBack correctly speaks the phrase when I request focus on my slider control from Activity.onCreate.
So far, so good. However, when I touch the control, which I believe sets the AccessibilityFocus on my Android API 16 test device, extra words are being added to the spoken phrase, i.e. '...seek control. 0 per cent'. I want to remove these additional words.
I have tried to eliminate them using event.getText().clear() in View.onInitializeAccessibilityEvent(event) without success. Echoing the event to LogCat reports the correct phrase in event.contentDescription and no entries in event.text, but the extra words appear both in the audio output from the device hardware and in the on-screen debug text displayed by Menu->Settings->Accessibility->TalkBack->Settings->Developer Settings->Display Speech Output.
Please can anyone suggest where the extra words are being added, and how to eliminate them?
Any constructive suggestions would be welcomed. Thanks.
Update
I can see that some Explore By Touch (initial single-tap) event on my custom control does not pass through either its onInitializeAccessibilityEvent or dispatchPopulateAccessibilityEvent methods as I am deliberately calling event.setContentDescription(null). Despite this, there is an AccessibilityEvent being generated with my custom control's ContentDescription, set in Activity.onCreate in code, plus the extra words I'm trying to eliminate.
I've also set an AccessibilityDelegate on my custom control's parent ViewGroup to give visibility of its onRequestSendAccessibilityEvent calls. This confirms that no event containing my ContentDescription is passing through.
This is very puzzling, and happens on both the emulator and real hardware with API 16. Any ideas?
You also need to override http://developer.android.com/reference/android/view/View.html#onInitializeAccessibilityNodeInfo(android.view.accessibility.AccessibilityNodeInfo)
and set the contentDescription there.
If you want to remove the 0%, I would try to change the class in AccessibilityNodeInfo/AccessibilityEvent:
http://developer.android.com/reference/android/view/accessibility/AccessibilityNodeInfo.html#setClassName(java.lang.CharSequence)
I believe that this is a bug in TalkBack, and have raised Google Eyes-Free issue #375, including example code.
Update: Google have now archived this. Link moved to: http://code.google.com/archive/p/eyes-free/issues/375
in my app I disabled the keyboard (I use now my custom keyboard) using this code:
editText.setInputType(InputType.TYPE_NULL);
Now, my problem is that the text cursor does not appear anymore in the edit text. What should I do? Any suggestion would be very appreciated.
There is an Issue opened in bug tracker Issue opened in bug tracker for this.
One of the users suggests the approach which works on "most" devices.
Briefly, all you have to do is call:
editText.setRawInputType(InputType.TYPE_CLASS_TEXT);
for your EditText view (after you called editText.setInputType(InputType.TYPE_NULL);).
You should probably also set:
editText.setTextIsSelectable(true);
in order for text to be selectable (though in does not seem to work properly with Samsung Galaxy SIII). This method is only available starting from HONEYCOMB (api11) so keep that in mind when developing for older Android versions.
Also it is stated that your EditText should not be the first view to receive focus when activity starts (if it is - just requestFocus() from another view). Though I (personally) have not experienced any problems with this.
Rather than just using a custom view for your custom keyboard, why not implement a full-fledged IME? That will solve your cursor problem, and even make your keyboard available outside your app (if you want).
This answer has a couple useful links if you want to do that:
How to develop a soft keyboard for Android?
I really wouldn't suggest this. Writing a good full fledged IME is really hard. In addition, users come to expect functionality from their keyboard (auto-correct, Swyping, next word prediction, the ability to change languages) that you won't have unless you spend months on the keyboard itself. Any app that wouldn't allow me to use Swype would immediately be removed (bias note: I worked on Swype android).
But if you want to integrate fully with the OS as a keyboard, you're going to have to write an InputMethodService. Your keyboard would then be selectable by the user in the keyboard select menu, and usable for any app. That's the only way to get full OS integration, otherwise you'll need to really start from scratch- writing your own EditView. Have fun with that, getting one that looks nice is decidedly non-trivial.
Also, setting input type null won't disable most keyboards. It just puts them into dumb mode and turns off things like prediction.
I tried the below answer and it worked, but take care that
1) EditText must not be focused on initialization
2) when your orientation changes while the user's focus is on the editText, the stock keyboard pops up, which is another "solvable" problem.
This was mentioned in a previous answer but take care that you MUST make sure your editText element do not get focus on instantiation:
https://code.google.com/p/android/issues/detail?id=27609#c7
#7 nyphb...#gmail.com
I have finally found a (for me) working solution to this.
First part (in onCreate):
mText.setInputType(InputType.TYPE_NULL);
if (android.os.Build.VERSION.SDK_INT >= 11 /*android.os.Build.VERSION_CODES.HONEYCOMB*/) {
// this fakes the TextView (which actually handles cursor drawing)
// into drawing the cursor even though you've disabled soft input
// with TYPE_NULL
mText.setRawInputType(InputType.TYPE_CLASS_TEXT);
}
In addition, android:textIsSelectable needs to be set to true (or set in onCreate) and the EditText must not be focused on initialization. If your EditText is the first focusable View (which it was in my case), you can work around this by putting this just above it:
<LinearLayout
android:layout_width="0px"
android:layout_height="0px"
android:focusable="true"
android:focusableInTouchMode="true" >
<requestFocus />
</LinearLayout>
I'm implementing an EditText that is used to obtain an rtsp URI from the user. Though it's not a huge issue functionally, I would like to disable the default behavior of the on screen keyboard where the state of the caps key is enabled for the first character of every sentence. From what I've gathered, this cannot be done in the XML via android:inputType flags. Any pointers as to how to do this programatically would be helpful.
I'd like to include the code, but the nature of the project prevents me from doing so. But I can say that nothing fancy is being done here. The EditText itself has no other input flags in use, and the only IME option in place is the flag to disable the Extract UI in landscape. The layout is implemented via XML, not programatically, so there are no custom classes or extensions in the mix either.
EDIT: The android:capitalize constant inherited from TextView isn't working. I'm specifically targetting 2.2 on a Galaxy Tab, so I don't know if this has something to do with Samsung's OS tweaks, or if it has something to do with the capitalize constant being deprecated.
EDIT 2: Swype is the culprit for not allowing the use of the capitalize constant. Does anyone know if there is a way to make Swype play nice without having to inform the end user to disable Swype?
You can use the inherited android:capitalize attribute from TextView. It accepts none (no caps, which is what you want), sentences (capitalizes the first word of each sentence), words (capitalizes the first letter of every word), and character (all caps).
Putting this in the XML for the EditText worked to stop Swype 2.17.59.15552.t100 from forcing capitals:
android:inputType="text|textEmailAddress"
Since EditText is subclass of TextView, you should be able to use the TextView:capitalize configuration to change the capitalization scheme of the view. It looks like you might only be able to set none in xml.
Is there any way to add words to the suggestions in the soft keyboard?
For a specific Edittext field i would like to add a list of names to the suggestions that pops up on top of the soft keyboard in android 2.0.
Does anyone know if this is possible?
Here is the source code of the soft keyboard.
If you go through the code, you will see that it uses a Suggest class which inside has different dictionaries.
If you want to add words for a specific EditText you would need to add and remove or change freq of a certain word from those dictionaries.
Some issues:
I couldn't find a way to get the InputMethodService's instance. (If you can, please answer my question here)
Android allows developers to program their own InputMethodService. I am working on one myself and my implementation doesn't use that dictionaries. So your feature will not work with my IME.
I would suggest using Auto Complete.
You can't add additional words to the ones the IME finds internally, however you can whole-sale supply your own completions via InputMethodManager.displayCompletions():
http://developer.android.com/reference/android/view/inputmethod/InputMethodManager.html#displayCompletions(android.view.View, android.view.inputmethod.CompletionInfo[])
This is what the auto complete text view uses to show its completions in the IME, when the IME is full screen so it can't be seen. Note that your app is still responsible for showing the completions itself, so they will be available to the user if the IME is not full screen.
(And sorry about the lack of documentation on that method.)