Android App Mistakes: Avoiding the Anti-Patterns

Android App Mistakes:Avoiding the Anti-Patterns

by Mark Murphy, CommonsWare

Introduction

• Anti-Patterns

• Code pollution

• Fatal assumptions

• Goal: help you avoid these anti-patterns

• Developers

• OEMs

Everlasting Services

• What is the Anti-Pattern?

• Trying to have a service “always running”, instead of periodically running or running when your activity is on-screen

• startService() without a stopService() or stopSelf()


• Why Is This Important?

• Android kills off old services to reclaim RAM

• Users kill off services they do not understand

• Task killer

• Settings > Applications > Services


• What is the Right Answer?

• Rare use cases for everlasting services

• VOIP app

• Otherwise, aim to keep the service out of RAM when not actively doing work

• AlarmManager

Background Control


• Implementing a polling mechanism without any sort of user control

• Implementing an everlasting service without user option to not have it

Background Control


• Users may blame your app

• Battery drain

• RAM consumption

• Users may kill or uninstall your app to regain control

Background Control


• If polling, let user choose period (including “never”)

• If everlasting service, let user say “no”

• VOIP app...but only for outgoing calls

Background Becomes Foreground


• Doing significant processing in background callbacks

• onReceive()

• onCreate() / onStart() / onDestroy()



• Normally, background processing is CPU-capped at ~10%

• During those callbacks, priority changes to normal foreground priority

• May impact real foreground (e.g., game)



• BroadcastReceiver delegates to IntentService

• IntentService does everything in onHandleIntent()

• Or other means of using background threads instead of work in callbacks

Boot-Time Services


• Configuring a BroadcastReceiver to respond to the BOOT_COMPLETED broadcast Intent

Boot-Time Services


• Too many boot-time services slows the boot down for user

• Lots of process churn

• May cause those broadcasts to be delayed for everyone

Boot-Time Services


• Use it only if truly necessary (e.g., restore AlarmManager alarms)

• Do not do significant work right away

• Wait for later trigger or user interaction

Using Multiple Processes


• Forcing Android to use more than one process for your application

• Remote services for internal use

• Process attributes in manifest

• Forking processes from JVM



• Each process takes up a significant chunk of RAM

• More active processes = more likely other things get kicked out of RAM

• If user feels RAM is over-utilized, more likely to come after you with task killer



• Just avoid multiple processes!

• Remote services/AIDL are for third-party use, not your own

• Be careful on forking system processes (e.g., interpreters, built-in binaries)

Use Mutable Statics


• Using static data members for more than final “constant” values

• Caching

• Cross-component communication

Use Mutable Statics


• Android can close components to reclaim memory...if memory can be GC’d

• Static references inhibit GC

• Static references to things that hold onto components defeats Android’s intentions

Use Mutable Statics


• Avoid mutable statics where possible

• Be very careful with the ones you need

• Ensure they do not hold references (direct or indirect) to activities, services, etc.

Leak Like a Sieve


• Register...and do not unregister

• Acquire...and do not release

• Assign to static...and not null out reference later

Leak Like a Sieve


• Once again, the issue is GC

• Registered listeners, etc. are held in static references inside of Android

• Must get those released

• Free up RAM

• Stop events from continuing to fire

Leak Like a Sieve


• Aim to use lifecycle pairs

• Register in onCreate(), release in onDestroy(), etc.

• Use onDestroy() as “backstop”, releasing everything registered or acquired

• Exception handling and finally {} block

Force Wrong UI


• Adding an Exit menu choice or button

• Trying to create a blocking modal dialog

• Otherwise attempting to pretend Android is some other OS

Force Wrong UI


• Android has a style all its own

• Different, not necessarily bad

• Breaking that style will cause some user confusion...or developer confusion when users do not behave as expected

Force Wrong UI


• Use Android navigation and APIs naturally, not trying to emulate some other model

• Navigation: pretend you are writing a Web application

• Flow is much like a Web browser

Ignore Screen Sizes


• Focusing on one screen size

• Focusing on customizing for individual screen sizes

• Instead of coming up with layouts, etc. that work across sizes

