I have not been saying that you shouldn't provide other ways for the user to navigate and your UI if you want, I have been saying that the implementation you have been discussing and posting here would break on pretty much anything besides the G1. At the end of the day, you get to design your app how you want, and I don't really care about that, I am just trying to point out to people when they do things that are making assumptions that can change in the future.
On Thu, Dec 18, 2008 at 10:09 PM, Keith Wiley <kbwi...@gmail.com> wrote: > > 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" <hack...@android.com> 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 <kbwi...@gmail.com> 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" <hack...@android.com> wrote: > > > > On Wed, Dec 17, 2008 at 9:37 AM, Keith Wiley <kbwi...@gmail.com> > 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 > > > > hack...@android.com > > > > > > 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 > > hack...@android.com > > > > 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 hack...@android.com 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 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 -~----------~----~----~----~------~----~------~--~---
