• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Optimizing your Android App for Mass Market Devices

on

  • 2,918 views

 

Statistics

Views

Total Views
2,918
Views on SlideShare
2,918
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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
  • Software Differences Platform Versions Densities and Compatibility Mode Hardware Differences Device Configurations So lets get started. Here I’ve listed 4 different devices and the some of the features that vary across different Android handsets. 1. Platform Version SDK 1.1, SDK 1.5, SDK 1.6, SDK 2.0, SDK 2.0.1 2. Display QVGA vs HVGA vs WVGA 3. Orientation - Portrait or Landscape 4. Camera Flash and Focus
  • Let’s start with Platforms. What does the landscape look like? Google now collects data on it’s platform numbers and publishes that data on a “Device Dashboard”. This data itself is collected from number of apps downloaded from the Android Market to each different OS version. May or may not be an accurate data point for your region but it does show that there are multiple releases of Android available in the consumer space. As more phones are released in your region you will start to see the same type of distribution. When each platform version is released, new features are added that will not be available on previous versions. Be aware of this.
  • So lets look at the how you set the API Level. It’s specified in the element of the application manifest file. There are three properties associated with this tag. minSdkVersion=1 but application uses APIs at level higher may or may not work across phones. The app will install. The app will not run on platforms that don’t support newer APIs used in your application. The app will crash. Not good from a consumer standpoint to be allowed to install an application that will not work.
  • This is where compatibility mode comes into play. Compatibility mode came along when Android began supporting high resolution screens (same time that 1.6 came out). If you set the targetSdkVersion to 3 or lower it means you want your application to look the same on all devices and display at a resolution of 160. It’s “compatibile” on all phones. If you set the targetSdkVersion to higher than 3 (4, 5, 6, 7) it means you want to run your app at the same density that’s on the phone. It could be 160, or 240. In order to set this, the build target must match or be greater than the targetSdkVersion.
  • Size of the screen doesn’t matter, it’s the density that matters. The density affects the scaling of your application. There are 3 components which are the building blocks for building graphical components.
  • Because the first Android devices were running at a 160 resolution, Google has defined 160 as a “normal” or baseline value from which all other densities are compared. 160 * .75 = 120 160 * 1.5 = 240 Applications created against SDKs at API levels 1, 2, and 3 only run at a density of 160 no matter what device they run on. The property you need to set for the other densities does not exist in these SDKs. This property was introduced in SDK 1.6. Applications created against SDKs at API level 4 and above have the option of running at a density of 160 _OR_ the native density of the device. Apps running at a density of 160 on all devices are said to be running in compatibility mode . This is independent of the device you are running on. Applications running at the density of the device are not running in compatibility mode.
  • There are three ways to code for the different densities…….. Compatibility Mode On (runs at density of 1.0/160 dpi) Your application looks/runs the same on different resolutions Tells platform to automatically scale Compatible on all resolutions Issues with new tablets Compatibility Mode Off (runs at density of device) Your application looks/runs differently on different resolutions Tells platform that you want to control the display and scaling It is optimized for higher resolution; looks okay on lower resolution devices
  • tag does not exist in SDK 1.5 or earlier but the framework uses default values for these settings with apps that are built against SDK 1.5 or lower. If you are compiling your application against a build target of 1.6 or higher, then you need to explicitly set these values. anyDensity == true disables auto-scaling by framework and relies on application to use dp or scaled values anyDensity == false tells framework to try and scale application to fit display – works ok on high res screens, not as well on low res screens.
  • In your res/layout/main.xml and res/layout-land/main.xml file specify where the UI elements should go relative to each other and to the dimensions For instance, in layout/main.xml you can get away with LinearLayout where the buttons place from top to bottom. However in layout-land/mail.xml it may be better to use RelativeLayout and position the buttons in relationship to each other.
  • In onRetainNonConfigurationInstance() implementation, initialize variables or arrays with data that you want to preserve for your future-self. Then in your onCreate() method call getLastNonConfigurationInstalnce(). If not null you can pull the data from the preinitialized variables or arrays.
  • In onRetainNonConfigurationInstance() implementation, initialize variables or arrays with data that you want to preserve for your future-self. Then in your onCreate() method call getLastNonConfigurationInstalnce(). If not null you can pull the data from the preinitialized variables or arrays.
  • Specs categories: General data (platform version, navigation type) Display-specific data (resolution, physical screen) Connectivity (voice bands, bluetooth profiles) Multimedia data (supported media formats) Processor and Memory data (chipset, RAM and ROM values) Sensor data (Types supported) Additional information (supports flash or LBS) Coming soon: Graphics (openGL extensions)

Optimizing your Android App for Mass Market Devices Optimizing your Android App for Mass Market Devices Presentation Transcript