Skip to content

View controllers

Julian Goacher edited this page Mar 3, 2017 · 4 revisions

SCFFLD provides the class as a lightweight alternative to Android Fragments.

Like a Fragment, a ViewController allows a modular portion of a UI's appearance and behaviour to be described within a single class. A screen within the UI can be described using a single view controller instance, or as multiple separate view controllers compounded into a single root view controller instance.


View controllers provide a simplified and well-defined life cycle, compared to fragments. A view controller life cycle has the following states:

  • Instantiated: A view controller's initial state after class instantiation.
  • Attached: Entered once the view controller has been attached to an activity.
  • Started: Entered once the parent activity has been started.
  • Running: Entered once the view controller is fully active, i.e. is fully visible on screen.
  • Paused: Entered when the view controller is temporarily suspended, e.g. if hidden on screen by another view.
  • Stopped: Entered when the the parent activity is stopped.
  • Destroyed: Entered when detached from the parent activity, immediately before the view instance is discarded.

Any view controller instance will move reliably and predictably through all relevant states (e.g. a view will always transition through Instantiated, Attached and Started before entering Running).

Title bars

View controllers provide a titleBar property which allows a title and and actions for the view to be configured and then displayed in the activity's action bar. Title bars also support compounded behaviour, allowing a view controller composed of multiple child view controllers to display actions defined on those child view controllers.


View controllers can be configured to load and display a named layout, using its layoutName property. For example, setting layoutName to accountscreen will load the layout named accountscreen.xml from the app's layout resources.

A layout may contain placeholder views which are replaced at runtime with view components instantiated by the SCFFLD container. This works as follows:

  • Placeholder views are defined in the layout with a unique id attribute. (The placeholder can be any type of view, but normally an empty View element is all that is required).
  • The view controller used to load the layout is configured with the replacement views using its layoutComponents property. This is a map of view component IDs or names onto component configurations; the SCFFLD container will instantiate and configure the components before injecting the component map into the view controller.
  • After the view controller loads its layout, it iterates over the map of view components and checks if the layout contains a view element with a matching ID; if a match is found then it replaces the view in the element with the matching view component.

Message routing

A view controller will automatically route messages to named child components contained by it.


The standard UI pattern used by SCFFLD is to put all UI specific code within sub-classes of ViewController and then to use the standard ViewControllerActivity to display those views.

It is possible to use SCFFLD with custom activity classes, but some SCFFLD functionality may be lost.

You can’t perform that action at this time.