Say I'm developing an app for Android tablets that supports offline use, such as a mail or Usenet client. As far as I can tell, most tablets are Wi-Fi-only, and the user is likely to be away from Wi-Fi for several minutes to several hours at a time. For example, a user might be a passenger on public transit and not be carrying a smartphone with a tethering plan. How can I please both non-technical users who want functionality and technical users who are sensitive about what apps can do to intrude on their privacy?
In case the reader has been spoiled by always-on Internet connections over the past decade, here's a refresher of how offline functionality works: An offline user might read messages that have already been downloaded and compose new messages that go into an outbox. When an Internet connection becomes available, the user expects the app to "sync": wake up, send all messages in the outbox, and download new messages that have become available. Then the user can go offline again and work with those messages.
Some users want opportunistic sync whenever the device discovers that a connection has become available behavior. But other users might think the ACCESS_NETWORK_STATE
permission or especially the READ_CONTACTS
permission is too intrusive on the user's privacy and would refuse to download an app that requests this permission.
"Need my address book? [Expletive] off."
--epine
And I'm told permissions can't be made optional in Android prior to Marshmallow; only hardware feature requirements can be made optional. And on Android, network state isn't considered an optional hardware feature.
An answer to "Is it possible to have 'optional' permissions in Android?" recommends splitting an app's functionality into several apps listed on Google Play Store:
- "FooMail" is the core app, with only
INTERNET
permission. If only this app is installed, the app would still run with its own contacts and let the user request a sync within the app. All features are usable except completing "To" with outside contacts and automatic sync. - "FooMail: Contacts" uses
READ_CONTACTS
to query the system-wide contacts to complete the "To:" field in mail. - "FooMail: Background Sync" creates a background service that uses the
ACCESS_NETWORK_STATE
permission to discover when the Internet connection has become available and request a sync if background data is enabled system-wide. - "FooMail: Sync on Device Start" creates a background service that uses the
RECEIVE_BOOT_COMPLETED
permission to discover when the device has finished starting and request a sync if background data is enabled system-wide. This way, even if the device's battery completely discharges or an OTA system update has been installed, the user is notified that new messages are available for offline reading once the device is turned on again. It might be prudent to combine this plug-in with Background Sync.
Once the apps are installed, all the UI would be in "FooMail", and the "plug-in" apps would act as services that communicate with "FooMail". Privacy-sensitive users would install only "FooMail", and they would sync manually by opening the app and pulling down the list of messages. Users who want additional functionality would install the core app and all plug-ins, and the setting to enable a feature present in a plug-in would direct the user to the plug-in's page on Google Play Store. How easily would users understand an app's functionality being split into several entries on Google Play Store? If not easily, then what's the best way to accommodate both non-technical users and privacy-sensitive users?
No comments:
Post a Comment