Re: requestFocus() logic very confusing in M5-RC14 - Kenny - com.googlegroups.android-developers

9 messages in com.googlegroups.android-developersRe: requestFocus() logic very confusi...

From	Sent On	Attachments
Jackkk	14 Feb 2008 11:16
Karl Rosaen	14 Feb 2008 13:48
Jackkk	15 Feb 2008 02:17
Karl Rosaen	19 Feb 2008 11:47
Jackkk	19 Feb 2008 15:31
Jackkk	19 Feb 2008 16:06
Karl Rosaen	20 Feb 2008 09:48
Kenny	23 Feb 2008 21:07
Anil	07 Mar 2008 08:48

Subject:	Re: requestFocus() logic very confusing in M5-RC14
From:	Kenny (yuye...@gmail.com)
Date:	02/23/2008 09:07:09 PM
List:	com.googlegroups.android-developers

Hi,

I just ran into a similar problem, hopefully I am not too late to get into the conversation. If I understand what have been said so far, is it correct to say that OnKeyListener would not do anything in touch mode? because the listener only works (or is only associated) with a view in focus?

Alternating between pad and touch for dialing may not be too practical, but there can be other useful applications. For example, if an app has a password screen on a touch centric UI, instead of having a View for the user to enter the password but only showing '*' anyway, that view can be omitted and have the user can enter the password blindly on the pad.

I have tried using focusableInTouchMode on a list associated with a CursorAdapter but that hasn't work. May I am doing something wrong.

On Feb 20, 12:49 pm, Karl Rosaen <kros...@google.com> wrote:

Hi Jack

About issue 2 - I think there would be several ideas concerning simultaneous use of keypad and touchscreen. It's not my current work that is so sensitive, but consider a game in landscape layout with physical keys under your right fingers and a virtual touch button or joystick under your left fingers! I actually was designing an UI for my app with the most efficient use when both keypad and touchpad are involved.

In this case, all you would need to do is make the View for the game focusable in touch mode.

Issue 3 - I really can't understand why it's so important to have a strong line between touch and keypad modes. We are still ending up making 2 clicks instead of 1 with the feeling that the first click was not registered and that's what everybody is annoyed about nowadays. It's like clicking "any key" to activate your keyboard each time after using mouse!

This is only enforced if the view's are not focusable in touch mode. There are plenty of applications that find this useful. Consider the phone dialer. What if each button remained focused after each press? Again, if you want your view to be focusable no matter what, just make it focusable in touch mode.

Just one example from the original dialer app in emulator: Enter a number "5968" and let's do it this way: Enter to Dialer by Touch: focus on textview touch "5" keypad "9": needs to click twice down to get "1" focused and the first impression is that the keypad is not working touch "6" keypad "8": click twice to get focus to "1" and then move down. I would have loved to continue my journey from "9" that was my last focused view with keypad.

I think alternating between d-pad and touch every other digit while dialing a phone number is an unlikely scenario. Were there no touch mode, as I mentioned before, each number would remained focus after each press, I don't think anyone would want that.

You make a good point about having to press down twice to get the 1 key focused. That is a problem with touch mode that is being fixed internally (and will be available in the next sdk refresh): if a view is focusable in touch mode (the edit text field that displays the digits in this example), and you are in touch mode, directional events should both cause an exit from touch mode *and* be dispatched to the focused view; there is no reason to have the directional key be consumed to exit focus mode, that only makes sense when there is nothing in focus (in which case something is given focus as the action).

but I know it's important in my app - very important!

Let me know if making particular views focusable in touch mode doesn't fix things for you.

I'm just very demanding about usability and user experience in everything I do, always been and always will be :)

No worries, the feedback is very helpful! Even if we don't agree on every point, you have helped identify a couple subtle but important problems with touch mode: 1)http://code.google.com/p/android/issues/detail?id=306 2) a key is consumed to exit touch mode even if there is a focused view (i just created an external issue for this that I will update when it's fixed internally, we actually just talked about this issue internally yesterday :)http://code.google.com/p/android/issues/detail?id=319

