The main purpose of SCFFLD is to build objects by first instantiating them, and then by injecting values into the object's named properties in order to configure them. An object's properties may themselves be objects which need to be instantiated and configured.
There are a small number of core concepts used by SCFFLD.
A configuration is something - typically a JSON file - which describes an object to be built and the values it is to be configured with. Because an object's values may themselves be objects, it's possible for a configuration to describe a complete and complex object graph composed of many separate individual objects.
A container is the thing which loads a configuration and converts it into its represented object graph by building each of the objects it describes. The resulting objects can then be requested from the container. An app typically only needs one container, but system modules may also be implemented as separate containers.
SCFFLD implements an internal URI space as a mechanism for addressing, referencing and describing different parts or components of a system. It is a powerful and flexible mechanism that is used extensively throughout SCFFLD.
These are named components of the system. They are typically the components described in the top level of a container's configuration, although app containers also allow additional named components to be defined separately. Nameds allow components required across a system to be easily discovered under standard, global names.
Services are special components with a simple start / stop lifecycle. Service components need to implement a special interface (on Android) or protocol (on iOS). The SCFFLD container will then start the service component once it is fully configured and added to a running app; and the container will stop the service when it is removed from the app, or when the app itself is stopped.
SCFFLD follows the following procedure when building an object:
Configurations allow values to be shared across objects and this may lead to situations where an object is about to be configured with a value before that value has itself been instantiated and configured. SCFFLD is able to detect these situations and perform Implicit Dependency Ordering (IDO) to ensure that objects are built in dependency order. SCFFLD also allows circular dependencies, but with certain caveats; see the containers section.