I'm dealing with a phone that has no physical keyboard and I'm using my own custom view for rendering. The device I'm working with, by default, seems to be in a T9 type entry mode where it suggests blocks of text. However, it never sends me the actual key events.
How do I tell whatever soft-keyboard that pops up to enter 'dumb' key event sending mode?
The InputMethodManager has a "isAcceptinText()" call which would tell me if it's in event-sending mode, but not a method to set it. Digging through the documentation hasn't produced any insight. How do I tell the input manager that I only want key events?
I think this page has pretty much all there is to say on Android Input method control: Android - Onscreen Input Methods
Related
I am unable to get key events from /dev/input/event1. What i'm able to filter out from its output is absolute X and Y touch coordinates from event code 53 and 54. I'm confused why there's no output with event code 1 when i type on my soft keyboard. I want to know which key user presses and with how much pressure. Hope you understand my problem.
I'm on rooted Samsung Galaxy S4.
Because the soft keyboard doesn't work like that. It isn't a part of the OS, its an application. So the keyboard app will be given touch events, and it will call java functions to tell the main app what was pressed. It doesn't go through hardware input channels at all after the press. The OS doesn't know what keys are where, ever.
Most keyboards don't even generate key events- they generate word at a time output via commitText.
Basically, you can't do what you want in the way you want. The only way to know what keys were pressed, without altering the OS, is to be on the other side of the InputConnection processing commands from the InputMethodService (keyboard).
I have written a custom InputConnection by extending android's BaseInputConnection. I used to get commitText() when the user presses Enter Key. But recently with Google Keyboard, this doesn't happen. Google Keyboard sends sendKeyEvent() with the parameter being enterKeyUp and enterKeyDown events. However, I don't get the predicted text, as I used to get in commitText(). How can I get the predicted text on pressing EnterKey in Googke Keyboard?
Did they actually have a composing region? If not they may have decided no commit text was necessary. Or did you tell them your input type was NULL? If so, they may have gone into dumb mode and sent everything as key events.
They also may have called FinishComposingText instead, which tells the editor that the existing text is good (no correction). But its generally not a good idea to assume a certain action will come from a certain event because keyboards are always working around bugs in bad input connection implementations to get the effect they want. Just implement InputConnection as best you can and do what it says, rather than expect certain events at certain times.
I am developing an application that has to listen for input from a hardware QR Code Scanner, and Card Swiper (both HID devices). I want to listen for input and evaluate the input. I was thinking of TextArea input that constantly has focus but I would rather not do that. Is there a simple way any one can think of to have some sort of event listener that is always listening on for input. Also, is there any other way of listening on ports in Android such as /dev/hidraw1...etc? I am able to get the input fine via in a text-area but would be great to listen from a specific device as well.
The only thing that pops in my head is trying to write a native module that implements intent-filters to launch a BroadcastReciever that will take the input and pass it back to your app.
What I ended up doing was actually creating a hidden input field that always has focus and blurring it on input. Listening to the onReturn event on the input ran a onHidInput function, which blurred the input (lost focus), disabled it and processed the data, than gave focus on result. I was originally doing on change but that did every character input when the scan or swipe happened, So I was able to program the devices so they contained a carriage return after input, which allowed me to listen to the onReturn event and get the entire data to process.
I am writing an android app which will record the frequency and timestamps of when a user is using their keyboards (soft or hard) (Example: a parent checking to see if their child was texting during school by giving them timestamps and frequency of key presses). This wouldn't need to know what was being typed, just when something was typed. It would also need to function regardless of what app was using the keyboard.
This is not possible, except perhaps via custom firmware.
I'd like to know how the key event is handled in Android platform.
From 'when user type key 'a' on software keyboard',
To 'view draw the character 'a' on itself'.
Probably, the key event is generated by IME,
And it will be sent to parent view,
Finally, view(such as EditText) displays chracters.
Please somebody explains about these entire key event handling process.
Take a look at this article: http://developer.android.com/resources/articles/creating-input-method.html
Basically, you can either manually send KeyEvents or you can manually edit and commit text around the cursor in the application's Input View.
These are all done via your IME's InputConnection.
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.