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.
Related
Similar to this iOS-question ( VoiceOver announces dimmed instead of disabled for buttons ) I have the same problem, but for Android devices with Talkback.
Why is Talkback announcing some elements like buttons or checkboxes as "dimmed" instead of "disabled"?
Should I somehow change this, or leave it as Talkback reads it? If I should change it to "disabled / dimmed" so that it's consistent over the whole app, how?
[EDIT]:
Example:
It seems that not only buttons use "dimmed", but check / tick boxes as well.
Also only the english language seems to use "dimmed", in german it's still read as "deaktiviert" (disabled).
Don't change it. TalkBack is responding to properties in ways that users would be accustomed to. Sometimes the default behavior is the most accessible because it is expected, even when it isn't quite ideal.
If you would like an answer to the "why" I would need more information on the particular examples that your talking about. Are there apps that exhibit this behavior? TalkBack updated not too long ago, but I generally hear the "disabled" announcement over the "dimmed" announcement from TalkBack from the "obvious" times that such an announcement would apply. I certainly wouldn't expect there to be a general distinction between the two.
Also, I'm looking through the current version of TalkBack (again TalkBack has been updated recently, so the open source version may not be up to date and available) and can't find the localized string "dimmed" anywhere. There are references to "screen dimmed" but this is certainly different from what you're talking about. Which suggests to me that the "dimmed" announcement is coming from changes in the code that I would recommend be UNDONE, so as to allow the "disabled" announcement that TalkBack users would be accustomed to. This sounds to me like something someone coming from an iOS background wanted to duplicate. The behavior in iOS is to announce disabled things as "dimmed". Duplicating this on Android would absolutely be innapropriate. Let TalkBack do its thing!
Providing code examples would be helpful for me to be more sure about all of these things, your question is quite ambiguous. What types of controls? A Button for example may behave different from a Tab in a TabWidget, and this may be intentional. The way your question is worded, any more specific answers than I have given would be speculative.
EDIT:
The different parts of this announcement:
Every Sunday (0): The text of the control
Tick Box: The calculated role of the control. In stock Android this will announce as "CheckBox" (I'm testing on 7.0, with the current GitHub TalkBack). Samsung would be best off to leave this as "Check Box" from stock Android OS, I don't know why they felt the need to change "Check Box" to "Tick Box" just to be different. Doing things just to be different is annoying, there is no objective difference between "Check Box" and "Tick Box" (licensing???).
Not Selected: The current calculated state of the control. In Stock Android this would read out as "Not Checked". Unless the app is overriding this, Samsung would seem to be mucking with this as well. They should stop doing so, but again, out of your control and best left alone. Samsung users will be used to this. Though ultimately I find "Not Selected" to be a little ambiguous in terms of a CheckBox control. "Not Ticked" I think would be better.
Dimmed: Again, another thing that, unless your code is overriding (which I don't think it can in this case for this bit of calculated state). This is the calculated enable/disabled state of the control. In stock Android this would read out as "disabled". Again, leave this alone. Samsung would ALSO be best to leave this alone.
It would definitely appear that Samsung is doing strange things to the Accessibility read outs of calculated components. I'm not sure what version of Android this Samsung flavor is built off of, but I don't believe those read outs have changed. I know CheckBox and Disabled have been the same since 4.2 - 7.0 (probably Android O as well.). These minor changes fracture the Android Accessibility Ecosystem. For these particular elements, Samsung would definitely be best off just to leave them alone. HOWEVER, given that Samsung has made these changes, you are best off NOT fixing this fragmentation. Let Samsung users and Nexus users and Motorola users experience things in the way they are used to and get accustomed to their devices. Allow default behaviors unless overriding them is absolutely necessary. Hearing "disabled" when your expecting "dimmed" is confusing, not to mention a maintenance nightmare should Samsung decide NOT to override this any more or vice versa. When the OS is "calculating" state and doing so reasonably... let it happen!
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.
In my app I have a custom dialog that works great on my stock gingerbread rom. I checked my app out on my friend's Atrix, and there is this extra border that looks to be consistent with the rest of the ui (sorry, dont have an Atrix here to test it out). The same thing happens when i use my app on a Droid 1 with stock froyo (theres a thicker, grey border). Is there a way to get rid of this?
The only way to get rid of it is by overriding all the styles used in a dialog. Most of the time this is not necessary... a dialog on the Atrix will look like every other dialog on the Atrix, so the user doesn't really notice the difference. If you need a specific look to match your app, however, you need to style it.
I just took a look on different devices and their soft keyboards. They are all looking a bit different. I attach two screenshots. One is from my HTC Desire (Android 2.2), another one from Emulator (Android 2.3).
As you can see on the device the enter key is on device just a symbol, on emulator it is "send".
Can I change it somehow?
I had this problem a year ago, my problem was that the numeric keypad is very different from each provider (not only on style but on the buttons that are shown)
In my personal experience is a pain to try to change that, you would need to create your own SoftKeyboard class with your own images.
If it's not an important issue I recommend to just pass over it, or find a keyboard type that satisfies your needs.
However, I don't know if in the newest versions of Android you get an easier way to customize keyboards.
Good luck on there :)
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...