Many core Android APIs can be challenging to use, with poorly designed implementations which reflect competing or unclear design goals. Often, Android APIs put too much cognitive load on the developer, exposing them to low level details which could (and should) be hidden, or forcing the developer to code multiple steps which could (and should) be automated by the API. This inevitably leads to increased complexity, and Android Fragments are one of the best examples of what results.

The design rational behind Fragments is a good one, but the resulting implementation is anything but good, suffering from poor design choices and shifting implementation goals. An excellent summary of the problems can be found in this article by Pierre-Yves Ricau, who is a lead developer for Square. In the article, as well as enumerating the very many problems he’s encounted when using Fragments, he also suggests a simple solution - roll your own - with some clear guildlines on how to go about the task.

Following the same rational, SCFFLD on Android doesn’t use Fragments in its core UI components. Instead, SCFFLD provides a class, ViewController, which is intended as a replacement for Android Fragments. The name is obviously borrowed from iOS’s UIViewController class, but whilst the Android namesake performs a very similar role, it isn’t a port of the iOS class to Android.

The SCFFLD ViewController class fulfills the same design role as Fragments, i.e. it allows a chunk of UI functionality to be defined as a collection of UI components, within a common layout, and sharing common model and controller code. View controllers can then be used to describe a full screen worth of UI, or used as composite parts describing discrete sections of a multi-panel screen. View controllers can also be embeded as sub-views of a parent view controller.

The ViewController code is actually pretty simple, and provides the following capabilities:

  • A simplified, dependable view life cycle;
  • The ability to inflate view layouts, and to inject component views into layouts;
  • The ability to add UI behaviours as decorations of the view controller class;
  • The ability to control title bar (i.e. action bar) state from within nested controllers;
  • Event handling.

The view controller code is kept simple by simply ignoring a lot of the design concerns of Fragments, particularly regarding behaviour on low-spec devices.

SCFFLD also provides a special activity class, ViewControllerActivity, for use with view controllers (it’s use isn’t absolutely necessary, but it ensures that a lot of SCFFLD functionality, particularly to do with UI navigation, works as expected).

Future implementations of SCFFLD will include code to automatically handle and route activity results, and will greatly simplify operations such as taking a photo from the device camera.

More information on view controllers is available in the SCFFLD wiki.