Examples

This section contains a couple of examples of SCFFLD configurations.

Simple example

The following configuration describes a UI screen showing a web view which loads and displays an HTML file packaged with the app:

{
    "-type":            "WebView",
    "backgroundColor":  "#FFFFFF",
    "contents":         "@app:example.html"
}

The configuration uses one of the standard, built-in SCFFLD types, WebView. This allows the configuration to be read and loaded on either iOS or Android. The view is displayed with a white (#FFFFFF) background color, and loads its contents from the example.html file.

This configuration should be saved in a file named RootView.json and placed into the SCFFLD/named folder of an app project. The RootView named object is used to indicate the first screen loaded by an app after it starts.

A more complicated example

The following example shows a UI pattern described using a configuration template and a custom layout class.

{
    "-type":            "BannerLayout",
    "mainView":         "$MainView",
    "bannerView":       "$BannerView"
}

This example supposes that a custom layout class has been created on each target platform, with its class name mapped to the standard type name BannerLayout. The custom layout class is implemented according to the target platform conventions - e.g. using an XIB file on iOS, or a XML layout file on Android - and has two properties, named mainView and bannerView which it inserts into the layout when it is displayed. (Note that SCFFLD provides standard methods for performing much of this).

The configuration as shown doesn't do much, as no values are specified for mainView or bannerView, just parameter placeholders. As such it is a component pattern, described as a configuration template. Patterns should be stored in the SCFFLD/patterns folder, e.g. as SCFFLD/patterns/BannerLayout.json in this case.

Once the pattern is created, it can be used as follows:

{
    "-extends":     "@pattern:BannerLayout",
    "$BannerView":  "@new:WebView+contents@app:banner.html",
    "$MainView":    "@new:WebView+contents@[app:example.html]+backgroundColor=%35FFFFFF"
}

This configuration extends the pattern defined previously, and provides values for the pattern's two configuration parameters. Note that all the configuration values are specified using internal URIs (with the @ prefix). The values of the two configuration parameters are described using the new: URI scheme, which can be used to instantiate and configure an object of the specified type. (Note also that the $MainView property value describes essentially the same view component as in the first example above).

This configuration file may be saved somewhere on the device's filesystem, e.g. in the app's cache directory. The make: URI scheme can then be used to load the configuration and instantiate the component it describes:

make:+config@cache:/views/ExampleView.json

We can also use internal URIs to describe a UI navigation event, using SCFFLD's message passing mechanism and the post: URI scheme. The post: scheme is used to build a SCFFLD message and send it to a named component. The SCFFLD app container is always bound to the name 'app'. The app container can be told to display a new UI screen view by sending it a show message which has the new view to display specified as a parameter. So to make the app container display the view component described above, we can send it a show message using the following URI:

post:app#show+view@[make:+config@cache:/views/ExampleView.json]

Such URIs can be used to specify actions within configurations (e.g. as an action to be performed when a button is tapped) but can also be used as hyperlinks within HTML pages, when displayed using SCFFLD's standard web view component.