Karl

On Feb 19, 3:32 pm, Jackkk <ahvi...@hotmail.com> wrote:

Hi Karl!

Thanks with the issue 1 - this way it would really be ok! Until it's not fixed, I'll find a way around.

I think it's just a matter of freedom to develop whatever comes to our heads. My personal opinion is that those kind of options could be turned off by default but should be available if really needed for advanced development or crazy apps that change the world. On the responsibility of the programmer or designer only! If the usability design fails, then it's a bad software anyway and nobody will use it!

Issue 4 - I think this way it works fine by default, but once again - an option for overriding this functionality could be useful sometimes!

The result - with 2 things in a different way - no touch mode entry click and the focus on the last focused element in keypad mode I would have done 5 clicks less than now. This is probably not the needed functionality with dialer, but I know it's important in my app - very important!

Another issue from this example - if you exit the Keypadmode by touching a button the cursor in the textview is moved to the beginning of the textview. The same thing appears if you work only intouchmode, touch "Recent calls" and back to "Dialer", the cursor is moved to the beginning of the textview. This is probably someway related to the losefocus and receivefocus events. It should remain to the location where it was left.

Another issue - the textview should have an option to have a cursor blinking even if it's not focused. If not blinking, just visible someway. Because even if we are working around with the keypad to enter numbers or text, the logical cursor is on the textview at the position where the numbers are entered! Usually a less experienced user will start asking "where did the cursor go". People are used to typing with keyboards to the location of cursor. It's the same thing here I think!

I'm just very demanding about usability and user experience in everything I do, always been and always will be :)

With best regards

Jack

On Feb 19, 9:47 pm, Karl Rosaen <kros...@google.com> wrote:

Hi Jack,

Thanks for the extra info.

If I understand correctly, you've raised four specific issues here. I'm hoping that each can be resolved individually without having to provide another mode of focus in the framework (FocusableInTouchModeManually) that allows you do work around problems you are facing with the current focus handling.

1) the action of gaining focus and firing an onClickListener are not consistent

This is definitely a bug. Whether a view gains focus from being clicked on, and whether it fires its onClickListener should be consistent. If that were fixed, this problem would go away (you could click on a button, drag away, and the button would neither fire its onClickListener nor gain focus).

I've createdhttp://code.google.com/p/android/issues/detail?id=306

2) It is cumbersome to launch an activity by clicking a button, then give something focus via the d-pad

application by touching and start moving around with keys - first arrow click set's the emulator to keypad mode, the second arrow click gives focus to the first element and the third click moves the focus. The normal logic should be that the first element is focused and the first arrow click allready moves the focus. So one click instead of three!

Actually, the first arrow event will leave touch mode and give the first element focus, so to get focus to the second item, it would take two actions - hit down (leaves touch mode, gives first item focus) - hit down (focus searches below, gives focus to next item below)

So this really seems like another form of issue 3:

3) It isn't possible to be in touch mode, launch an activity, and have it start in non-touchmode

Our thought was that once users are interacting with the device by touching the screen, they will be doing so for a while, until further notice. So when a user launches an application by touching a button, that means they are interacting with the device via touch. The new activity shouldn't show navigational focus (highlight a button), because they can simply touch any button they wish to act on. In general, things that aren't focusable in touch mode are things that should only be focusable when the user isn't interacting with the device via touch, so we need to give them visual cues as to what has focus. Sort of a 'navigational focus'. Other views, like edit texts, can be focusable regardless of the mode, since they need to be focusable for reasons more than simply saying, "hey, if you click the center key, i'll get the input", so they are focusable in touch mode.

We are already discussing providing better naming and documentation about this as it has caused confusion with many developers. I may post to the forum with our ideas once we've settled on something.

...