Your apps must play fair with other apps so that they don’t disrupt the user by doing something such as popping up a dialog box when the user is interacting with some activity.
Also Read: Things To Consider When Writing Code For Android Applications
Also, you don’t want one of your app’s activities to lose state when it’s paused, leaving the user confused as to why previously entered data is missing when the user returns to the activity. In other words, you want your app to work well with other apps so that it doesn’t disrupt the user’s experience.
An app that achieves a seamless experience must take the following rules into account:
Don’t drop data
Because Android is a mobile platform, another activity can pop up over your app’s activity (perhaps an incoming phone call has triggered the Phone app).
When this happens, your activity’s void onSaveInstanceState(Bundle outState) and onPause() callback methods are called, and your app will probably be killed. If the user was editing data at the time, the data will be lost unless saved via onSaveInstanceState(). The data is later restored in the onCreate() or void onRestoreInstanceState(Bundle savedInstanceState) method.
Don’t expose raw data
It’s not a good idea to expose raw data, because other apps must understand your data format. If you change the format, these other apps will break unless updated to take the format changes into account. Instead, you should create a ContentProvider instance that exposes the data via a carefully designed API.
Don’t interrupt the user
When the user is interacting with an activity, the user won’t be happy when interrupted by a pop-up dialog box (perhaps activated via a background service as a result of a startActivity(Intent) method call). The preferred way to notify the user is to send a message via the android.app.NotificationManager class.
The message appears on the status bar and the user can view the message at the user’s convenience.
Use threads for lengthy activities
Components that perform lengthy computations or are involved with other time-consuming activities should move this work to another thread. Doing so prevents the Application Not Responding dialog box from appearing, and reduces the chance of the user uninstalling your app from the device.
Don’t overload a single activity screen
Apps with complex user interfaces should present their user interfaces via multiple activities. That way, the user is not overwhelmed with many items appearing on the screen. Furthermore, your code becomes more maintainable and it also plays nicely with Android’s activity stack model.
Design your user interfaces to support multiple screen resolutions
Different Android devices often support different screen resolutions. Some devices can even change screen resolutions on the fly, such as switching to landscape mode.
It’s therefore important to make sure your layouts and drawables have the flexibility to display themselves properly on various device screens. This task can be accomplished by providing different versions of your artwork (if you use any) for key screen resolutions, and then designing your layout to accommodate various dimensions.
(For example, avoid using hard-coded positions and instead use relative layouts.)
Do this much and the system handles other tasks; the result is an app that looks great on any device.
Assume a slow network
Android devices come with a variety of network-connectivity options, and some devices are faster than others. However, the lowest common denominator is GPRS (the non-3G data service for GSM networks).
Even 3G-capable devices spend lots of time on non3G networks so slow networks will remain a reality for a long time to come. For this reason, always code your apps to minimize network accesses and bandwidth. Don’t assume that the network is fast; plan for it to be slow.
If your users happen to be on faster networks, their experience only improves.
Don’t assume a touchscreen or a keyboard
Android supports various kinds of input devices: some Android devices have full “QWERTY” keyboards, whereas other devices have 40-key, 12-key, or other key configurations.
Similarly, some devices have touchscreens, but many won’t. Keep these differences in mind when designing your apps. Don’t assume specific keyboard layouts unless you want to restrict your app for use only on certain devices.
Conserve the device’s battery
Mobile devices are battery powered, and it’s important to minimize battery drain. Two of the biggest battery power consumers are the processor and the radio, which is why it’s important to write apps that use as few processor cycles, and as little network activity, as possible.
Minimizing the amount of processor time occupied by an app comes down to writing efficient code. Minimizing the power drain from using the radio comes down to handling error conditions gracefully and fetching only the data that’s needed.
For example, don’t constantly retry a network operation if one attempt failed. If it failed once, another immediate attempt is likely to fail because the user has no reception; all you’ll accomplish is to waste battery power. Keep in mind that users will notice a power-hungry app and most likely uninstall the app.
You may also like:- Six Ways to Speed Up Your iPhone – A Comprehensive Guide
- Top 3 Android Obfuscators Tools
- Essential Guidelines for Enhanced Security in Mobile Apps
- Top Issues Facing Mobile Devices
- Top 11 Essential Tips for Secure Mobile Application Development
- Things To Consider When Writing Code For Android Applications
- [India] Top 10 Smartphone Apps Of All The Time
This Post Has One Comment
Comments are closed.