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 <seeingwithso...@gmail.com>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 <hack...@android.com> 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 <seeingwithso...@gmail.com
> >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
-~----------~----~----~----~------~----~------~--~---
