Application Context Management

The Application Context Management (ACM) represents the conceptual approach to configure the potential visualization and management of objects on the client. Objects, its properties and relations can be used to set up a user defined behavior including the creation of new objects, documents, etc. For each type of object its characteristics with respect to hierarchy and its properties can explicitly be managed by the user.

Along with the object oriented configuration, the user might also customize the logo and background images for the mobile application to enhance the users' experience.

UBIK^® provides specific objects and tools for configuration and testing of the ACM environment and the result being published to the mobile client.

How the ACM works

Technically, the ACM can be explained separating the following topics:

Application and Context
Scopes
View and View Items
Meta Definitions

Application and Context

An Application is used to identify Contexts. A Context is used to identify a View and all relevant Scopes. UBIK^® satellites use these two in order to identify the View that provides data for them, as well as the Scopes that decide what the data looks like. The Application's and Context's names have to be configured in the client's settings. One could say the Context is the central object in every ACM configuration, connecting all the details.

Scopes

Scopes define what a UBIK^® object and its properties look like to a UBIK^® satellite. Let's say we have a pump with a lot of properties (that can be used for automatic data processing), but these properties aren't of much use to a human user. In this case, if I publish such pump objects to the user's mobile client (aka. UBIK^® satellite) via ACM, I probably want to give the user a more convenient, specialized version of these objects, containing only useful properties. With Scopes, one can define what an abstract content object should look like. One could say, they are post-processing filters for Meta Classes. Specifically, you can define which properties are visible, decide which classifications are published and configure rights (e.g. for writing a property value or creating instance objects for the Scope).

View and View Items

The View defines the hierarchical representation of all objects that should be available. The object's look & feel is described by Scopes, but the connection between those objects is described by the View. For example, if I have a root object Station A and as its child, I have an object Unit A.1, then the View describes that Unit A.1 is a child of Station A. Technically, the view uses View Items in order to describe the connection of objects. View Items are defined for a Meta Class, e.g. for the Meta Class Station, and can provide the children for specific instances of such a Meta Class. In our example, if we have a View Item responsible for getting the Unit-children of a Station, for Station A (which is an instance of the Meta Class Station) it would retrieve Unit A.1. There are different types of View Items, depending on how the children should be resolved technically. The following types exist:

Reference View Item (only 1 : N relations)
Relation View Item (N : M relations possible)
Query View Item (complex, custom child evaluation possible)

Reference View Items use a reference from each child to the parent in order to evaluate the children in a backward manner. Relation View Items use relations from parents to children, where each parent can have multiple children and vice-versa, every child can have multiple parents. Query View Items use a query to evaluate the children, but the parent object has to be the respective query object. A View can have multiple view items for the same Meta Class (target type) in order to make a complex structure possible.

Meta Definitions

Last but not least, the UBIK^® satellites need to get Meta Definitions in order to interpret and use the content correctly. Meta Definitions describe (abstract) Meta Classes, Selective Lists, Units and rights as well as some information about the view structure, e.g. possible children of an element (in case the user wants to create a new object, like a picture for example). The Meta Definitions are a result of the Scopes and the View for a specific Context. The customizer has to publish these Meta Definitions actively though, using the ACM Manager.

Objects

Name	Description
Application	Aggregates a range of contexts
Context	Aggregates a range of scopes and serves as configuration object for the hierarchy and object structure published to the mobile application
MetaClassScope	Specifies the MetaClass and its published properties as well as permissions granted on those objects
QueryScope	Specifies the Query and its published search properties
Satellites	Configuration of allowed devices to connect to the system

Tools

Name	Description
ACM Manager	Administration and testing of the objects structure, creating and editing customization settings for the client user interface
View Test Environment	Perform a dry-run of created or modified views, e.g. to check the resulting objects of the different levels.