Classes

Supports decoding of any Coaty object, either as a core type or as a custom, i.e application-specific object type.

If the Coaty object type specified in the decodable JSON object has been registered as a Swift class, an instance of the corresponding class type is created with all core type and custom type properties filled in. Any extra fields present on the decodable object are ignored.

Otherwise, if the Coaty object type has not been registered, an instance of the core type class as specified in the decodable JSON object is created with all core type properties filled in. Additionally, any other field present on the decodable object is added to the custom dictionary property of the created instance.

The second approach is especially useful if you want to observe custom Coaty objects whose object type is not known at compile time so that no Swift class definition exists for them.

Custom implementation of a UUID that actually is compatible with the RFC 4122 V4 specification of defining UUIDs (lowercase in contrast to Apple’s uppercase implementation).

PayloadCoder provides utility methods to encode and decode communication events from and to JSON.

AdvertiseEvent provides a generic implementation for advertising CoatyObjects.

Defines event data format for advertising objects.

Associate event

Defines event data format to associate or disassociate an IO source with an IO actor.

CallEvent provides a generic implementation for invoking remote operations.

CallEventData provides the entire message payload data for a CallEvent.

ChannelEvent provides a generic implementation for broadcasting objects through a channel.

ChannelEventData provides the entire message payload data for a ChannelEvent including the object itself as well as associated private data.

CommunicationEvent is a generic supertype for all defined Coaty event types.

CommunicationEventData provides the generic type required by the CommunicationEvent. Note that this cannot be a type alias since we need it to be an actual class.

CompleteEvent provides a generic implementation for responding to an UpdateEvent.

CompleteEventData provides the entire message payload data for a CompleteEvent including the object itself as well as associated private data.

DeadvertiseEvent provides a generic implementation for deadvertising CoatyObjects.

DeadvertiseEventData provides the entire message payload data for a DeadvertiseEvent.

DiscoverEvent provides a generic implementation for discovering CoatyObjects. Note that this class should preferably be initialized by its withObject() method.

DiscoverEventData provides the entire message payload data of a DiscoverEvent.

IoState event.

This event is internally emitted by the observable returned by CommunicationManager.observeIoState.

Defines event data format for association/disassociation related to a specific IO source/actor.

This data is emitted by the observable returned by CommunicationManager.observeIoState.

Undocumented

Undocumented

QueryEvent provides a generic implementation for querying CoatyObjects.

QueryEventData provides the entire message payload data for a QueryEvent.

ResolveEvent provides a generic implementation for responding to a DiscoverEvent.

ResolveEventData provides the entire message payload data for a ResolveEvent including the object itself as well as associated private data.

RetrieveEvent provides a generic implementation for responding to a QueryEvent.

RetrieveEventData provides the entire message payload data for a RetrieveEvent including the object itself as well as associated private data.

ReturnEvent provides a generic implementation for responding to a CallEvent.

Undocumented

Undocumented

UpdateEvent provides a generic implementation for updating a CoatyObject.

Defines event data format for update operations on an object.

Provides a set of predefined communication events to transfer Coaty objects between distributed Coaty agents based on the publish-subscribe API of a CommunicationClient.

Keeps track of agents or specific Coaty objects in a Coaty network by monitoring agent identities or custom object types.

This controller observes advertisements and deadvertisements of such objects and discovers them. Changes are emitted on corresponding observables that applications can subscribe to.

You can use this controller either standalone by adding it to the container components or extend your custom controller class from this controller class.

If you want to keep track of custom object types (not agent identities), you have to implement the remote side of the distributed object lifecycle management explicitely, i.e. advertise/readvertise/deadvertise your custom objects and observe/resolve corresponding Discover events. To facilitate this, this controller provides convenience methods: advertiseDiscoverableObject, readvertiseDiscoverableObject, and deadvertiseDiscoverableObject.

Usually, a custom object should have the object ID of its agent identity, i.e. Container.identity, set as its parentObjectId in order to be automatically deadvertised when the agent terminates abnormally. You can automate this by passing true to the optional parameter shouldSetParentObjectId of method advertiseDiscoverableObject (true is also the default parameter value).

Describes information used to connect to a specific database server using a specific database adapter.

Supports basic routing of data from IO sources to IO actors based on an associated IO context.

This class implements a basic routing algorithm where all compatible pairs of IO sources and IO actors are associated, not taking any other context information into account. An IO source and an IO actor are compatible if both define equal value types in equal data formats.

Note that this router makes its IO context available by advertising and for discovery (by core type, object type, or object Id) and listens for Update-Complete events on its IO context, triggering onIoContextChanged automatically.

This router class requires the following controller options:

• ioContext: the IO context for which this router is managing routes (mandatory)

Provides convenience methods for observing IO values and for monitoring changes in the association state of specific IO actors.

