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
On Fri, 2008-12-19 at 01:24 -0800, Dianne Hackborn 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
Brian Beattie wrote:
Why do you say this? It seems to me that this would work on any device
with a physical keyboard and that Android does not yet provide an on
screen keyboard most Android devices will provide a physical keyboard.
If I understand the situation correctly, the
Keith Wiley wrote:
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
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 hack...@android.com wrote:
I have not been saying that you shouldn't provide other ways for the user to
On Dec 19, 5:10 am, Mark Murphy mmur...@commonsware.com wrote:
KeithWileywrote:
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
Keith Wiley wrote:
I admit that I haven't look at the note you are referring to,
WikiNotes is a program, for Android. It's available on the Market, and
the source code is in the apps-for-android project:
http://code.google.com/p/apps-for-android/
If your cursor is in the middle of the text
Yeah TextWatcher is reasonable. You'd end up with the behavior where if the
user enters a tab character through a soft keyboard that your app switches
focus, which might be surprising to users, but wouldn't be broken (as long
as you really don't want any tabs in the field).
On Fri, Dec 19, 2008
Thank you for your patience. I do appreciate your advice on the
matter. I will take it under consideration during development.
Cheers!
On Dec 19, 5:50 pm, Dianne Hackborn hack...@android.com wrote:
Yeah TextWatcher is reasonable. You'd end up with the behavior where if the
user enters a
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
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
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
Hmmm, that's very interesting. Thank you. As hinted in my original
post, I suspected there was some dichotomy between the physical
keyboard (and its KeyListener) and the higher-level characters being
delivered to the EditText. Thank you.
Nevertheless, I am actually trying to implement a
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
On Wed, 2008-12-17 at 16:35 -0800, Dianne Hackborn 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
ARgh...
I use the OnKeyListener to limit a editText to 8 characters ( as
described here :
http://androidblogger.blogspot.com/2008/11/editview-with-limited-number-of.html
)
Do you mean it is a bad idea ?
What would be the correct way to do that ?
Emmanuel
http://androidblogger.blogspot.com/
You are mixing physical key codes (which is what is delivered in KeyEvent
objects) with generated characters. You really don't want to do that,
because keyboards in different devices will have different (perhaps
radically different) key layouts.
Plus since there is no tab key in the G1, I think
17 matches
Mail list logo
