Android Development Becoming More Difficult

android.gifI am of the opinion that it’s not just poorer takeup of Android tablets that has caused there to be few tablet specific android apps. These apps are more difficult to create.

I have recently been looking into using the newer Android Fragments on a project. Fragments provide a way to create multi-panel apps required of tablets. It’s possible, for example, to have two panels show in one screen on a tablet and in their own respective screens on a smartphone.

There are two ways of using Fragments – Android 3.0 Honeycomb specific Fragments or via a compatibility package that provides similar functionality to older (Android 1.6+ Smartphone) devices.

Therein starts the problem of choice. Which do you choose? I figured the compatibility package would be better as it allows for one app for smartphones and tablets.

I got a skeleton app working using Fragments. At this point I realised I now have many more decisions to make over and above those required for an app not produced using Fragments. A Fragment is very similar to an Activity (in layman’s terms a container for a screen) and has a similar lifecyle and functionality. Apps with Fragments still have Activities and they, in fact, usually include layouts that reference the fragments.

Unlike Activities, Fragments can be made to remain in existence when there is a configuration change, for example, an orientation switch. This is great because we used to have to do convoluted things to keep long running tasks (e.g. web server or database access) going on an orientation switch. However, there’s a gotcha in that you still have to be very careful not to access the parent Activity state when the activity isn’t there. This complicates the choice of what you can put in the Fragment and what in the Activity. 

Then there’s the new Loader mechanism for long running taks. It’s not clear in what cases this should be used in preference to AsyncTask. Then there’s the app design itself. Should things like menus (and their handlers) and data access tasks be put in the parent Activity or child fragments? In some cases, it might be best to put them in Activities to prevent redundancy. In other cases they might be put in Fragments so that Fragments ‘manage themselves’ to reduce inter-dependencies and also to take advantage of the previously mentioned ability of Fragments to stay in existence on an orientation switch.

The answers to all these questions depend, to some extent, on the needs of the app itself. However, the lack of patterns how to use Fragments is a great waste of development effort. As Fragments are new, there are very few examples and what’s currently out there is far too simplistic. There are different ways of doing the same thing and it’s not currently clear which way is best and under what circumstances.

There’s a comment on that echos my concerns…

"I am of the opinion that in order to build a stable, robust app, Content Providers, at the very least, are required (for many reasons, the primary one currently being the ability to use LoaderManagers and CursorLoaders). But where was the documentation that explained why this was so? The complete lack of a centralized, high-level overview of Android systems have lead me to several development dead-ends, resulting in rewrites. While I’m wiser for the effort, and have finally settled on a sane, reusable, fairly general pattern for data-driven Android apps, I used up some really valuable development time finding this out. And you know what? Looking at the codebase before my (just-deployed) rewrite, and looking at the Android codebase at the job I left before it, everyone is making these same mistakes, and not many are realizing it until later."

Google needs to create some documentation describing recommended patterns for using the newer Fragments and Loaders or some guidelines as to what to use where under what circumstances.