Base IO router class for context-driven routing of IO values.

This router implements the base logic of routing. It observes IO nodes that are associated with the router’s IO context and manages routes for the IO sources and actors of these nodes.

This router implements a basic routing algorithm where all compatible pairs of IO sources and IO actors are associated. An IO source and an IO actor are compatible if both define equal value types in equal data formats. You can define your own custom compatibility check on value types in a subclass by overriding the areValueTypesCompatible method.

To implement context-specific routing strategies extend this class and implement the methods marked with the fatal error: “This method must be overridden”

Note that this router makes its IO context available for discovery (by core type, object type, or object Id) and listens for Update-Complete events on its IO context, triggering onIoContextChanged automatically.

This base router class requires the following controller options:

• ioContext: the IO context for which this router is managing routes (mandatory) Otherwise a fatalError is thrown

Provides data transfer rate controlled publishing of IO values for IO sources and monitoring of changes in the association state of IO sources.

This controller respects the backpressure strategy of an IO source in order to cope with IO values that are more rapidly produced than specified in the recommended update rate.

Supports rule-based routing of data from IO sources to IO actors based on an associated IO context.

Define rules that determine whether a given pair of IO source and IO actor should be associated or not. A rule is only applied if the value type of IO source and IO actor are compatible. If no rules are defined or no rule matches no associations between IO sources and IO actors are established.

You can define global rules that match IO sources and actors of any compatible value type or value-type specific rules that are only applied to IO sources and IO actors with a given value type.

By default, an IO source and an IO actor are compatible if both define equal value types in equal data formats. You can define your own custom compatibility check on value types in a subclass by overriding the areValueTypesCompatible method.

Note that this router makes its IO context available by advertising and for discovery (by core type, object type, or object Id) and listens for Update-Complete events on its IO context, triggering onIoContextChanged automatically.

This router requires the following controller options:

• ioContext: the IO context for which this router is managing routes (mandatory)
• rules: an array of rule definitions for this router. The rules listed here override any rules defined in the onInit method.

Represents an annotation

Variant object composed of a description key and a download url

The base type of all objects in the Coaty object model. Application-specific object types extend either CoatyObject directly or any of its derived core types.

Represents the unique identity of a Coaty container.

Defines meta information of an IO actor.

Represents the context of IO routing.

An IO context is associated with an IO router that can use its context information to manage routes.

Represents an IO node with IO sources and IO actors for IO routing.

The name of an IO node equals the name of the IO context it is associated with. An IO node also contains node-specific characteristics used by IO routers to manage routes.

Defines meta information of an IO point.

This base object has no associated framework base object type. For instantiation use one of the concrete subtypes IoSource or IoActor.

Defines meta information of an IO source.

Object model representing location information including geolocation according to W3C Geolocation API Specification.

This interface can be extended to allow additional attributes that provide other information about this position (e.g. street address, shop floor number, etc.).

Represents geolocation information according to W3C Geolocation API Specification.

This version of the specification allows one attribute of type GeoCoordinates and a timestamp.

Represent geographic coordinates. The reference system used by the properties in this interface is the World Geodetic System (2d) [WGS84].

Represents a log object.

Information about the host environment in which a Log object is created. This information should only be logged once by each agent, e.g. initially at startup.

Represents a snapshot in time of the state of any Coaty object.

Represents a task or task request.

Object model representing users as defined by the SCIM 2 standard according to RFC7643.

Note that the SCIM userName property is represented in the name property of the base CoatyObject type.

The components of the SCIM user’s name. Service providers MAY return just the full name as a single string in the formatted sub-attribute, or they MAY return just the individual component attributes using the other sub-attributes, or they MAY return both. If both variants are returned, they SHOULD be describing the same name, with the formatted name indicating how the component attributes should be combined.

Undocumented

Undocumented

Defines criteria for filtering and ordering a result set of Coaty objects. Used in combination with Query events and database operations, as well as the ObjectMatcher functionality.

Determines the ordering of result objects by an array of (property name, sort order) tuples. The results are ordered by the first tuple, then by the second tuple, etc.

Defines the format of nested properties used in ObjectFilter conditions and orderByProperties clauses. Both dot notation ("property.subproperty.subsubproperty") and array notation (["property", "subproperty", "subsubproperty"]) are supported for naming nested properties. Note that dot notation cannot be used if one of the properties contains a dot (.) in its name. In such cases, array notation must be used.

Defines a set of conditions for filtering objects. Filter conditions can be combined by logical AND or OR.

An object filter condition is defined by an object property name - object filter expression pair. The filter expression must evaluate to true when applied to the object property’s value for the condition to become true.

A filter expression consists of a filter operator and an operator-specific number of filter operands (at most two).

Tip: use one of the typesafe FilterOperations functions to specify a filter expression.

