I work on an app with iOS and Android versions and am looking to know more about our users who have accessibility requirements.
There are two pieces of info I'd love to have:
How many of our users on iOS and Android already use accessibility features like voice over, switch control, font scaling, or color and motion settings (amongst many other options).
How many users generally use these features?
I'm having a very hard time using the Google to answer these questions, so any advice would be well received.
Related
Some background on the goal result:
Currently I'm on a team that is working to develop an Android app for use in a classroom. The app is designed to be used across at least 20 or so tablets at once, and to manage connections between all of these devices somehow. It will hold similar functionality as an attendance tool. For instance, the teacher will open their app to an empty list and the students, each with a device of their own, can indicate they are present by clicking a button. Upon each click, the student's name will appear on the teacher app's growing list.
This is the general idea of the app, with the added functionality of student devices able to pass data amongst themselves, as well as the teacher sending out data to them, in an N-to-M device format. As for devices, at the moment we are looking into Amazon Kindles, which can run Android.
We have tried using Google Nearby Connections API:
We have experimented with Google's Nearby Connections API, but have found this to connect inconsistently among three devices. Often, it shows a bluetooth error which seems likely due to inadequate support on the Kindle device for Google's API, for which there doesn't seem to be much documentation online (this is kind of a niche situation). Beyond this issue, I've read on here the Google Nearby API is only intended for use among 7 or so devices at most, due to general lack of bluetooth strength in devices that support it, from what I understand. If that's the case, this wouldn't work for a class of 20+ students.
What we are looking for:
We are hoping to determine the best approach to implementing the Android app of this nature. This is an unfamiliar realm for me, but it seems there are a variety of games out there that utilize functionality of this kind (Kahoot! comes to mind). We have hoped to avoid using standard WiFi as much as possible, since elementary school wireless networks tend to be laggy in the district for which we are developing this app, but if that is the best option then we will go for it. I'd appreciate any insight or advice on how best to approach this development, including API recommendations if you know of any.
Background
Google has announced on Google IO 2018 something that's called "Adaptive battery":
https://youtu.be/ogfYd705cRs?t=3562
As a user, this sounds promising, but as a developer, this could be an issue in some cases.
The problem
They said it checks which apps are used more often using AI, and that the "OS adapts to your usage pattern" :
Adaptive Battery uses on-device machine learning to figure out which
apps you’ll use in the next few hours and which you won’t use until
later, if at all today
To me it sounds like it might be yet another step in the "war against background processing apps".
What I've found
Since this is very new, I haven't found anything of how it works, and if developers should be concerned about it and need to change apps.
Only things I've found are articles from user-point-of-view.
The questions
What is exactly "Adaptive battery"?
Should developers be worried when it's being enabled?
Which app components, background-processing classes, alarms, wakelocks, syncing classes, background/foreground services etc... - might be affected by it?
If indeed it can affect the nature of the app, is there any API to check if it's enabled, and act accordingly? If so, how?
How does it compare to other battery-saving mechanisms?
I agree, this “Adaptive Battery” sounds concerning. This new version of Android, named Android P, “puts AI at the core of the operating system and focuses on intelligent and simple experiences.” (1) On the developer’s blog, they quote, “For developers, Android P beta offers a range of ways to take advantage of these new smarts, especially when it comes to increasing engagement with your apps.” (1) It is pretty obvious that while they are trying to make their OS better for the general public, they have not forgotten their developers.
The two things that are the most concerning with Android P are the Adaptive Battery and Background Restrictions changes. I will try to answer your five questions to the best of my ability, but of course with Android P being in beta, not everything is ironed out yet.
1. What exactly is “Adaptive Battery?”
“In Android P we’ve partnered with DeepMind on a new feature we call Adaptive Battery that optimizes how apps use battery”(1). What Android is using DeepMind for is categorizing apps into different “App Standby buckets” which range from “active” to “rare.” Based on which standby bucket the application is put into, it will vary the restrictions on alarms, jobs, network and high-priority Firebase Cloud messages.
These buckets are: Active – meaning the app is currently being used. Working set – meaning the app is in regular use. Frequent – meaning the app is often used, but not every day. Rare – meaning the app is not frequently used. Obviously these buckets are not clear cut because they are dependent on the DeepMind AI that Android P is implementing. Please follow this link for a better explanation on what the buckets are and how they are used. Also, this link is the Appendix for Power management restrictions, that will also shed light on the Adaptive Battery.
They also say “If your app is optimized for Doze, App Standby, and Background Limits, Adaptive Battery should work well for you right out of the box. We recommend testing your app in each of the four buckets.”
2. Should developers be worried when it’s being enabled?
It looks like developers might have some cause for concern if they do not plan for this. Looking through the power management appendix I linked above, the biggest changes are how long jobs and alarms are deferred. However, it looks like if you force jobs or alarms, then they will fire.
I think, for developers, it would be wise to heed their warning of optimizing your application for Doze, App Standby and Background Limits. And if that is not the route you want to go, I would highly recommend at least make sure to test your app in each of the four buckets.
3. Which app components might be affected by it?
Because Android P is still in beta, these are subject to change. For now, the only app components that would be effected would be: Jobs, Alarms, Network, and Firebase Cloud Messaging. These are all effected differently based on the standby bucket that DeepMind decides they should be in.
Another note, I mentioned background restrictions and was going to elaborate a little on it here, because it is similar to Adaptive Battery in the sense of its limiting powers. Background Restrictions point out applications that have been using battery in the background, and allows users to put restrictions on them. “When an app is restricted, its background jobs, alarms, services, and network access are affected.” So if a user deems your application as taking too many resources, you will get restricted and it seems as if this is like being put into a low priority standby bucket. There are however, ways in the Android P API to check whether your app is restricted, which will be helpful towards developers.
4. If indeed it can affect the nature of the app, is there any API to check if it’s enabled, and act accordingly?
Yes, there are calls in the API that can tell you which bucket that you are in, and whether your app is being restricted as I said before. For example, you can find out what bucket that your application is currently in by calling: UsageStatsManager.getAppStandbyBucket()
Also, there are great ways to test your application using the Android Debug Bridge in each of these buckets. Just follow this link.
5. How does it compare to other battery-saving mechanisms?
This type of bucket battery saving way, to my knowledge, has never been implemented before. This is a new experience. However, I know that the background restrictions have been available since Android Oreo, where the users could see what apps were acting out. However, in Oreo the users could only see what apps were sucking battery, but couldn’t place restrictions.
An interesting example I found here: “So, for example, let’s say you really only look at Instagram at night. In that case, Adaptive Battery will learn this behavior and keep the app in sleep mode during the day, then wake it up when you’re most likely to use it.” That is an example they gave for Android P for how DeepMind will work to place applications into these standby buckets.
Overall, I do think that this is a good step for Android, who has always been plagued by battery issues. As long as developers are not spamming their users with wake locks, notifications, or other things that aren’t necessary, this really shouldn’t impact their application too much. However, this does make it so developers have to put in more work, like checking what bucket they are in and acting accordingly. Time will tell if this is a good step for Android.
Links
(1) - https://android-developers.googleblog.com/2018/05/whats-new-in-android-p-beta.html#androidbeta
(2) - https://developer.android.com/preview/features/power#buckets
(3) - https://developer.android.com/preview/features/power-details
(4) - https://www.howtogeek.com/352364/how-android-p-will-increase-battery-life/
We are working on a mobile app with a feature that allows parents to restrict or disable certain phone functions on their children's devices.
I have been googling for this for a while and can't find an adequate search term.
Ultimately I would like to create a table that outlines various phone features and indicates whether a native mobile application can restrict or disable it. This will be used to indicate the differences between iOS, Android, and Windows Phone development capabilities.
Some features I am looking to modify are: app use, phone calls, text messages, internet access, etc. For restrictions such as phone calls and texts, I'd also like to determine if we can allow a "white list" of allowed contacts.
Thanks for your time.
Windows Phone doesn't have any mechanisms to allow one app to restrict what the user / other apps can do. It does have the Kids Corner feature that enables parents to limit what apps a child can use (and some features within those apps, like In-App-Purchases) but not individual features.
iOS already has a pretty rich parental control center built into the Settings app. I don't believe there is an API that would allow you access those features either. In general, this type of inter-app communication is very limited on iOS.
Preamble
TalkBack is an Accessibility Service for Android that helps blind and vision-impaired users interact with their devices. It’s an screen reader, that reads every user interface element.
This is great visually impaired people can use so many different apps that have not specially adapted.
But it does not work for all types of apps. I want to use a widget, that handle all touch events despite TalkBack is active.
VoiceOver is the complement of TalkBack in IOS. Here is the solution for my problem in IOS.
VoiceOver accessibility in a virtual musical instrument iPhone app?
Question
I implemented this solution to my IOS App and it works fine. Is there any equivalent for Android/TalkBack?
[ mySubView setAccessibilityTraits: UIAccessibilityTraitAllowsDirectInteraction ];
Apps that play sound directly by touch should be able to use with TalkBack on. Instrument apps, several games and apps like mine, that make a room discoverable with 3D Sound, should work with TalkBack on.
Turning off TalkBack is for a blind person not an option. It’s like turning of the screen for seeing people.
If you think there should be such a function, please upvote.
I am trying to write an android application that uses several of the android apis(like policy manager, package manager, wifi apis etc).
The concern i have is, android being open, manufacturers/carriers are free to take any specific version of android as their start point and customize the same and ship it with the device.
Note:Please excuse me if this post is in anyway a repeat of earlier posts on the same/similar topic. In such a case, appreciate anyone sharing the earlier post.
Few things that bother me are:
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
how do i ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know these are some naive questions for many of you who may have been on android for a while, but any pointers in this regard would be of immense help.
Any other information in general w.r.t cross version, cross device incompatibilities and strategies to deal with them would be very helpful.
Thanks a lot in advance.
Regards,
Deepak
Your concerns (and many other developers) are addressed by: http://source.android.com/compatibility/index.html
But this still does not guarantee that manufacturer will not change API and break your application.
The common approach is to initially target subset of devices that make up large percentage of market and then implement workaround for other devices (if necessary). Sample info about device market penetration can be found at:
http://opensignalmaps.com/reports/fragmentation.php?
Kind regards,
Bo
First off, I don't believe you should need to worry about this. Only after you have thousands of users will you end up needing to face the more complex issues caused by the great number of manufacturers offering Android devices. This should not discourage you from developing for Android.
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
No. But it would certainly work against them if they remove important APIs from the system. The core exists as a whole, though there really isn't anything preventing them from removing or disabling chunks as they wish. For example, AT&T had disabled the ability to sideload apps on Android devices some time ago (but I don't think they still do that). An example of a device with reduced functionality: Amazon Kindle Fire. It doesn't at all look like Android in the majority of its interfaces (except within third-party apps) and it doesn't offer the complete API set. Even with those dramatic changes, Android app developers still have great success building and selling apps that run well on the Kindle Fire.
Even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
That's the idea, but there isn't anything in place to forbid them from breaking things. Nor is there anything that will keep them from introducing bugs accidentally.
How do I ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know that some manufacturers will offer an emulator for their devices/configurations to help test against their systems. For example, Motorola offers MOTODEV Studio for this purpose.