Yes, thank you. If I pursue this approach, I do want to try to make it as general as possible. I think the TextWatcher level will accomplish that, right?
On Dec 19, 1:24 am, "Dianne Hackborn" <[email protected]> wrote: > 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 <[email protected]> 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" <[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. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
