Search

Sunday, April 17, 2011

Bad practices coding for Android

In the last post I talked about the good practices to follow by an android beginner. Now I'm going to summarize the bad practices collected from Android Dev Helper 2010. This are common mistakes we must avoid always when coding for Android. Google talks of them as "The five deadly sins":

About Sloth:

To avoid sloth we should be fast and responsive. The clues to be fast are the next:
  • Avoid creating objects (minimize it)
  • Use native methods
  • Virtual is better than interface
  • Static is better than virtual
  • Avoid internal getters an setters
  • Declare constants final
  • Avoid float an enums
  • Use package scope with inner classes

The clues for responsiveness are:
  • Avoid modal Dialogues and Activities, informing always the user with the progress and rendering and filling the data as it arrives
  • Respond to the user input within 5 seconds and Broadcast Receiver must complete in 10 seconds
  • Users perceive a lag longer than 100 to 200ms
  • Use Threads and AsyncTask within Services

About Gluttony:

We must use system resources responsabily:
  • Don't over use WakeLocks
  • Don't update Widgets too frequently
  • Don't update your location unnecessarily
  • Don't use Services to try to override users or the system
  • Do share data to minimize duplication
  • Do use Receivers and Alarms not Services and Threads
  • Do let users manage updates
  • Do minimize resource contention

For using Wakelocks correctly:
  • Do you really need to use one?
  • Use the minimum level possible
  • Release as soon as you can
  • Specify a timeout
  • Don't use them in Activities

About Hostility:

Avoid fight with your users. User experience should be your top priority and you should respect user expectations for navigating your app, avoiding hijack the native experience and respecting the user preferences:
  • The back button should always navigate back through previously seen screens
  • Always support trackball navigation
  • Understand your navigation flow when entry point is a notification or a widget
  • Navigating between application elements should be easy and intuitive
  • Don't hide the status bar
  • Use native icons consistently
  • Put menu options behind the menu button
  • Use only enabled location-based services
  • Ask permission before transmitting location data
  • Only transfer data in the background if user enabled

About Arrogance:
  • Avoid fight the system. Take it as it is.
  • Don't use undocumented APIs
  • Make your app behave consistently with the system
  • Respect the application lifecycle model

About Discrimination:

Since there are many devices and many SO versions, you should design and code for everyone.
  • Don't make assumptions about screen size or resolution
  • Never hard-code string values in code (or XML)
  • Use Relative Layouts and device independent pixels
  • Optimize assets for different screen resolutions
  • Use reflection to determine what APIs are available
  • Store values as Resources (colors, dimensions, arrays, images, layouts)