Android: Dealing with Different Devices
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Android: Dealing with Different Devices

  • 1,131 views
Uploaded on

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.

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,131
On Slideshare
1,131
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
11
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 CTablet 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