• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Android: Dealing with Different Devices
 

Android: Dealing with Different Devices

on

  • 1,008 views

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.

Statistics

Views

Total Views
1,008
Views on SlideShare
1,008
Embed Views
0

Actions

Likes
1
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Android: Dealing with Different Devices Android: Dealing with Different Devices Presentation Transcript

    • Dealing with Different Devices   
    • 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 Activity A  Activity CTablet 1 2 3 Activity A Activity B  Activity C TV 1 2 3   
    • 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   
    • 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