In this presentation entitled Faces of Fragmentation, Mark Murphy discusses Android mobile development.

1. In the Brain Of...Mark Murphy
Facets of Fragmentation

2. Those Who Cannot
Remember the Past Are
Condemned to Repeat It
George Santayana

3. Past? There's a Past?
Too Many Android Developers

4. Screen Resolutions
● The Concern: GUI Design
– Many existing resolutions
– New resolutions cropping up all the time
● Documented support sometimes lags
● Cannot always emulate desired sizes
– Designing for multiple resolutions “makes my
head hurt”

5. Screen Resolutions
● Historical Analogue: “The Window”
– Invented in the 1970's
– Allows for thousands (millions!) of possible
resolutions
– Can be changed by user on the fly

6. Screen Resolutions
● The Techniques
– RelativeLayout or weight-based LinearLayout
– Anything-but-pixels for dimensions
– Density-driven drawables
– Strategy-based presentation
● Different layouts
● Different presenter implementations

7. Screen Resolutions
● What We Could Use
– More layout classes and better understanding of
how to make custom layout classes
– More documented UI patterns with layouts and
sample code
– A nice icon library
● ...once the icon styles stabilize

8. Framework Changes
● The Concern: Shifting APIs
– Deprecate-and-replace
● Contacts
● Sensors
– Deprecate-and-don't-replace
● Secure settings

9. Framework Changes
● Historical Analogue: “Java”
– Threads
– Bytecodes (1.4.2 → 1.5)
– I/O (streams → readers)
– Well over 100 classes, methods, interfaces,
fields, etc. between Java 1.1 and Java 6.0
– Many new classes in each subsequent release

10. Framework Changes
● The Techniques
– Version detection (android.os.Build)
– Reflection
– Conditional class loading
● Abstract base class
● Concrete classes for each API level
● Abstract base class creates singleton based on API
level
● Rest of app uses singleton

11. Framework Changes
● What We Could Use
– More canned strategies
● Example: Sensor API → 3D gesture library
– More sample wrappers
● E.g., blog post with recommended wrapping
approach for each modified/deprecated API

12. OS Bugs
● The Concern: Unintentionally Shifting APIs
– Example: OpenCORE → StageFright
– Flavors
● Code that used to work, and should work, does not
work
● New APIs that should work do not work

13. OS Bugs
● Historical Analogue: “Windows”
– Each major release broke something from
previous releases
– Service packs even more likely to break
something
– Why do you think we have so many IT people?

14. OS Bugs
● The Techniques
– Mostly the same as for official changes
● Version detection
● Reflection, conditional class loading, etc.
– More prone to problems near the edges
● Example: video file formats

15. OS Bugs
● What We Could Use
– Patience
– A case (or 20) of Red Bull
– Better/faster feedback on issue tracker

16. Presentation Layers
● The Concern: Changing Look and Feel
– HTC Sense, MOTOBLUR, TouchWiz, Rachael,...
– Effects
● Home screen and app widgets
● Default colors (e.g., orange vs. green)
● Theoretically, nothing else too much

17. Presentation Layers
● Historical Analogue: “Themes”
– Available on most desktop/notebook OSes
– Effects
● Colors used everywhere
● Widget styles (e.g., radio button/checkbox)
● Font sizes

18. Presentation Layers
● The Techniques
– Will It Blend?
● Make no color assumptions, try to specify as few
colors as possible
– Assert Your Authority
● Use Android styles and themes and control the color
of every item

19. Presentation Layers
● What We Could Use
– “BrowserCap”-style database
● Mapping android.os.Build → presentation layer
– API for presentation layers
● Database would only be needed for earlier Android
versions

20. Hardware Differences
● The Concern: Devices Different, Dammit!
– Expected Differences
● External storage availability
● Camera resolution
– Unexpected Differences = No API
● Multiple forms of external storage
● Front-facing camera

21. Hardware Differences
● Historical Analogue: “PCs”
– Hardware manufacturers used to often leap
before Microsoft was ready
– Examples
● Video cards
● Input devices
● CD burners

22. Hardware Differences
● The Techniques
– Expected Differences: Use the APIs
● Environment.getExternalStorageState()
● Camera.Parameters values
– Unexpected Differences
● SDK add-on
● Lots of switch() statements
● Ignore

23. Hardware Differences
● What We Could Use
– “BrowserCap”-style database
● Mapping android.os.Build → hardware
capabilities
– More organized support for advancing hardware
● Android has improved support for expected
differences, negligible support for unexpected
differences

24. Device Bugs
● The Concern: Irreconcilable Differences
– MOTOBLUR and 1.5 contacts
– Samsung and viewing contacts
– Notification “number”
– DROID 30fps limit
– Theme: bugs impacting compatibility

25. Device Bugs
● Historical Analogue: “Damn Well Everything”
– Grace Hopper found Mark II hardware bug in
1947
– Steady stream since then
– Compatibility issue only relevant for multi-
vendor platforms
● Android, Windows Mobile, Windows Phone,
Windows, Linux
● Not iOS, Blackberry, WebOS, Palm OS, OS X

26. Device Bugs
● The Techniques
– Strategic: Beef up the Compatibility Test Suite
● Best “contract” between manufacturers and
developers, by way of Google
– Tactical
● Drop features based on device
● Find workarounds

27. Device Bugs
● What We Could Use
– “BrowserCap”-style database
● Mapping android.os.Build → recognizable
hardware limits (e.g., 30fps), identified flaws (e.g.,
notification “number”)
– Streamlined contribution process to CTS
● Or perhaps just better documentation using CTS as
example

28. Self-Fragmentation
● Going Past the SDK Boundaries
– Accessing public non-SDK classes and methods
via reflection
– Using command-line utilities via Runtime.exec()
– Listening on undocumented broadcasts
● Flaw: Android May Change

29. Self-Fragmentation
● Treating Common Apps as OS Components
– Using undocumented app content providers
● Calendar
● Messaging
– Directly invoking activities via component names
● Flaws
– Android may change
– Apps may be replaced by OEMs

30. Self-Fragmentation
● You Are Welcome to Take the Risk
– “It's a free country...”
– Cannot do this on iOS App Store!
● No Grounds for Complaints
– Systemic changes (e.g., Android OS releases)
– Device changes

31. Free As In...
● Most Problems Due to Freedom
– Device manufacturers have broad latitude
– Developers don't have to play by the rules
– Exacerbated by rapid pace of evolution
● Improvements Over Time
– Slower rate of change, stronger CTS
– More community support structures
● Be the Change You Seek