Base components

The framework is set up to be lightweight. You basically need an OCSObjectContext which serves as a container for managed objects. To configure such an ObjectContext, reliant uses an OCSConfigurator instance. A configurator is responsible for providing object definitions, which are kept in OCSDefinition objects. A definition gives an object:

• a name (also called key), so it can be identified
• a scope
• optionally some aliases

Reliant makes sure no two objects have the same name or alias within the same context.

An object context uses an OCSObjectFactory to create objects based on the definitions provided by the context's configurator.

A context can keep track of objects through OCSScope objects. Out-of-the-box, Reliant provides two scope implementations: singleton and prototype.

The names of these scopes were taken from well known design patterns

Singleton

Objects in this scope will have only one instance for the object context they belong to.

Do not think of these as the pure singleton. Typically in Objective C, a pure singleton has a static sharedClassName method, which always returns the same instance. The best known singleton in iOS is UIApplication. Pure singletons however are often being referred to as anti-patterns, because they open doors to keeping global state and worse, they make it hard to decouple code from this singleton. Because of these remarks, it is important to note that a singleton scope does not force your object to be a pure singleton, it merely defines the object instance as unique to a specific context.

When you define an object as singleton, it should not hold state. This is important, because once a singleton object holds state, that state has the potential of becoming shared state between different components on different threads. This often causes unwanted side effects and concurrency problems.

Eager or lazy?

Reliant further identifies eager and lazy singletons. Eager means that they will be instantiated when the object context is started, lazy means they will be instantiated Just-in-Time, when they are needed.

Prototype

A prototype is the exact opposite of a singleton in that it will be created each time it is requested from the object context. These objects can keep state. Be careful though! If you inject a prototype into a singleton, the prototype's lifecycle is bound to that singleton! As a result, you probably should never inject a prototype into a singleton.

Context hierarchy

An object context can also have a parent context. Whenever a context cannot find an object for a given name or alias, it will consult its parent context for that object. This also means that a child context can override an object definition of its parent.

Parent contexts are useful when you look at your application in modules. Each module might have its own context. These contexts hold only those objects relevant to their specific module. Now, if each module needs the same object, you can define that object in a separate context, and make that context parent of all the module contexts. Please have a look at our example application, which gives you a quick overview on how to set this up.

Related pages

To see how all these components are glued together, please read our readme, our wiki page about the OCSConfiguratorFromClass and our Example application. For a full overview of Reliant's classes, checkout cocoadocs.org