Skip to content

Object instantiation and configuration

Julian Goacher edited this page Feb 12, 2017 · 1 revision

In normal operation, objects are instantiated using their public no-arguments constructor method and then configured by performing dependency injection through their public, writable property setter methods (e.g. methods in the form setXxx taking a single argument). A class which declares a public constructor taking a single Configuration argument will be instantiated using that constructor instead.

Lifecycle methods

Objects may be notified of the configuration lifecycle by implementing the IOCConfigurationAware interface. This declares a couple of methods:

  • beforeIOCConfiguration: Called immediately before dependency injection is performed on an object.
  • afterIOCConfiguration: Called immediately after dependency injection has been completed on an object.

Both methods are passed Configuration being used to configure the object.

Container references

Objects requiring a reference to their container may implement the IOCContainerAware protocol. This declares a single method, setIOCContainer, which will be called with a reference to the current container.

Configuration proxies

One of SCFFLD's aims is to allow object configurations to be shared across platforms. This requires object implementations across platforms to share a common configuration interface, which can be achieved easily when classes are developed with SCFFLD usage in mind, but becomes a problem if pre-existing classes need to be configured. (For example, it can be useful to describe standard UI widgets such as text labels and inputs through a configuration; both iOS and Android provide broadly equivalent implementations of these widgets, but with quite different APIs).

Configuration proxies provide a solution to this problem. A configuration proxy is an implementation of a standard configuration interface which is instantiated by the container in place of another type. The proxy is configured by the container, and then used by the container to build an actual instance of the required type.

Configuration proxies are implemented using the IOCProxy interface. This declares a single method:

  • unwrapValue: Called by the container when the configuration cycle is completed. The proxy should return a fully configured instance of the required type.

In addition, classes implementing the IOCProxy interface should provide a constructor method taking a single argument, that argument being a previously instantiated instance of the value being configured.

The class com.innerfunction.scffld.ui.TextViewIOCProxy is an implementation of the IOCProxy interface, used to configure text field and label objects.

Type inference

The container will perform type inference for configurations that don't declare specific type information (i.e. because the configuration doesn't declare type information using -type or -and:class keywords). For non-collection properties, the container can interrogate the object's property at runtime for its type by examining the declared type of the set method's single argument. For collection properties, the container uses the collection's declared generic type information (if any).

JSON data

SCFFLD uses this term to refer to data that is read from a JSON configuration but is used as data, and not to build and configure an object. So for example, a list object configuration may contain a data property containing the list data which should be injected into the list object as it is read from the configuration, rather than having the container attempt to instantiate objects from the data and inject that into the list.

Object properties accepting JSON data should be declared using the org.json.simple.JSONArray (for list or array data) or org.json.simple.JSONObject (for object or map data) types. These types are used as marker classes, and otherwise provide standard List and Map collection interfaces on the data.