Yeah, it sounds like the best way to implement this behavior is to avoid the Keyboard level enirely and do it by catching tab characters as they are appear in the edit text, removing them, reassigning the previous text to the box, and then performing the desired request focus on the next edit text. I appreciate the clarification on the distinction between the keyboard layer and the character-mapping layer.
...and to answer your question, yes, it is much easier to jump to the next edit text in the sequence by tabbing (and MUCH easier still with the enter key, which requires no alting whatsoever). I'm sorry this fact is bothersome to Google's official Android developers, but the greater efficiency and overall easy of use of this interaction hass consistently been my experience. Consider the following inefficiency that is imposed by using the trackball: You can't necessarily skip out of an edit text with the trackball in the desired way because the cursor may be in the middle of the edit text, in which case trackballing merely moves the cursor within the edit text. This is tedious, wasteful, and most seriously, jarring to the user because the program isn't doing what they naturally expect it to do, which is to jump focus on a tab. The trackball is problematic for many reasons. As stated, it doubles as a cursor mover and a focus mover, depending on whether it is at the beginning, middle, or end of the text. Second, I find myself constantly triggering trackball motions on the wrong axis. My attempts at horizontal movement often end up detected as vertical movements and vs/va, and as another post mentioned, your hands simultaneously support the device from the bottom while delivering detailed motions to the top. Adjusting one's hands to go constantly back and forth between the keyboard and the trackball is difficult unless you physically put the device down on a table. Now, I'm not complaining about the fact that it is small and has a small keyboard and must be gingerly held in one's hands. Those properties are simply inate to such a device. The complaint is the somewhat dogmatic prescription to developers and users of a user interaction which frankly doesn't work as well as might have been hoped for by the original designers. For that reason, it is perfectly fair for developers to attempt to design improved user interactions. I'm really sorry if the Android team at Google strongly disagrees with me on this point, but having used the devices for a while, I am simply reflecting my experiences. Jumping focus with a key is much easier than with the trackball. I will endeavor to write code that accommodates adaptable hardware. Thanks for the tip on the future keyboard discrepancies. Cheers! On Dec 18, 4:21 pm, "Dianne Hackborn" <[email protected]> wrote: > It is seriously easier for them to chord ALT+TAB (both on the left side of > the keyboard making it especially awkward) than to move the trackball? Well > whatever. > > But anyway, your code will break on pretty much any other future device than > the G1 -- those that have a different keyboard layout, and those that have a > soft keyboard (and in the future on a G1 when the user is typing with a soft > keyboard). And it could break in rather severe ways, if a device happens to > have ALT+Q mapped to something else. At the very least you should go > through the keymap to correctly determine if what they are pressing is > actually a TAB on their keyboard. > > > > On Thu, Dec 18, 2008 at 4:15 PM, Keith Wiley <[email protected]> wrote: > > > Well, I understand your point, but I'm writing a program in which the > > user might be doing lots of data entry into numerous text fields. In > > my own testing so far it is much much easier, less error prone, and > > generally more efficient to do this with the tab and return keys > > instead of the thumb wheel. Permitting tab and return key events to > > jump focus makes a lot of sense. If the API doesn't officially > > support it, that's okay, but I'm still going to provide it in my app. > > It's just too useful a functionality to dismiss. > > > Thanks though, I'll be sure to keep a close eye on how this user > > interaction is handled on different devices as Android branches out. > > I'm probably programming myself into corner on this one. > > > I suppose I could not do it at the keyboard level, but rather detect > > the introduction of a tab character into the edit text, remove it, and > > then jump the focus at that time...just brain storming. > > > On Dec 17, 4:35 pm, "Dianne Hackborn" <[email protected]> wrote: > > > On Wed, Dec 17, 2008 at 9:37 AM, Keith Wiley <[email protected]> wrote: > > > > Nevertheless, I am actually trying to implement a rather common UI > > > > mantra, where tab jumps to the next edit text (focus right or down or > > > > something logical like that). > > > > That is only common on desktop UIs. On phones, the user typically > > navigates > > > with a DPAD or trackball or scroll wheel. If we ever decide to support > > > desktop keyboards as a formal input mechanism in the UI, the platform > > will > > > take care of mapping tab or whatever to focus changes just like it does > > for > > > DPAD and trackball events. > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > [email protected] > > > > Note: please don't send private questions to me, as I don't have time to > > > provide private support. All such questions should be posted on public > > > forums, where I and others can see and answer them. > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > Note: please don't send private questions to me, as I don't have time to > provide private support. 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
