Update: There is a problem with this method. It appears that the Android framework will not pickup the bool values using any type screen size modifier (e.g. sw600dp or xlarge) because they can change at runtime. It won’t give you an error, instead it’ll just completely ignore the resource and default to true. You can of course achieve the same results in other ways but unfortunately they’re not quite as clean as what i had hoped to achieve below. Sorry!

I already created a tablet app a while back when Honeycomb was first released but since then I’ve been working on phone only applications. Between then and now, the compatibility library has been released and a new way of handling screen sizes has been introduced into the Android framework. Below is a recipe on how to use these features to architect a single apk app that will run on both phone and tablets. Credit to Nick Butcher for inspiration from his talk at Droidcon UK 2011.

1) Encapsulate the functionality that you had (or would have) in your activities into Fragments
A Fragment is, generally, a chunk of a user interface with it’s own lifecycle.  This sounds similar to how you might describe an activity doesn’t it? In fact, if you’re adapting an existing app, you can pretty much cut and paste your code from your old activity into your new Fragment. Then your old activity is only responsible for instantiating your new Fragment and listening to any events that it might trigger.

2) Create completely separate Activities to handle single pane layouts vs dual pane layouts (i.e. phone vs tablet)
Don’t think about hdpi, large or xlarge buckets any more. Think more like a responsive web designer e.g. here is my single pane layout for screens less than 600dp and here is my dual pane layout for screens wider than 600dp.

By way of example, an imdb style app might have two fragments: MovieListFragment (to show a list of movies) and MovieDetailFragment (to show the movie detail).

When designing for the single pane layout (e.g. for phones) you would most likely have two activities:

  • SingleMovieListActivity – which is where the MovieListFragment would live and
  • SingleMovieDetailActivity – which is where the MovieDetailFragment would live

Pretty simple eh? For the dual pane layout (e.g. tablets) you would have something like:

  • DualHomeActivity – which would house both Fragments; MovieListFragment (on the left) and MovieDetailFragment (on the right).

Keeping them separate means that you don’t have messy code within your activites to detect which screen mode you are in before you can show or act on anything.

3) Use the (force) framework
You don’t need a splash activity to detect how many pixels are on screen before you forward to an appropriate starter activity. Simply add something like android:enabled=”@bool/single_pane” to any single pane activity elements within your Android Manifest. Then create the file res/values/bools.xml with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<resources>
<bool name="dual_pane">false</bool>
<bool name="single_pane">true</bool>
</resources>

Handling the dual screen activities is also quite simple. Add android:enabled=”@bool/dual_pane” to any dual screen activity elements within your Android manifest. Then create the file res/values-sw600dp/bools.xml with the following contents:

<?xml version="1.0" encoding="utf-8"?>
<resources>
<bool name="dual_pane">true</bool>
<bool name="single_pane">false</bool>
</resources>

Now if your app is started on a device that has a width of at least 600dp (e.g. a tablet) then the framework will enable all of your dual pane activities and disable all of the single pane ones. Conversely, if your app is started on a device with less than 600dp then all single pane activities will be enabled and the dual pane ones will be disabled.

Note that the sw600dp modifier will only work for Android 3.2 and above so you should also copy the above bools.xml to res/values-xlarge/bools.xml to cater for the extra large screens in older versions of Android.

4) Decouple communication
So you have all these reusable fragments…but they can exist in different activities depending on whether you’re running on a device that has a width of more or less than 600dp. How does your fragment know whether to transition to a new screen or whether to animate in a new fragment when a movie is selected? The answer of course is that it doesn’t and shouldn’t.

The enclosing activity knows whether you are in single vs dual pane mode so you need a clean way to communicate your event (e.g. movie selected) to this enclosing activity. There are a few ways to do this but my favoured way is to use Broadcast Intents. Your enclosing activity (which is listening for these defined events) can intercept a broadcast intent and associated parameters and then decide whether to transition to a new activity (if in a single pane activity) or whether to replace the currently showing MovieDetailFragment (if in a dual pane activity).

Simples.

Advertisements