If you are having this text put into an EditText, there are all kinds of APIs on that to get callbacks when the text is modified. I would strongly recommend using those instead of any kind of raw event interception: keep in mind that there will be future devices with all kinds of keyboard configurations, using various key sequences to generate the actual characters (think 12 kit, 1/2 qwerty, etc) so unless you are using the full key character map class you likely not work there either.
If you leave your UI without an EditText in focus, the user can long press on the MENU key to force the soft keyboard to be displayed (or you can call the API to show it yourself), and then you are in the situation I already described: no InputConnection, so text coming from the IME is turned into raw key events, with lower fidelity support of IME features, but compatibility with existing apps that are looking for key events. On Thu, May 21, 2009 at 3:15 AM, blindfold <seeingwithso...@gmail.com>wrote: > > Hi Mark, > > > At the risk of sounding impertinent: why? > > My app is aimed at blind users, and individual key presses form a > basic means to quickly change operating mode during mobile use, such > as to select a color filter by pressing the first character of the > color name, or toggle the color identifier, while also speaking the > pressed key name for confirmation. Works fine with the G1 hardware > keyboard. One does not want to enter complete strings for such quick > mode changes, nor navigate a menu (too slow, too inconvenient). Touch > gestures might make an alternative, but for consistency, and because I > already use touch for other input functions, I just want to emulate > the functionality of phones that have a hardware keyboard, and thus > respond to individual key presses on the soft keyboard. I now added a > "dummy" EditText to my app's main screen as a means for the blind user > to pop up the soft keyboard and perform a key press, but was next > baffled to find that the soft keyboard functioned as a software > keyboard for digits, but not for letters, thus breaking my app on > phones that lack a hardware keyboard. Moreover, even when entering > strings, the blind user needs speech feedback for each character > pressed, to be notified of typos. I hope this clarifies why I am > seeking a simple way to pop up the soft keyboard and get events with > individual key presses for all the keys that show up on the screen, > including all digits and letters. Hopefully such basic functionality > is possible without adding a lot of dedicated IME code? Indeed I would > not mind using a touch event to pop up the soft keyboard instead of > using an EditText, as long as I can next get those individual key > presses. > > Thanks > > On May 21, 11:31 am, "Mark Murphy" <mmur...@commonsware.com> wrote: > > > as I simply want to keep on responding to individual key presses and > > > nothing else. > > > > At the risk of sounding impertinent: why? > > > > I can see wanting to handle key events outside an EditText, but inside an > > EditText, there may be better ways of achieving your application goals > > than detecting individual key events. > > > > Part of the problem is that you have given us a very narrow view on what > > you are trying to achieve. What sorts of key events are you trying to > trap > > and what behavior are you trying to do when those events are raised? > > Perhaps by giving people a broader perspective on what you are aiming > for, > > you can get answers that meet your user experience objectives while also > > integrate well with the IMEs. > > > > -- > > Mark Murphy (a Commons Guy)http://commonsware.com > > _The Busy Coder's Guide to Android Development_ Version 2.0 Available! > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
