Strategies and tactics for creating Android applications that will work across a range of device types (phones, tablets, etc.). Presented at NoVA-JUG/GTUG event in August 2011.

1. Dealing with Different
Devices

2. Objective: Minimal Redundancy
● More code = more cost
– More development time initially
– Greater odds of bugs
– More maintenance over time
● Aim for maximum targets with the least
feasible code

3. Step #1: Identify Targets
● Where Is Your App Really Going to be Used?
– Outside of US? Small screens popular
– Heavily dependent on mobile data? Tablets less
likely, TVs pretty much out
● Business-Focused Restrictions
– Distribution partners (e.g., OEM deals)
– Enterprise requirements

4. Step #2: High-Level UX Design
● What Are the Major Functions?
– E.g., Gmail = labels, conversations, messages,
composition
● How Are the Functions Delivered?
– E.g., Gmail = one per screen on phones,
combined on tablets
● What Functional Differences Are There?
– E.g., something only on tablets

5. Step #3: ID Reusable Portions
● Where Are You Combining Things?
– Tablet screen = combination of multiple phone
screens
– Only min0r differences in functionality, look and
feel

6. Step #4: Apply Fragments
● Fragments in an MVC World
– Models = POJOs, database+helper, whatever
– Views = widgets
– Controller = fragments
– Activities = orchestration

7. Step #4: Apply Fragments
Activity A Activity C
Tablet
1 2 3
Activity A Activity B Activity C
TV 1 2 3

8. Step #4: Apply Fragments
● Orchestration via Listeners
– Define interface for the event listener
– Activity supplies implementation to fragment
– Fragment calls listener methods as needed
– Activity responds
● Dynamic fragment or reconfigure existing
fragment
● Start an activity

9. Step #4: Apply Fragments
● Hoped-For Outcomes
– Fragments directly usable in all screen sizes
● 1 per activity in small/normal screens
● 1+ per activity in large/xlarge screens
● Fragment implementations oblivious to where other
fragments reside
– Views and models unaffected

10. Step #5: Tactical Considerations
● Use density-independent dimensions
● Use stretchable graphics
– ShapeDrawable
– Nine-patch PNGs
– SVG (via add-on library)

11. Step #5: Tactical Considerations
● Tell Android where whitespace goes
– LinearLayout and android:layout_weight
– TableLayout and android:stretchColumns
– RelativeLayout and wise choice of rules
● Get graphics designer to design with rules in mind!

12. Step #5: Tactical Considerations
● Resource Set Strategy
– Drawables by Density
● Want image to stay roughly the same size
– Layout by Screen Size
● Apply appropriate fragments, sized and positioned
as needed
– Values by Density (dimensions)
– New in 3.2: minimum resolution resource sets

13. Step #5: Tactical Considerations
● API Versions and Backwards Compatibility
– Class Detection
– Reflection
– Conditional Class Loading
● Newer API only
● Abstract class and multiple API concrete
implementations
– Why? For other tablet features
● E.g., work with action bar

14. Step #6: Testing
● Emulators
● Devices
– Owned
– Loaned (e.g., user group events, device labs at
conferences)
– DeviceAnywhere and similar services
– Controlled beta test release

15. Alternative #1: Market Filtering
● Upload Multiple APKs
– Each targeting a different device spec
● Apply Market Filters
– APKs only delivered to devices on which it
should work

16. Alternative #2: Manifest Filtering
● <compatible-screens>
● <supports-screens>
● <uses-configuration>
● <uses-feature>
● <uses-sdk>

17. Alternative #3: HTML5
● Detect window size or user agent, use
appropriate formatting
– Screen density can be a challenge
● Use PhoneGap to convert into installable APK
● Bonus: cross-platform
● Cons: limited device integration, “non-native”
feel