Developing for Android VIII The Rules: User Interface

Hot off the press (do people even say that anymore), the latest installment from Google Developers - Developing for Android VIII The Rules: User Interface.

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.