Archives for 11 Feb,2010

You are browsing the site archives by date.

Supporting multiple phones and screensizes in your android applications

When releasing an android application it is often desirable to release your application to the largest amount of users as possible. By developing an application with android 1.5 as the target, later versions are automatically supported (1.6, 2.0, and 2.1). However different screen-sizes were introduced with android 1.6 so by default an application will not support smaller screens (larger screens are automatically supported).

Android Versions Marketshare
The image below shows the current market share for the different version of android:

Android version percentages

Android version marketshare

Android Platform Percentage of Devices
1.1 0.3%
1.5 27.7%
1.6 54.2%
2.0 2.9%
2.0.1 14.8%

Devices with small screens include the following phones T-Mobile G1, Samsung I7500, and the HTC Tattoo. Unfortunately I cannot find any statistics regarding the percentage of small screen android users (if you can please let me know). However as the fix is very simple it seems stupid not to.

Which version of android are you using?

View Results

Loading ... Loading ...

What screen size are you running android on

View Results

Loading ... Loading ...

Adding Support
To add support for different screen sizes we need to add a supports-screens tag in our android_manifest.xml. This should look like the following:

  <supports-screens
          android:largeScreens="true"
          android:normalScreens="true"
          android:smallScreens="true"
          android:anyDensity="false" />

This tells android that the application should work on large, normal and small screens. Note that only setting small to false will prevent it from been visible in the market to small screened phones, for normal and large it will simply change the method of which android interprets the display of this application. anyDensity fix me

However in order to use the supports-screens tag the target of your application must be android 1.6 (or Sdk version 4). We can allow our program which is now targetted for android 1.6 still be avaliable for android 1.5 (Sdk version 3) by adding android:minSdkVersion=”3″ to our uses-sdk tag.

<uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"/>

Now your application can be built for 1.6 supporting smaller screen sizes and still work on 1.5.

Demonstration
Below are screenshots from two AVD’s, one with a normal screen size, and one with a small screen size:

android small screen wordcube

small screen android AVD running wordcube


android medium screen wordcube

Medium screen android AVD running wordcube

Note: Eclipse bug
Unfortunately eclipse currently does not acknowledge minSdkVersion and will not give you the option to test your application in any android virtual devices (AVD’s), while this is not fixed you can manually install the package into your AVD. For this you need to know the name of your emulator instance, to do this first run the AVD and then use the followin command to find out the name.

$adb devices
List of devices attached
emulator-5554   device

So we can see that the emulator instance I need is called emulator-5554. We can now use adb to install a package into this emulator. The below example shows installing wordcubefree from the bin folder in my project to my AVD using adb.

adb -s emulator-5554 install ~/android/workspace/WordCubeFree/bin/WordCubeFree.apk
1019 KB/s (39683 bytes in 0.038s)
Can't dispatch DDM chunk 46454154: no handler defined
Can't dispatch DDM chunk 4d505251: no handler defined
        pkg: /data/local/tmp/WordCubeFree.apk
Success

Note that this will fail if the application is already installed and you will need to uninstall the application before using this command (if anyone knows a switch to force install or alternative method please let me know)

Going Further
It is possible to delve into this is more detail by providing layouts for small, medium and large screen sizes. This can be explored in more detail in the google dev support guide

Read More

Android: Using SVN with your app’s project (and eclipse)

When creating any non-trivial program using a versioning system is essential, especially when working in part of a group. This guide aims to be a quick tutorial to the SVN (subversion) tool for versioning and how to use it with an android project.

Assumptions

  • You will need SVN installed on your computer. This can be done using your package manager or by the following command in ubuntu / debian based systems:

    sudo apt-get install subversion
  • You already have an SVN repository configured. If not please view a tutorial like this or if you have a nice webhost like me (thanks dreamhost 😛 ) there may be a simple tool to do this automatically for you in your panel.

Note
Don’t include the files inside /bin or /gen as they are just build from the source code and will simply fill up a lot space in your SVN. But do include the folders themselves as the project will fail to build without them.

Command line (recommended)
For SVN, I am a great fan of the command line. From the few SVN GUI applications that I have used in the past I can recommend Turtoise SVN for windows and kdesvn for linux (kde) but I still prefer the command line.

The following code will checkout the project from your server. This will create a new folder called “projectname” on your computer and download the project from your server (at this point it is most likely an empty folder).

# Checkout the SVN directory
svn co svn.yourdomain.com/projectname projectname

You can then copy or create your android project in this directory. In our project folder there are two folders which contain generated files (as opposed to source files) there is no point uploading these to the svn as you will simply take up space and bandwidth. Before you decided to upload your changes to the server you should empty the bin and gen folders:

# Empty bin and gen folders
rm -rf ./projectname/bin/*
rm -rf ./projectname/gen/*

Each time you add a new file to the project you will need to add (`svn add filename` for single files or `svn add *` for all files):

# Tell SVN we want to be versioning these files
svn add projectname/*

When you are happy with your changes you can commit (`svn commit -m “message”`) your changes to the svn to create a new version, it is mandatory to include a message with each revision and it is best to be as detailed as possible with the changes made. This makes it much easier to hunt down where a bug or regression was introduced.

# Save the changes and upload to repository
svn commit -m "Initial import of projectname"

Each time you commit or wish to upgrade what is stored locally to the latest version on the server you need to use the following:

# Update the locally stored version
svn update projectname

Further points
Eclipse has a plugin to manage SVN download and install instructions can be found here.

Read More