Ignore Screen Sizes


• Your app may not work well on existing devices

• Your app may not work well on future devices

• Many new screen sizes are coming

Ignore Screen Sizes


• Write to be resolution-independent

• RelativeLayout

• Don’t use pixel dimensions

• Test on a wide range of layouts to confirm your independence actually works

Assume Touch


• Writing an application that assumes the existence of a touchscreen and does not mandate it via the manifest

• Not testing an application via the D-pad and keyboard alone

Assume Touch


• Not all Android devices will be touchscreens

• Television set-top boxes

• Low-end smartphones / high-end “feature phones”

Assume Touch


• If your app only makes sense with touchscreen, require it via the manifest

• If your app could be used by D-pad or equivalent, test it out, make sure it makes sense

• “Tab order” issues

Make Busy App Widgets


• Trying to update an app widget every second...from your code

• Rolling your own timer

• Faking an animation



• App widgets cross the process boundary on every update

• Your code -> home screen process

• IPC is expensive in terms of CPU time

• Hence, expensive for battery



• App widgets are largely static or driven by user input

• Update the app widgets on user demand or slow timers

• 30 minute minimum for updatePeriodMillis

Assume Unlimited Data


• Assuming users have unlimited SMS plans

• Using SMS for chatty app protocols

• Assuming users have unlimited data plans

• Constantly refreshing or downloading data



• “Unlimited” SMS or data only available in some markets to some users

• Everybody else pays by the message or MB

• Even “unlimited” usually comes with caps

• Net: costs users money or capability



• Allow user controls over chattiness or refresh periods

• Pay attention to WiFi vs. mobile data connections

• WiFi is less prone to costing users money

Reach Past the SDK


• Using reflection to access public classes, etc. that are not part of the SDK

• Accessing undocumented content providers

• Assuming existence of certain binaries

Reach Past the SDK


• Your app may break on today’s or tomorrow’s phones

• Broken apps = unhappy users

• Will they think ill of you...or Android?

• Weakens arguments against OEMs

Reach Past the SDK


• Stick to the SDK

• Work with the core Android team to figure out how to open more up

• Coordinate SDK-hack wrappers

• Strength in numbers

Anti-Patterns, OEM Style

• Plenty of anti-patterns for creating Android devices

• Impacts ability of developers to deliver quality apps for your device

• Impacts user satisfaction with apps, your device, and Android overall

Breaking the SDK


• Changing Android and breaking API

• Changing Android and changing behavior of documented resources

• Inadequately setting expectations

• Example: contacts and Facebook

Breaking the SDK


• Broken SDK means some apps break when run on your device

• Until developers spend extra effort trying to work around your errors

• Broken expectations cause angst for users and developers alike

Breaking the SDK


• Test, test, test!

• CTS is nowhere near sufficient

• Developer device seeding program

• Direct

• Through services (DeviceAnywhere)

Hamper Developers


• Break access to DDMS

• Block non-Market app installs

• Innovate without adequate explanation

• Example: CDMA on Android 1.5

Hamper Developers


• Users buy these devices for the apps

• Important for apps to work well on your device

• Users will think poorly of your device

• Users will think poorly of Android

Hamper Developers


• End users are not your only user base you need to think about

• Have developer programs for communication and support

• Don’t screw up the firmware too bad

Block Replacement Firmware


• Using cryptographic signing to prevent people from replacing firmware



• Segment of your user base values this

• Can result in bad PR

• Never know when a replacement firmware may increase the value of your device, or give you access to firmware talent



• Best = support replacement firmware

• ADP1, ADP2

• Great = endorse replacement firmware

• Nexus One

• OK = “fig leaf” on firmware issue

Summary

• Avoid anti-patterns

• Better for your apps

• Better for your devices

• Better for Android overall

Contact Info

• http://commonsware.com

• [email protected]

• http://commonsware.com/blog

• Twitter: commonsguy

• +1.484.350.4004

http://commonsware.com

http://commonsware.com

mailto:[email protected]

mailto:[email protected]

Technology

Android App Mistakes: Avoiding the Anti-Patterns