I have two buttons that both have onTouchListeners and perform an action when pressed down. Why do they not work if you try to click both at the same time? I'm building for Android 1.6. I don't have a real device to test on, and you can't test clicking two things at the same time in the emulator. Thanks for any help.
I'm no expert, but my guess would be the following,
All gui-interaction is done through the UI-thread. Unless you do some special treatment of the buttons, you'll end up processing "click 1" with the UI-thread, while the user does "click 2" (at a time when the UI-thread is busy somewhere else). That is, the UI will not be responsive during the second click.
Multitouch was only introduced in Android 2.x, so on 1.6 you're out of luck - not possible. Even with 2.x the default UI behavior is to be singletouch only for such events (ie button press).
I suppose it is possible to somehow extend the container view of those buttons to become multitouch friendly and actually pass the correct events to the buttons, but that would be quite hackish.
You can read more about multitouch here. And on page 3 you can see why the multitouch fails on the GUI: first touch event is ACTION_DOWN which is handled like it should be, and the second one is ACTION_POINTER_DOWN which the UI doesn't know how to handle.
As Roosma already mention, multitouch is available from 2.x version.
According downloading statistics from my app published at android market (already downloaded more then 16k persons) it looks like there are only a few dozens people that using Android 1.6 on their devices. So i think you should mouve to version 2.1 at least.
I hope it helps :)
Related
My android watch has a single hardware (physical) button on the side. Is it possible to program a listener for this button, so that it can be used as an additional control in my program?
I don't believe this is possible. The usual way to detect a standard button press (like Back) in Android is with an onKeyDown listener, and this doesn't fire in an Activity on Wear when the stem button is pressed (tested on both Wear 1.5 and the 2.0 dev preview).
It's always iffy to assert something is categorically not possible, because there's always the chance that someone will find a clever hack to make it happen. And I wouldn't mind being proved wrong. But until such a hack comes along, I'm going to say no, it's not.
I've been writing an new app for our company and came across an odd thing. On the test device (running 2.3.x) the alert dialog buttons will always be in the order of:
POSITIVE | NEGATIVE
Yet, when I tested the app on my personal cell (running 4.x) the alert dialog buttons were switched to:
NEGATIVE | POSITIVE
The code is obviously the same.
I don't really want to make different versions. But I could cater for later versions in code, and maybe (although its rubbish) swap the text of the positive and negative buttons... Which would work, I'm guessing, but it's a bit horrible!
The only problem I can foresee, is that our end-users aren't that tech-savvy and having multiple devices, using differing versions of the OS, could cause issues (which I could easily cater for, but would rather some kind of 'standard').
Is this something I can get around? Or is it best to leave as is and let the OS handle it (as I am doing now)? Also, are there any other small issues I'm going to run into. I.e. Can I guarantee that on 4+ devices that if I'm only using 2 buttons that they will remain in the above order.
What I'm hoping someone will post is a hidden flag that magically sets 4.x alert dialogs to 2.x style :) I'm pushing my luck, I know!
Cheers. Any help is greatly appreciated.
It's an interesting piece of lunacy from Google (see issue 24138) but, as of ICS, this is how it's supposed to be. Definitely best to let the OS choose the ordering.
If you wish to have it the same for all versions, you could potentially check which version of Android is being run, and change the negative/positive buttons yourself. I don't recommend it, and people will expect it to like it is on their device, don't shoehorn everyone into having the exact same flow.
We’re porting to Android some interactive iOS apps used to teach young children with learning disabilities. We have hit a major usability issue, because we can't figure out how to disable physical or on-screen navigation buttons (Home and Recent Apps).
Before anyone says “you don’t want to do that”, we fully understand why you would always want these buttons enabled for an able-bodied adult, but these children pose a unique set of accessibility issues. Specifically:
Their fine motor control may be poor - they may inadvertently touch a different area of the screen to the area they intend, or accidentally use more than one finger at once.
They may have weak muscle tone and poor physical strength – so e.g. the bottom of the palm of their hand may drop and touch the screen while trying to just use a finger.
They struggle to achieve and easily become disheartened or disruptive if they fail.
For instance, a typical 5 year old child with Down syndrome will accidentally drop out of the app they are using as a result of inadvertently touching the Home button: when this happens repeatedly, and the adult teacher or parent has to go back into the app for them repeatedly, the child loses interest and focus. Another typical scenario is a young child with Autism, who may freak out completely and need physically restraining if this happens while using their favourite app. Also, many disabled children will try to poke any other button they can find, in search of a response. In any of these situations, a potentially valuable educational session may have to be completely abandoned.
We're aware of SYSTEM_UI_FLAG_HIDE_NAVIGATION and SYSTEM_UI_FLAG_LOW_PROFILE, but these only reduce the visibility of the on-screen buttons until the child touches some other part of the screen, and then they re-appear in a way that’s more distracting than if they were visible all the time.
On iOS there is the “Guided Access” feature that solves this problem trivially. Can we emulate anything similar on Android?
On iOS there is the “Guided Access” feature that solves this problem trivially.
Guided access appears to be a device setting, not something that developers enable unilaterally themselves, thank heavens.
Can we emulate anything similar on Android?
There is no similar device setting in stock Android.
You can download the Android source code, modify it as you see fit, build the results into a ROM mod, and install that ROM mod on devices as you see fit.
Or, you can perhaps work with a device manufacturer creating tablets aimed at children to see if either they have already added this capability to their devices, or would be willing to work with you to add such a capability in a future iteration of their devices.
I looked around and although there are many related questions I didn't see one that answers my exact question:
I would like to create an app that runs in the background that provides the exact same functionality as the hard coded 'Back' button in all cases.
The reason? I (for example) have a Droid X, and it is BIG. it makes it extremely hard to use one-handed and having a swipe gesture function as a back button (like in Palm Pre for example) would greatly increase the ease of use.
as far as I'm concerned the app could just be one simple class that contains:
1) a listener for the 'back' swipe
2) a call to the physical hard button itself
Is this possible? are there built in APIs for the hard coded buttons that would allow me to call them without actually pressing them?
Again - I'm not interested in overriding the button, I'm interested in making a software call to it - or failing that, in emulating it's behavior in any and all states and other apps!
Please forgive the naivete of this post. I am a very novice programmer and really I just want to know whether this is possible before I start to devote myself to trying to build it.
Thank you,
b
Is this possible?
By writing your own firmware, yes. Via an Android SDK application, no.
I was looking at my application (designed for 1.6) that uses the DatePicker controls on a HTC Desire the other day, and the owner of the phone showed me the native calendar program which uses much much nicer controls, i.e. the datepicker you can touch and scroll rather than having to repeatedly press the buttons to adjust days/months/year.
So my question is does anyone know if these sense controls can be automatically used in place of the stock datepicker controls? I would ideally like my app to run on older devices i.e. 1.6 but show the nicer UI elements if running on a device that has the sense UI.
Thanks
Well unfortunately it appears you can't. Maybe if you know the widget classes you can use them but as for packaging them up in your app so you can rely on them being present in every phone you install on.. not a good idea... as you can't guarantee they'll even work on all devices...