Defines filter operator functions that yield object filter expressions.

Convenience builder class for ObjectFilter objects.

Convenience builder class for ObjectFilterCondition objects.

Convenience builder class for ObjectFilterConditions objects.

Defines a condition for joining related objects into a result set of Coaty objects. Result objects are augmented by resolving object references to related objects and by storing them in an extra property of the result object. Used in combination with Query events.

Represents package, build and release information about a Coaty agent.

Agent information is generated when the agent project is build and can be used at run time, e.g. for logging, display, or configuration.

Represents information about the agent’s package, such as Swift package format or Cocoapods.

Represents information about agent build.

Represents information about agent configuration.

Defines the application-specific container components to be registered with a Coaty Container.

Convenience class for building a configuration.

Configuration options for Coaty container components, such as controllers, communication manager, and runtime.

Common options shared by container components.

Options used for communication

Controller options mapped by controller class name.

Controller-specific options.

Database access options mapped by a unique database key.

MQTT client options for the CocoaMQTT client.

An IoC container that uses constructor dependency injection to create container components and to resolve dependencies. This container defines the entry and exit points for any Coaty application providing lifecycle management for its components.

The base controller class.

Provides access to runtime data of a Coaty container, including shared configuration options, as well as platform and framework meta information.

Defines a time interval using the number of milliseconds since the epoc in UTC instead of ISO 8601 standard time intervals. This is used for consistency within the system.

A valid interval can have four formats:

• start and end timestamps
• start timestamp and duration
• duration and end timestamp
• duration only

Four different initializers, one for each format case ensure that this object always has a correct format.

The ISO 8601 standard string can be created using the function toLocalTimeIntervalIsoString which is a part of this class.

An Observation results in a value being assigned to a phenomenon. The phenomenon is a property of a feature, the latter being the FeatureOfInterest of the Observation. In the context of the Internet of Things, many Observations’ FeatureOfInterest can be the Location of the Thing. For example, the FeatureOfInterest of a wifi-connect thermostat can be the Location of the thermostat (i.e., the living room where the thermostat is located in). In the case of remote sensing, the FeatureOfInterest can be the geographical area or volume that is being sensed.

An Observation is the act of measuring or otherwise determining the value of a property.

NOTE: This file implements a small portion of the RFC7946 that is used in the coaty framework. This implementation is by no means complete. Many trivial choices were made during development. In case more compliance with the standard is needed, further development of this class is necessary. Polygon geometry object as defined in: https://tools.ietf.org/html/rfc7946#section-3.1.6

Undocumented

A Sensor is an instrument that observes a property or phenomenon with the goal of producing an estimate of the value of the property. It groups a collection of Observations measuring the same ObservedProperty.

Some common sensor encoding types.

http://docs.opengeospatial.org/is/15-078r6/15-078r6.html#table_15

Some common encoding types.

• http://docs.opengeospatial.org/is/15-078r6/15-078r6.html#table_7
• http://docs.opengeospatial.org/is/15-078r6/15-078r6.html#table_15

Some common observations types

http://docs.opengeospatial.org/is/15-078r6/15-078r6.html#table_12

The base class for sensor hardware-level IO control. Some IO classes are already defined:

• MockSensorIo: Mocks the functionality with a cached value.

Applications can also define their own SensorIo classes.

Mocks the IO communication of an actual sensor hardware. Stores a cached value for the pin and simply updates it with the ‘write’ calls. The value is 0 at the beginning.

Observes Sensors and Sensor-related objects. This controller is designed to be used by a client as a counterpart to a SensorSourceController which should answer its requests.

Manages a set of registered Sensors and provides a source for both Sensors and Sensor-related objects.

This controller is designed to be used by a server as a counterpart of a SensorObserverController.

You can either register the Sensors manually by calling registerSensor method or do it automatically from the controller options by defining your Sensors in a SensorDefinition array given in the sensors option of the controller.

SensorSourceController also takes some other options (they all default to false):

• ignoreSensorDiscoverEvents: Ignores received discover events for registered sensors.
• ignoreSensorQueryEvents: Ignores received query events for registered sensors.
• skipSensorAdvertise: Does not advertise a sensor when registered.
• skipSensorDeadvertise: Does not deadvertise a sensor when unregistered.

With regard to the Internet of Things, a thing is an object of the physical world (physical things) or the information world (virtual things) that is capable of being identified and integrated into communication networks.

Observes Things and Thing-related objects.

This controller is designed to be used by a client with a corresponding controller (e.g. ThingSourceController) that answers to its events.

A convenience controller that observes things and associated sensor and observation objects, combining the functionality of ThingObserverController and SensorObserverController.

This controller is designed to be used by a client that wants to easily handle sensor-related events as well as sensor observations.