Your SlideShare is downloading. ×
0
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Android: Dealing with Different Devices
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Android: Dealing with Different Devices

786

Published 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.

Published in: Technology, Art & Photos
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
786
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
14
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   

×