Dealing with DifferentDevices

   

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

   

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

   

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

   

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

   

Step #4: Apply Fragments

● Fragments in an MVC World– Models = POJOs, database+helper, whatever– Views = widgets– Controller = fragments– Activities = orchestration

   

Step #4: Apply Fragments

1 2 3

1 2 3

Activity A  Activity C

Activity A  Activity CActivity B

Tablet

TV

   

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 existingfragment

● Start an activity

   

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

   

Step #5: Tactical Considerations

● Use density-independent dimensions● Use stretchable graphics

– ShapeDrawable– Nine-patch PNGs– SVG (via add-on library)

   

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!

   

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

   

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

   

Step #6: Testing

● Emulators● Devices

– Owned– Loaned (e.g., user group events, device labs at

conferences)– DeviceAnywhere and similar services– Controlled beta test release

   

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

   

Alternative #2: Manifest Filtering

● <compatible-screens>● <supports-screens>● <uses-configuration>● <uses-feature>● <uses-sdk>

   

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