[android-developers] Re: Puzzled by soft keyboard
Thanks Dianne, I now seem to be getting somewhere using addTextChangedListener() instead of setOnKeyListener(). Regards On May 21, 6:50 pm, Dianne Hackborn wrote: > 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Puzzled by soft keyboard
> OK Dianne, thank you for highlighting that the soft keyboard is not a > software keyboard. For me that is a novel insight, as I had hoped and > expected that the IME was (also, at the very least) meant to simply > emulate a software keyboard. Nope. Try using it in the contacts app to see the soft keyboard do some interesting transformations it understands the format of what you're typing in and will customize itself aggressively for that type of input. It's really a lot more flexible than a standard keyboard and only looks like a qwerty keyboard sometimes. Still, I understand your confusion - hopefully the workarounds given help you out. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Puzzled by soft keyboard
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 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" 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 -~--~~~~--~~--~--~---
[android-developers] Re: Puzzled by soft keyboard
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" 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! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Puzzled by soft keyboard
> 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! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Puzzled by soft keyboard
OK Dianne, thank you for highlighting that the soft keyboard is not a software keyboard. For me that is a novel insight, as I had hoped and expected that the IME was (also, at the very least) meant to simply emulate a software keyboard. Apparently it acts more like a newly defined virtual input peripheral then. Indeed a paradigm shift for me, as I simply want to keep on responding to individual key presses and nothing else. It would be absolutely fabulous to find some minimal example code of how to do just that - and only that - with the IME. The soft keyboard SDK sample is rather intimidating with its hundreds of lines of code for a rich editing interface, making it hard to extract minimum code as needed for just capturing individual key presses. I think other developers would also appreciate this. Thanks! On May 21, 10:43 am, Dianne Hackborn wrote: > It's not a software keyboard, it is an IME with a rich editing interface > back to the text editor, including things like showing candidates, > performing replacement, etc. For example, as you enter a word, each key you > enter is actually the IME delivering to the editor a new candidate text > string to replace the one currently displayed. This is actually a pretty > typical IME interface. > > It is certainly not a design oversight... though you can simply not give > the IME an InputConnection, in which case it falls back on delivering raw > key events (when it can... for some characters it simply won't be able to) > and gives the user a crummy editing experience. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[android-developers] Re: Puzzled by soft keyboard
It's not a software keyboard, it is an IME with a rich editing interface
back to the text editor, including things like showing candidates,
performing replacement, etc. For example, as you enter a word, each key you
enter is actually the IME delivering to the editor a new candidate text
string to replace the one currently displayed. This is actually a pretty
typical IME interface.
It is certainly not a design oversight... though you can simply not give
the IME an InputConnection, in which case it falls back on delivering raw
key events (when it can... for some characters it simply won't be able to)
and gives the user a crummy editing experience.
On Thu, May 21, 2009 at 12:46 AM, blindfold wrote:
>
> Thank you, Dianne. I must admit that I find this an utterly confusing
> paradigm. So now we have a *software* keyboard that makes a (novel!)
> distinction between what *it* considers "physical" keys and "non-
> physical" keys? All those digit and letter keys were physical enough
> on my ADP slide-out keyboard, and my EditText onKey() example works
> perfectly fine there with both digits *and* letters. As a physicist I
> am lost here. The user sees either a (truly) physical keyboard or an
> on-screen keyboard that gets physically touched, and why must there be
> a further split in key types for application programmers? This
> artificial split does not even match the non-Qwerty "numeric" keyboard
> of basic phones, because for instance the '#' hash/pound key also
> fails to raise a key event with the soft keyboard. In short, it all
> looks like a design oversight to me.
>
> To be concrete:
>
> With the ADP slide-out keyboard, pressing '7' gives keyCode 14, and
> pressing 'a' gives keyCode 29 in my example code. However, with the
> ADP soft keyboard, pressing '7' gives keyCode 14, but pressing 'a'
> gives... nothing, zilch, no key event at all.
>
> I may be naive but I find this an undesirable complication. IMO I
> should not have to add any special InputConnection code to recover
> proper default behavior here?
>
> Thanks
>
>
> On May 21, 3:55 am, Dianne Hackborn wrote:
> > Most text isn't delivered through key events, since key events represent
> > physical keys and not Unicode characters. The IME sends most of its text
> > through the editing with the InputConnection interface.
> >
> > On Wed, May 20, 2009 at 11:34 AM, blindfold >wrote:
> >
> >
> >
> >
> >
> > > Hi,
> >
> > > I have a regular EditText that nicely pops up the soft keyboard when
> > > the hardware keyboard is closed. Entering data also works fine and
> > > gets preserved by my app. However, when I try to track individual key
> > > presses using the following code,
> >
> > > EditText myedit;
> >
> > > // Only gets number keys??
> > > myedit.setOnKeyListener(new EditText.OnKeyListener() {
> > > @Override
> > > public boolean onKey(View v, int keyCode, KeyEvent event) {
> > > Log.i("OIC","keycode "+keyCode);
> > > KeyCharacterMap kmap = KeyCharacterMap.load(event.getDeviceId
> > > ());
> > > if (kmap.isPrintingKey(keyCode) && event.getAction() ==
> > > KeyEvent.ACTION_DOWN) {
> > >// Blah, blah
> > > }
> > > return false;
> > > }
> > > });
> >
> > > no key presses show up in LogCat *except* for number key presses
> > > (0-9). No letters, punctuation, or anything other than numeric digits
> > > and a few special keys such as Del and Return. Is this a bug or a
> > > feature? In this particular case I am only interested in individual
> > > alphabetic key presses, but the listener fails to report them. What's
> > > wrong?
> >
> > > I'm using the official Android 1.5 on my ADP.
> >
> > > Thanks
> >
> > --
> > Dianne Hackborn
> > Android framework engineer
> > hack...@android.com
>
> >
>
--
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
-~--~~~~--~~--~--~---
[android-developers] Re: Puzzled by soft keyboard
Thank you, Dianne. I must admit that I find this an utterly confusing
paradigm. So now we have a *software* keyboard that makes a (novel!)
distinction between what *it* considers "physical" keys and "non-
physical" keys? All those digit and letter keys were physical enough
on my ADP slide-out keyboard, and my EditText onKey() example works
perfectly fine there with both digits *and* letters. As a physicist I
am lost here. The user sees either a (truly) physical keyboard or an
on-screen keyboard that gets physically touched, and why must there be
a further split in key types for application programmers? This
artificial split does not even match the non-Qwerty "numeric" keyboard
of basic phones, because for instance the '#' hash/pound key also
fails to raise a key event with the soft keyboard. In short, it all
looks like a design oversight to me.
To be concrete:
With the ADP slide-out keyboard, pressing '7' gives keyCode 14, and
pressing 'a' gives keyCode 29 in my example code. However, with the
ADP soft keyboard, pressing '7' gives keyCode 14, but pressing 'a'
gives... nothing, zilch, no key event at all.
I may be naive but I find this an undesirable complication. IMO I
should not have to add any special InputConnection code to recover
proper default behavior here?
Thanks
On May 21, 3:55 am, Dianne Hackborn wrote:
> Most text isn't delivered through key events, since key events represent
> physical keys and not Unicode characters. The IME sends most of its text
> through the editing with the InputConnection interface.
>
> On Wed, May 20, 2009 at 11:34 AM, blindfold wrote:
>
>
>
>
>
> > Hi,
>
> > I have a regular EditText that nicely pops up the soft keyboard when
> > the hardware keyboard is closed. Entering data also works fine and
> > gets preserved by my app. However, when I try to track individual key
> > presses using the following code,
>
> > EditText myedit;
>
> > // Only gets number keys??
> > myedit.setOnKeyListener(new EditText.OnKeyListener() {
> > �...@override
> > public boolean onKey(View v, int keyCode, KeyEvent event) {
> > Log.i("OIC","keycode "+keyCode);
> > KeyCharacterMap kmap = KeyCharacterMap.load(event.getDeviceId
> > ());
> > if (kmap.isPrintingKey(keyCode) && event.getAction() ==
> > KeyEvent.ACTION_DOWN) {
> > // Blah, blah
> > }
> > return false;
> > }
> > });
>
> > no key presses show up in LogCat *except* for number key presses
> > (0-9). No letters, punctuation, or anything other than numeric digits
> > and a few special keys such as Del and Return. Is this a bug or a
> > feature? In this particular case I am only interested in individual
> > alphabetic key presses, but the listener fails to report them. What's
> > wrong?
>
> > I'm using the official Android 1.5 on my ADP.
>
> > Thanks
>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[android-developers] Re: Puzzled by soft keyboard
Most text isn't delivered through key events, since key events represent
physical keys and not Unicode characters. The IME sends most of its text
through the editing with the InputConnection interface.
On Wed, May 20, 2009 at 11:34 AM, blindfold wrote:
>
> Hi,
>
> I have a regular EditText that nicely pops up the soft keyboard when
> the hardware keyboard is closed. Entering data also works fine and
> gets preserved by my app. However, when I try to track individual key
> presses using the following code,
>
> EditText myedit;
>
> // Only gets number keys??
> myedit.setOnKeyListener(new EditText.OnKeyListener() {
> @Override
> public boolean onKey(View v, int keyCode, KeyEvent event) {
> Log.i("OIC","keycode "+keyCode);
> KeyCharacterMap kmap = KeyCharacterMap.load(event.getDeviceId
> ());
> if (kmap.isPrintingKey(keyCode) && event.getAction() ==
> KeyEvent.ACTION_DOWN) {
>// Blah, blah
> }
> return false;
> }
> });
>
> no key presses show up in LogCat *except* for number key presses
> (0-9). No letters, punctuation, or anything other than numeric digits
> and a few special keys such as Del and Return. Is this a bug or a
> feature? In this particular case I am only interested in individual
> alphabetic key presses, but the listener fails to report them. What's
> wrong?
>
> I'm using the official Android 1.5 on my ADP.
>
> Thanks
>
> >
>
--
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
-~--~~~~--~~--~--~---
