One of the major design goals of SCFFLD has been to facilitate content driven apps.

A content driven app is an app whose user interface and navigation structure is defined by the content being presented. It implies a dynamic UI which is generated according to the needs of the content, with flexible, fluid navigation between different parts of the app content.

The web is the prime example of content driven UIs, with layouts structured around page content, and navigation between pages described using hyperlinks. This flexibility largely exists because web content is text based, and structured using HTML markup (as well as other text based formats such as XML and JSON). Text content makes it inherently easier to dynamically generate pages from source content, and web browsers are based on the prinicipal of fluid navigation via hyperlinks.

In contrast, native mobile app UIs are described in code, or designed using UI builders, layout files, nib files or storyboards, which are then compiled and packaged with the app executable. Static layouts and navigation structures are the natural consequence of this approach. Dynamic layouts and navigation structures require at the leaset additional layers of coding, if not a completely different approach.

Configurations and URIs

Because SCFFLD app configurations are JSON - i.e. text based - they are prime candidates for dynamic generation from content data, allowing the potential to generate a complete app UI description from data. It’s important to note here that SCFFLD doesn’t attempt to be a universal markup language for app UIs. Instead, the approach expected to be taken is that the developer should capture a small number of useful UI patterns for presenting the app content, in code - e.g. as view controller subclasses - and then configure those classes to display different content using SCFFLD configurations. This way, the advantages of a native app UI, tailored for the content, can be combined with the flexibility of dynamic UI description.

Displaying content is one thing, but there is still the need to navigate between different content items and different parts of the app, and SCFFLD’s internal URIs provide a flexible and powerful way to do this. An internal URI can be used to describe a screen that should be displayed in place of the current one, and can instruct the app how to display the new screen (e.g. by pushing onto a navigation stack). Whilst a complete screen configuration can be described in a single URI, it’s normally much more convenient to use a pattern based on a parameterized configuration and to then reference the pattern, along with some parameter values, in the URI. As well as considerably shortening the length of URIs, the principal advantage of this approach is that it allows common UI patterns to be captures in a parameterized configuration and then easily reused to display different content, wherever in the app it might be needed.

An example

A very simple example of the SCFFLD approach uses the built-in WebView component, which as the name suggests, displays content in a web view. For this example, we’re also going to suppose that we’re using a custom layout (this can be described using a NIB file on iOS, or an XML layout on Android). The custom layout will display a banner image above the web view, and on different screens we want to display different banner images with different web content.

We can capture and describe this basic UI pattern using a parameterized configuration:

    {
        "-type":        "BannerLayout",
        "banner": {
            "image":    "$bannerImage"
        },
        "content": {
            "-type":    "WebView",
            "content":  "$content"
        }
    }

A small bit of code is required here, in the form of a view controller class that loads the layout and maps the principal components of the layout to its properties (e.g. using IBOutlet), and the class name then needs to be mapped to the type name BannerLayout in SCFFLD’s type configuration. Once this is done, and the configuration above is dropped into the SCFFLD pattern folder, then the layout can easily be used either extending the configuration or by referencing it from a make: URI, e.g. (assuming the configuration is saved to pattern/BannerLayout.json):

make:BannerLayout+$bannerImage@app:banner1.jpg+$content@app:content/page1.html

This URI basically describes how to make an instance of the BannerLayout pattern, using the provided image and content values.

Navigating to a screen requires an additional layer of information to be given, to instruct the app how to display the screen. This can be done using the post: URI scheme, which is used to send messages between different components of the app. The standard pattern used for app navigation is to send an open message with a view parameter, e.g.:

post:#open+view@make:BannerLayout+$bannerImage@app:banner1.jpg+$content@app:content/page1.html

Whilst this now looks like quite a long and complicated URI, it’s important to remember a couple of things:

  • It’s easy to generate these URIs dynamically from string templates, and -
  • Often, the post: URI isn’t needed, as many SCFFLD UI components will automatically promote non-post URIs to a URI suitable for navigation.