CoatySwift Migration Guide

The jump to a new major release of Coaty involves breaking changes to the CoatySwift framework API. This guide describes what they are and how to upgrade your CoatySwift application to a new release.

Coaty 1 -> Coaty 2

Coaty 2 incorporates experience and feedback gathered with Coaty 1. It pursues the main goal to streamline and simplify the framework API, to get rid of unused and deprecated functionality, and to prepare for future extensions.

Among other refactorings, CoatySwift 2 carries breaking changes regarding object types, distributed lifecycle management, and the communication protocol while keeping the essential set of communication event patterns. Therefore, CoatySwift 2 applications are no longer backward-compatible and interoperable with CoatySwift 1 applications.

CoatySwift 1 is still available as CocoaPod CoatySwift', '~> 1.0'. CoatySwift 2 is deployed as Cocoapod CoatySwift', '~> 2.0'.

To update your application to CoatySwift 2, follow the migration steps described next.

Before migrating

Changes in Configuration options

Changes in Coaty object types

Definition and handling of Coaty object types has been greately simplified by getting rid of the notion of a Coaty object family:

Additional changes to Coaty core types:

Changes in Container

Changes in distributed lifecycle management

To realize distributed lifecycle management for Coaty agents in Coaty 1, individual identity objects were assigned to the communication manager as well as to each controller, in order to be advertised and to be discoverable by other agents. The identity objects were also used to provide event source IDs for communication events to realize echo suppression on the controller level so that events published by a controller could never be observed by itself.

In Coaty 2, distributed lifecycle management has been simplified and made more efficient:

Upgrade to the new approach as follows:

If echo suppression of communication events is required for your custom controller, place it into its own container and filter out observed events whose event source ID equals the object ID of the container’s identity, like this:

    .filter { (discoverEvent) -> Bool in
        return discoverEvent.sourceId != self.container.identity.objectId
    .subscribe(onNext: { (discoverEvent)
        // Handle non-echo events only.

Changes in communication

Changes in Update event

We abandon partial Update events in favor of full Update events where you can choose to observe Update events for a specific core type or object type, analogous to Advertise events. This reduces messaging traffic because Update events are no longer submitted to all Update event observers but only to the ones interested in a specific type of object.

Changes in Raw event