I have an OpenGL application that needs to show the soft keyboard for devices without physical ones for user input such as username or numbers in a few cases. In the case of numeric input, is there any way to show the numeric keypad instead of the alphabetic keyboard? I'm not using any text edit fields or anything, just the InputMethodManager:
((InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE)).showSoftInput(glView, InputMethodManager.SHOW_FORCED);
The only method I've found that looks remotely helpful is InputMethodManager.setInputMethod but that takes an IBinder token and a String id, neither of which is explained very well in the documentation. I get the impression that it's not the right way to go, though.
If I were using an edit field, it would be simple and obvious, and I've found dozens of answers for that, but that's not what I'm doing, because it's an OpenGL game, so I have to just displaying the keyboard manually as above.
Probably not the answer you are looking for since it is more of a hack than a real solution, but a few things come to mind that might work (that is if you can't get a real solution).
An EditText with View.INVISIBLE set. Although, you might not be able to set focus here.
Put an EditText behind your GLSurfaceView and focus it. So it’s technically visible (from a code standpoint) but invisible to the user.
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
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 designing my first Android IME and am a bit overwhelmed. My goals are accessibility-related, and as such I wonder if perhaps I'm trying things with the IME framework that just aren't possible. I've taken the default softkeyboard example and have it working along with some of my modifications, so I've definitely understood at least some of this, but there isn't a whole lot of documentation on some of the things I'm attempting. Here's what I mean:
Currently, Android phones with touchscreen-only keyboards are inaccessible. I currently have an accessible touchscreen keyboard using methods similar to those used in IOS/VoiceOver, so that part of the project is done and fairly straight-forward to accomplish in the IME framework.
Currently, Android's accessibility API doesn't provide accessible feedback for navigating text fields. That is, with an Android screen reader loaded, if you type the word "this", you'll hear individual characters spoken as you type them, but if you then try left-arrowing over the "s", that isn't spoken. So I want to trap movements and provide spoken feedback for the elements navigated past. Here's where I start encountering problems.
I currently have speech feedback for left and right arrowing, using getCurrentInputConnection.getTextBeforeCursor(1, 0) for arrowing left, and a similar call for arrowing right. This gets the character currently under the cursor after the movement is processed, and all is good.
My challenge, though, comes when arrowing up and down between lines. Ideally, I'd like to grab the current line of text and speak that, but I don't see any way to do that. The only thing I can think of is some combination of getTextBefore/AfterCursor(Integer.MAX_VALUE, 0) and combining those values, determining the current line by filtering for the previous and next \n. Is there another way--getting the entire text content of the field as a single block of text and using the cursor position to determine which piece of that text represents the current line? I'm seeing something about extracted text in the various input method classes, and it seems like there may be a way to monitor that, but I don't know if that is at all useful to me (I.e. would that return the entire field content?)
My next goal is providing standard text navigation capabilities. Android accessibility doesn't currently include touchscreen exploration, so it is impossible to otherwise scroll a large block of text. I don't necessarily expect folks to write novels on their phones, but I'd like to provide quick gestures or commands to move up/down paragraphs, and to the top/bottom of longer fields. Does the IMF provide methods for cursor movement, or is that outside of its authority?
Honestly, I didn't get the first part :(
For your second question, you will need to handle it by hand.
For instance, to add a key with a down drawable and make it work you will need to:
In the onKey method check for the code.
If it's 20, you should do a sendDownUpKeyEvents of that key event.
I'd like to limit the text length of EditText widget,
And if user type more charactes than the limited length,
I want to show a kind of warning popup, however I can't show popup.
The problem is that we can't show popup while typing,
Probably, many people think a way of utilizing OnKeyListener or OnKeyDown.
But, when the word is composing, nothing come into OnKeyListener or OnKeyDown,
So, we can't show popup when we want to.
Is there anyone who have smart idea to solve this problem?
You should be able to remove focus from the widget, and show your message.
InputMethodManager imm = (InputMethodManager)getSystemService(Context.INPUT_METHOD_SERVICE);
imm.hideSoftInputFromWindow(editTextField.getWindowToken(), 0);
OnKeyboardActionListener is for implementing software keyboards.
OnKeyListener and OnKeyDown do not get called, as you have discovered, when using a software keyboard. They only get called when using a hardware keyboard, which many Android devices don't even have.
I assume what you are trying to do is capture key events as they are occurring in an EditText area. Your best bet in this case, in order to handle both software keyboard input and hardware keyboard input, is to register a TextWatcher via the addTextChangedListener() method.
Note that on phones with Android 2.1 and later, such as the Nexus One, people have the option of using speech recognition to input text into your EditText instead of typing the text. When they do that you may get full words, or even full sentences, entered all at once. So you need to check the entire contents of the EditText field when there is a change to the contents.
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.)