It’s now widely understood that Google will be unveiling the next version of its Android operating system, Ice Cream Sandwich (ICS), next week on the 11th of October. It will launch along with a new flagship phone from Samsung, but along with it is a promise to get the new tasty treat OS on to many of the recently released phones. If they back this up, this means that there will soon be a lot of phones out there running the newest version of Googles OS.
What does this mean for application developers? There are a number of articles out there that speculate on what user interface changes there will be. In particular, there is this supposed walkthrough video that did the rounds a couple of weeks ago:
Other than that video tease, I won’t re-tread the steps of those bloggers today. Instead, I want to talk about what programming changes this will bring to Android developers. Google haven’t released much information about the new API yet (tight lipped buggers!), but they have sent out some information to the Android Developers Blog. Largely it involves using the Honeycomb APIs, but with tweaks to get it to work for phones too. I know that I’ve largely ignored the Honeycomb release, as it was intended solely for tablet developers. By the looks of it, it might be time to get familiar with these APIs, as that’s what we’ll be using a lot of in ICS. Lets have a look at what some of these changes will be:
One App for Tablets and Phones
The most talked about feature of ICS is that it will bring all the Google devices together. Phones, Tablets, and possibly TVs. What this means is that in addition to the varieties of screen sizes that app developers have to deal with, they now have vastly different screens and usage patterns. Up until now, apps written for Honeycomb generally only worked on tablets, and normal phone apps generally didn’t really work properly in full screen mode. In order to deal with this, Google is introducing a fragment based system of laying out views.
A fragment is a section of your user interface that can be composed with other fragments into a whole screen. On a phone, the screen might only be big enough to show one fragment. On a tablet, several fragments can be combined, and can work together.
The handset layout will look like this:
<?xml version="1.0" encoding="utf-8"?> <FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" android:layout_width="match_parent" android:layout_height="match_parent"> <fragment class="com.example.android.TitlesFragment" android:id="@+id/list_frag" android:layout_width="match_parent" android:layout_height="match_parent"/> </FrameLayout>
Whereas the tablet might look like:
<?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="horizontal" android:layout_width="match_parent" android:layout_height="match_parent" android:id="@+id/frags"> <fragment class="com.example.android.TitlesFragment" android:id="@+id/list_frag" android:layout_width="@dimen/titles_size" android:layout_height="match_parent"/> <fragment class="com.example.android.DetailsFragment" android:id="@+id/details_frag" android:layout_width="match_parent" android:layout_height="match_parent" /> </LinearLayout>
The developer will still need to write code to deal with the different layouts and the communications between them, but it is facilitated by the
FragmentManager class. The developer can test for the presence of other fragments, and use this information to decide if he just needs to update that fragment, or start a new Activity to show information.
In the article covering Android Layouts: Resolution and Orientation Solutions we had a look at how Android can deal with different screen sizes. Its widely rumoured that the new Nexus Device will have a resolution of 1280×720 pixels, vastly different from the 480×320 you see on some older devices, so this becomes even more important.
One feature that was added into Honeycomb was a way of specifying minimum screen sizes for layouts, as shown in the Android Docs: Supporting Multiple Screens. To use this, our layout resources can have
Available Screen Width or
Available Screen Hight selectors. As an example, if your layout requires a minimum layout size of 600dp at all times, you could put it in the
Your application manifest can also specify which screen sizes it will work for. As seen in the Android Docs: The Android Manifest.xml File, by using the
<supports-screens> in your application manifest, you can specify the following qualifiers:
- requiresSmallestWidthDp (integer)
- compatibleWidthLimitDp (integer)
- largestWidthLimitDp (integer)
For example, you can cut out handsets, by setting
false. Then your application will not be shown in the market to phones that do not have the qualifying screen sizes. Personally though, I would recommend making your application flexible enough to work on all screen sizes, to maximise your exposure.
Soft Home, Back & Menu Buttons
In the Honeycomb release, Google got rid of the familiar hardware buttons that have been present since the start of Android. Instead, these buttons have been incorporated into the screen layout, present in all activities. In ICS, this approach will also be used in phones.
To my mind, this makes very little difference to the developer. There will still be home, back and menu buttons. They will just be on the screen. It doesn’t change how your application works at all. It doesn’t change the code that you will write to support the buttons.
Another feature Honeycomb introduced was the Action Bar. In earlier versions of Android, an Application’s title bar generally did nothing except show the view’s title, unless the programmer chose to replace it with their own custom title.
Honeycomb introduced the ActionBar to provide a standardised method of showing Tabs, Buttons and Menus in the title bar, saving space and providing a consistent user interface to users. In Ice Cream Sandwich, this is being extended to phone devices as well.
Getting Ready & Supporting Old Android
The Ice Cream Sandwich SDK hasn’t been released yet, but its clear that it will take many of its cues from Honeycomb. Those developers that want to get a head start should start by making sure their app uses the fragment and action bar systems used in Honeycomb. The Compatability Package can be used to ensure that your application, written for Honeycomb/ICS will still work on older devices. In particular, this will allow you to use Fragments on older devices.
Will there be more APIs to play with? Probably, but we’ll have to wait until next Tuesday to find out!