tl;dr : Some important UI details and patterns as they pertain to user experience and performance (which are related).
- Avoid Overdraw
- Enable Debug GPU overdraw in developer settings
- Avoid opaque views covering other views
- Avoid Null Window Backgrounds (had not thought of this much before)
- Eliminating can be valid, but introduces new issues trying to solve overdraw.
- Instead of setting background in manifest, set background in onCreate() by doing getWindow().setBackground(null) - warning, this can cause issues.
- The correct way is to use the starting window with the background you want!
- Avoid disabling Starting window
- This causes the slow start time of the app.
- use a custom drawable if necessary to customize the starting window
- Allow Easy Exit from Immersive Mode
- Unless in a game, make it easy to leave immersive mode by tapping.
- Check the developer guide (link in the article)
- Set Correct Status/Navigation Bar Colors in Starting Window
- Theme the Starting window as you would your app.
- android:statusBarColor
- android:navigationBarColor
- For the activity you can modify them via onCreate
- getWindow().setStatusBarColor()
- getWindow().setNavigationBarColor()
- Use the Appropriate Context
- For UI context, use activity context, not application.
- For resources for your activity, use activity context.
- Avoid View-Related References in Async Callbacks
- Avoid referencing View/Activity/Fragment in network operation / long running async task.
- Consider using weak callbacks..
- It also says consider an event bus, but I personally don't like the event bus because it does not honor the application lifecycle, and you must program around corner cases. (more on this later probably)
- Design for RTL
- As of API 17, applications should use start/end instead of left/right
- You can enable RTL in Developer options
- Cache Data Locally
- "Cache Locally, Sync Globally"
- You should create a local db that keeps data in a meaningful way (not just serialized server response).
- Update your UI from local data whenever possible
- Google I/O 2010 has video, Android REST Client Applicaitons. And personally once again, I would avoid the recommendation of an EventBus. Not even needed if you read your data from a db.
- Cache User Input Locally.
- Cache any user input locally, then send it to the server, this avoids it getting lost..
- Have some UI indication that the data is pending vs. complete.
- Separate Network and Disk Background Operations
- Have two different thread pools one for network one for disk
Some of these things I was not aware of, partially because I had never done some of the 'don't do this' things.. Others I actively do (Syncing data), and other things were totally new, and a great idea, such as having two different thread pools.
