I'm looking into these docs: TelephonyManager, Preference and others, but I cannot find anything useful related to Left handed layout.
As far as I know Android 2.3 had that setting. Right now I am unsure if it was deprecated or not. Is there a way to detect if "left handed mode" is set?
Left Handed Mode is possibly similar to "Force RTL Layout Direction" In "Developer Options".
There was never an Android standard setting added to the API for a 'left handed mode'. You may have seen a manufacturer specific change to Android, but I don't know of any recent Android device that has a similar feature.
Individual Android app developers may add the option to switch to a "left handed mode" that will alter the UI to be better formatted for users who hold phones and devices in there left hands. I am an active "Lefty rights" advocate in the app world and call-out developers who could easily better accommodate left handed people. As far as a handicap/accessibility setting there is no current setting on Android for that. There is actually a RTL layout setting in "Developer options" you can enable it through these instructions, and apps like Chrome and Google Maps use it. I would think some more research would need to be done to check for that seeing how it's a developer option and not an accessibility option. My guess would be it is similar to getting the device locale and adjusting. I'm not sure if you could find the developer options in resources though. (Noting for full disclosure, the last time I programmed android was a few months ago.)
I would buy a phone that had RTL/ Lefty Mode perfectly implemented though.
Hope this helps a little.
Have an awesome day, and be well!
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!
I'm working on my first (C++/IwNUI) Marmalade app, which so far works fine, but on Monday one of my devices (an HTC One Android phone, Credo Mobile) had a system update, after which my app, and only my app, now shows what seems to be a "settings" control on top of my app, which can be moved around, but does nothing but clock taps to the app where it is. It's a grey circle with three dots in it, which appears immediately when my app starts to load. Another Android test machine (Samsung Galaxy) does not show this control on my app.
Has anyone else seen this? How might I get it not to appear?
I have asked on the Marmalade forums with no response, and searched here and on the web but I haven't seen any reference to it, so I assume it may be limited to some combination of Marmalade apps, HTC One, and/or Credo Mobile Android phones.
Update: This control appears (on this phone only) on all of the Marmalade example apps I have built too, including IwUI, IwNUI, and plain demos like IwHTTPExample.
Even though this is very specific, I wonder if anyone knows a programmatic way in Marmalade C++ for me to at least get such a settings control to hide or go away?
I found a way to make it go away: "Add android:targetSdkVersion="11" (or higher) to your element." in the settings file which in my Marmalade project is called AndroidManifest.xml.
It seems like this may be a bug where it thinks there is an "overflow" of a title/menu-bar which isn't even there in these apps. By targeting a later version, it uses a newer "holo" menu, which doesn't do this.
If someone has a better explanation, I'll wait to mark that as the accepted answer.
In case it may help future people confused by all this, here's how I found this. Jared's answer led me to study my Marmalade config files, and the Android developer site where I found some general somewhat relevant info about what this is, and to search some different terms on the Marmalade forums, which got me to a relevant question I had missed on the Marmalade community answer pages, which led me to this page which had the suggestion which has the desired effect.
I am guessing you created a new project. Are you seeing this "settings"?
This is automatically added in every new app. Check your res -> menu folder. You can remove the "fake" options menu if you like.
Samsung will show this menu if you hit the menu button on the bottom left of the device.
HTC devices will show the options menu in the ActionBar/ToolBar.
My question is similar to this one. I'm running Android 4.4 on my device, and want to add additional options to the quick settings. I noticed that turning on/off the Alarm Clock shows/hides a tile in the quick settings, like this:
The biggest difference in the two questions is I want to know what it would take to make it work, either having the device rooted, or flashing a custom app at install or what. I've been trying to browse the source code here, but so far I haven't seen anything that stands out to me.
Sorry about the picture size, I don't know if there's an option to scale them down...
Android N introduced Quick Settings API which allow application to add status icon in quick settings. Please check Android N preview document to learn more.
I'm pretty sure you need to be rooted. I have not come across anything that will let you add tiles under completely stock android. Depending on your phone, you might be able to root it without voiding the warranty explicitly, however it will be tricky. After which you can look at installing something xposed framework and then different xposed modules (I suggest gravity box as it lets you add most options to the quick settings). But again, it's all at your own risk for voiding your warranty or soft-bricking your phone. Good luck!
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.
Android SDK suggests developing button states (if on a custom background) around Normal, Disabled, Focussed, Focussed + Pressed and Focussed + Disabled etc.
What I have observed is that mainly android tablets and modern phones, they all have given up on a trackball and nobody really supports them. So in that case, focussed and the related states are something that will never become visible.
Is it necessary to include all those states? Or, can I intelligently save some APK file size by avoiding those graphics currently.
Please send your thoughts.. Thanks
I'm inputting my point of view myself. I have included all the states as of now because I think its best from a standards perspective and I think of one situation when users will really encounter the state where focussed styles have to be shown. I imagine the case when users have external hardware (like a bluetooth keyboard) attached and it somehow enables them to move to those buttons using the arrow key.
Please comment in your thoughts around this perspective too