[android-developers] Re: How to simulate a (missing) DPAD
OK, I've got it working, and in a rather straightforward manner.
Although dispatchKeyEvent() for some reason does not always determine
which UI element gets focus, it turned out that the UI element
actually does have a focus that one can in onKeyDown() reliably
perform a hasFocus() for after having done setFocusable(),
setFocusableInTouchMode() on all UI elements and a requestFocus(),
requestFocusFromTouch() on one element. Next, after putting all UI
elements like radiobuttons, checkboxes and editboxes in (for instance)
arrays, one can assign focus to the previous or next element when the
volume up or down key is pressed, thus hard-coding in what order UI
elements are traversed. Not very elegant, but thus far it works
reliably (no strange dependencies on whether a view is scrollable),
does the accessibility job for me in all activities, and it did not
require a major program overhaul. Tested on Android 1.6 and 2.2. It is
a bit like defining the tab order when programming for Microsoft
Windows. The key thing was to discard use of dispatchKeyEvent()
altogether and "manually" do what dispatchKeyEvent() was supposed to
do in terms of moving focus to a next UI element for a generated
KeyEvent.KEYCODE_DPAD_DOWN and KeyEvent.KEYCODE_DPAD_UP.
Thanks
On Dec 17, 10:06 am, Dianne Hackborn wrote:
> I doubt you will get this to work correctly, because you are doing this
> after parts of the framework that deal with things like going in and out of
> touch mode have seen the events.
>
> Why are you doing this? If a device doesn't have a DPAD, the user isn't
> going to think to use the volume keys to navigate focus(!!). You should be
> giving them a good touch-based UI.
>
> On Fri, Dec 17, 2010 at 12:38 AM, blindfold wrote:
>
>
>
> > For Android phones that lack a physical d-pad or trackball (e.g.
> > Alcatel OT-980, Motorola Droid Pro), I am trying to remap the physical
> > up and down volume keys to simulated up and down d-pad keys using code
> > like
>
> > �...@override
> > public boolean onKeyDown(int keyCode, KeyEvent event) {
> > if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
> > KeyEvent ke = new KeyEvent(KeyEvent.ACTION_DOWN,
> > KeyEvent.KEYCODE_DPAD_UP);
> > dispatchKeyEvent(ke);
> > return true;
> > }
> > return super.onKeyDown(keyCode, event);
> > }
>
> > Although this works fine with a ListView and with activity views that
> > become scrollable because they are too large to fit on the physical
> > screen, it somehow does not work at all for activity views that remain
> > small enough to fit on the screen. I can test this by increasing the
> > number of radio buttons in some activity view and then see how the
> > above key remapping begins to work fine as soon as there are more
> > controls than fit on the screen. I have tried all sorts of things with
> > setting focus after making things focusable using setFocusable(true),
> > setFocusableInTouchMode(true), requestFocus(), requestFocusFromTouch()
> > and so on, but nothing seems to help. The above onKeyDown() executes
> > in all relevant cases as shown by my Log.i() output, but it is the
> > dispatchKeyEvent() that in the described cases does nothing. All my
> > activity views are surrounded by in the XML
> > of their respective layouts. More about the context of this problem at
>
> >http://groups.google.com/group/eyes-free-dev/browse_thread/thread/374...
> > (eyes-free-dev list).
>
> > So the above code works "sometimes", but I need a reliable/general
> > solution. How can one reliably remap physical keys to perform key
> > functions for which there are no physical keys on the Android device?
>
> > Thanks!
>
> > --
> > 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
>
> --
> 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, and so won't reply to such e-mails. 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
[android-developers] Re: How to simulate a (missing) DPAD
Hi Brill, you may be right in hindsight, but key remapping seemed like such a simple and effective countermeasure that I expected it to work, and it would have made more Android phone types accessible to blind users. Alas... On Dec 17, 3:04 pm, Brill Pappin wrote: > I'm not sure that is going to work all that well for you, but instead of > emulating the DPAD, can you simply listen for the keys you are trying to > remap instead of remapping them? > > I think its great that you are trying to solve a problem for a user that is > having trouble with your app because of an unusual circumstance... however I > also feel that the user in question should maybe take that problem up with > whoever they got the phone from and get a new phone; you may be willing to > make an effort, but most apps won't, so they really have the wrong phone. > > - Brill -- 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
[android-developers] Re: How to simulate a (missing) DPAD
Hi Mark, walking the View tree with getLocationOnScreen() while retrieving element labels might be possible, and is a good idea in itself, but this is more the kind of thing that one would try for a generic accessibility layer, such as for a screen reader that works across all apps (currently limited by security restrictions), or as part of the OS. For a single app it may be too much work for what should be a temporary app-specific solution. Perhaps I am pessimistic, but my estimate is that it would take a significant effort that may run into unforeseen limitations along the road much like even my simple key remapping attempt turned into a time waster. I once looked at something similar to UI-tree walking to obtain icon names at the mouse pointer on the Microsoft Windows desktop, but there it was a royal pain and still did not quite yield the sought information. Unfortunately Google rarely discloses what they are up to, so one cannot know how much of the app-level accessibility patching and bridging will become obsolete in what time frame. For instance, I made my app's UI elements self-voicing before Google released TalkBack, but by now that effort is mostly obsolete. Basically all blind Android phone users and would-be users are now clamoring for something equivalent to the iPhone touch screen experience, but that requires changes to the OS, and we non-Google accessibility developers do not know if or when these are forthcoming. Thanks The vOICe for Android http://www.seeingwithsound.com/android.htm On Dec 17, 1:00 pm, Mark Murphy wrote: > On Fri, Dec 17, 2010 at 6:52 AM, blindfold wrote: > > Thanks Mark. I can easily detect touch events by their coordinates, > > but not so easily identify what UI elements lie underneath - unless I > > define and layout each of these UI elements graphically myself in > > terms of screen coordinates. > > Walk the widgets in the layout and figure out who is on the screen at > your touch coordinates via getLocationOnScreen() (or maybe > getLocationInWindow())? I'm probably being a bit simplistic, but I > would think there should be some way to figure out what is underneath > the touch coordinate. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9 > Available! -- 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
Re: [android-developers] Re: How to simulate a (missing) DPAD
Hmm... yah, that might work, you could use audible tones and or vibration to help the user know what they are touching. - Brill -- 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
Re: [android-developers] Re: How to simulate a (missing) DPAD
I'm not sure that is going to work all that well for you, but instead of emulating the DPAD, can you simply listen for the keys you are trying to remap instead of remapping them? I think its great that you are trying to solve a problem for a user that is having trouble with your app because of an unusual circumstance... however I also feel that the user in question should maybe take that problem up with whoever they got the phone from and get a new phone; you may be willing to make an effort, but most apps won't, so they really have the wrong phone. - Brill -- 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
Re: [android-developers] Re: How to simulate a (missing) DPAD
On Fri, Dec 17, 2010 at 6:52 AM, blindfold wrote: > Thanks Mark. I can easily detect touch events by their coordinates, > but not so easily identify what UI elements lie underneath - unless I > define and layout each of these UI elements graphically myself in > terms of screen coordinates. Walk the widgets in the layout and figure out who is on the screen at your touch coordinates via getLocationOnScreen() (or maybe getLocationInWindow())? I'm probably being a bit simplistic, but I would think there should be some way to figure out what is underneath the touch coordinate. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9 Available! -- 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
[android-developers] Re: How to simulate a (missing) DPAD
Thanks Mark. I can easily detect touch events by their coordinates, but not so easily identify what UI elements lie underneath - unless I define and layout each of these UI elements graphically myself in terms of screen coordinates. I think your proposed TalkBackOverlayView would require that too, if I understand you correctly. My main screen already uses different touch screen events for gross positions like center, top middle, left middle, bottom left and bottom right, and speaks the relevant user actions. Here I did without an exploration mode, although that should have been easily possible through handling ACTION_DOWN and ACTION_UP events separately in dispatchTouchEvent(). This very basic level of touch screen use is indeed accessible for blind persons, as are the keyboard shortcuts that I have defined for phones with a physical keyboard. However, at some point one would want to make good use of standard UI elements (listviews, buttons, radio buttons, checkboxes etc) for which Android determines the concrete layout instance, and render these standard elements accessible rather than having to define a range of dedicated touch views corresponding to each and every activity view that sighted users would use. I have no ambition to reinvent the Android layout framework. The iPhone, through VoiceOver, offers a generic touch screen solution for this as part of the OS. I feel that any accessibility "hook" for standard UI elements that I add at application level to my specific Android app should be only an interim solution and a stop gap until Android catches up and offers a similarly general accessibility solution as part of the OS. Otherwise, blind users will in the future at best have a few accessible point solutions, but no general accessibility with phones that lack a physical keyboard and/or d-pad. Now while trying to bridge the current accessibility limitations for d- pad-less Android phones, apparently even a simple key remapping is not that, erm... simple, with the current set of event Listeners and onWhatevers(). :-( On Dec 17, 11:37 am, Mark Murphy wrote: > On Fri, Dec 17, 2010 at 4:31 AM, blindfold wrote: > > This currently requires physical keys, because > > Android still lacks the kind of touch event model of the iPhone where > > (blind) users can explore the screen by touch and hear GUI elements > > spoken without immediately activating whatever elements they are > > touching or sliding over. > > If this is your own app, I would think you could do this on your own. > Have a "blind mode" that puts a TalkBackOverlayView on top of the > regular UI. TalkBackOverlayView would use the same techniques as > GestureOverlayView to detect touch events and selectively pass them > through. In particular, in an "exploration" mode, it would behave as > you describe -- when the screen is touched, find out the widget > underneath it at those pixel coordinates, and announce what it is. > > Offering this for other apps would require firmware mods, of course. > > And, of course, I haven't tried this, nor have I looked at the > GestureOverlayView code to see how tough it would be to implement. > It's just an idea that popped to mind while reading your post. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9 > Available! -- 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
Re: [android-developers] Re: How to simulate a (missing) DPAD
On Fri, Dec 17, 2010 at 4:31 AM, blindfold wrote: > This currently requires physical keys, because > Android still lacks the kind of touch event model of the iPhone where > (blind) users can explore the screen by touch and hear GUI elements > spoken without immediately activating whatever elements they are > touching or sliding over. If this is your own app, I would think you could do this on your own. Have a "blind mode" that puts a TalkBackOverlayView on top of the regular UI. TalkBackOverlayView would use the same techniques as GestureOverlayView to detect touch events and selectively pass them through. In particular, in an "exploration" mode, it would behave as you describe -- when the screen is touched, find out the widget underneath it at those pixel coordinates, and announce what it is. Offering this for other apps would require firmware mods, of course. And, of course, I haven't tried this, nor have I looked at the GestureOverlayView code to see how tough it would be to implement. It's just an idea that popped to mind while reading your post. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9 Available! -- 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
[android-developers] Re: How to simulate a (missing) DPAD
Thanks Dianne! Good to know, even though it presents a setback.
> Why are you doing this?
For accessibility purposes. One of my blind users just bought an
Alcatel OT-980 running Android 2.1. This phone does have a physical
QWERTY keyboard but no d-pad or equivalent (BTW, the same applies to
Motorola Droid Pro and Sony Ericsson X10 mini pro). So I want to make
provisions for blind navigation of menu and dialogs through Google's
screen reader TalkBack. This currently requires physical keys, because
Android still lacks the kind of touch event model of the iPhone where
(blind) users can explore the screen by touch and hear GUI elements
spoken without immediately activating whatever elements they are
touching or sliding over. This is particularly relevant for the soft
keyboard, but even with Android phones that have a physical keyboard
we face this accessibility problem when there is no d-pad. These users
are motivated enough to learn a few workarounds, because that is part
of their daily life.
Best regards
The vOICe for Android
http://www.seeingwithsound.com/android.htm
On Dec 17, 10:06 am, Dianne Hackborn wrote:
> I doubt you will get this to work correctly, because you are doing this
> after parts of the framework that deal with things like going in and out of
> touch mode have seen the events.
>
> Why are you doing this? If a device doesn't have a DPAD, the user isn't
> going to think to use the volume keys to navigate focus(!!). You should be
> giving them a good touch-based UI.
>
> On Fri, Dec 17, 2010 at 12:38 AM, blindfold wrote:
>
>
>
> > For Android phones that lack a physical d-pad or trackball (e.g.
> > Alcatel OT-980, Motorola Droid Pro), I am trying to remap the physical
> > up and down volume keys to simulated up and down d-pad keys using code
> > like
>
> > �...@override
> > public boolean onKeyDown(int keyCode, KeyEvent event) {
> > if (keyCode == KeyEvent.KEYCODE_VOLUME_DOWN) {
> > KeyEvent ke = new KeyEvent(KeyEvent.ACTION_DOWN,
> > KeyEvent.KEYCODE_DPAD_UP);
> > dispatchKeyEvent(ke);
> > return true;
> > }
> > return super.onKeyDown(keyCode, event);
> > }
>
> > Although this works fine with a ListView and with activity views that
> > become scrollable because they are too large to fit on the physical
> > screen, it somehow does not work at all for activity views that remain
> > small enough to fit on the screen. I can test this by increasing the
> > number of radio buttons in some activity view and then see how the
> > above key remapping begins to work fine as soon as there are more
> > controls than fit on the screen. I have tried all sorts of things with
> > setting focus after making things focusable using setFocusable(true),
> > setFocusableInTouchMode(true), requestFocus(), requestFocusFromTouch()
> > and so on, but nothing seems to help. The above onKeyDown() executes
> > in all relevant cases as shown by my Log.i() output, but it is the
> > dispatchKeyEvent() that in the described cases does nothing. All my
> > activity views are surrounded by in the XML
> > of their respective layouts. More about the context of this problem at
>
> >http://groups.google.com/group/eyes-free-dev/browse_thread/thread/374...
> > (eyes-free-dev list).
>
> > So the above code works "sometimes", but I need a reliable/general
> > solution. How can one reliably remap physical keys to perform key
> > functions for which there are no physical keys on the Android device?
>
> > Thanks!
>
> > --
> > 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
>
> --
> 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, and so won't reply to such e-mails. 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
