Android 4.0 for Developers

android.gifThe web is full of articles describing how Android 4.0 changes things for end users. This article is slightly different in that it describes my initial thoughts from a developer viewpoint.

New APIs on any mobile platform pose a problem for developers. The APIs aren’t available yet on a large number of user phones which means either…

  • Programming around them (using relection) to take advantage of them where you can, or
  • Producing special versions of apps only for the latest phones, or
  • Waiting until a large number of phones have the API or
  • Using the new APIs in a vertical (specialised) app where the device version can be guaranteed (i.e. Some Enterprise apps or apps for devices that aren’t owned).
In practice, most developers of consumer apps don’t have the resources to program around differences in APIs. This means that new APIs announced now tend to represent what will be used in apps written in a year or two’s time. For example, only very recently did it become viable to release an Android 2.2 app and expect it to be installed on a large number of devices.

Having said all this, here’s a summary of the new APIs

  • Fragments and content loaders
  • Resizeable home screen widgets
  • Rich notifications
  • Multi-selection, drag-drop, clipboard
  • Improved screen-support API
  • Hardware-accelerated 2D graphics
  • Graphics and animation
  • Property-based animation
  • Renderscript 3D graphics
  • Media and connectivity
  • HTTP Live streaming
  • Bluetooth A2DP and HSP devices
  • Support for RTP
  • MTP/PTP file transfer
  • DRM framework
  • Input from keyboard, mouse, gamepad, joystick
  • Enterprise
  • Full device encryption
  • DPM policies for encrypted storage and passwords

One area all Android developers will be wondering about is the promise that Android 4.0 would bring together smartphone and tablet development back under one Android version. Previously you needed to program for up to 2.3 for smartphones and 3.x for tablets or use the compatibility package to allow one APK to support both smartphones and tablets. Looking at the APIs, I can’t yet see anything significant has changed with respect to the UI. Maybe it’s just that we will see both smartphone and tablet devices running 4.0. This doesn’t mean much in the short term because, as I said, there won’t be many 4.0 end user devices for a while. Until there’s a significant number of devices, developers will have to continue to use the compatibility package to allow use of smartphone and tablet in one APK.

Speaking of the compatibility package, I notice this has also been updated to v4 which makes the new accessibility and ViewPager APIs available to Android 1.6 and higher. It’s a shame Google couldn’t have also provided many more of the new 4.0 APIs.

Digging deeper into the Android 4.0 API, two areas I have identified as useful now on more vertical apps are peer to peer WiFi and face recognition.

One end user feature that will affect developers, in time, is the Data Usage facility within Settings. In Google’s words…

"Colorful charts show the total data usage on each network type (mobile or Wi-Fi), as well as amount of data used by each running application. Based on their data plans, users can optionally set warning levels or hard limits on data usage or disable mobile data altogether. Users can also manage the background data used by individual applications as needed."

This ties in with my past articles on how developers will, with increasingly data capped tariffs, need to start thinking a lot deeper about data usage.

Related Articles:

Comments are closed.