iOS Base Xray SDK

[JanC]

OSS Xray SDK

Stories

Below are the stories. A detailed Open Source SDK board is here

• Event Persistence
• Setup CI
• Data Persistence
• Data Service API
• Event Service API
• Data Scheduler
• Event rule engine

Description

The goal is to have a mobile SDK that offers a base functionality of a event based platform. The input of the SDK are events, the output are pure data in response to the events.

The Xray sdk should be agnostic from the network transport and the message protocol by only defining an interface to transmit the events and callbacks when data triggered.

When and what events are sent is not part of the Xray SDK. This should be implemented in a higher level (e.g. 360dialog SDK)

What is part of the Xray SDK

Event handling

• Definition of an event:

  • name
  • properties
  • priority
  • local only / remote

• Local Event persistence until the event transmitter marks the event as processed

Event Transmitting

How are the events send should be abstracted to allow different transport implementations such as HTTP, web-sockets or a local pub sub...

The implementation of a transmitter is responsible for
- Serialising the events
- Message protocol format
- Telling the Xray SDK if the event was correctly processed (e.g. sent over network)

One of the implementation can be the xray 1.9 HTTP protocol

Payload Receiving

In the same way as the events, the Xray SDK should offer an API to receive data payloads in a transport agnostic way (native push, Web Sockets, HTTP).

• Definition of a payload:

  • Actual data which will be given back to the caller when the payload is triggered
  • An optional event trigger defined by JSON e.g. {"event":"app_shop_add_cart","filters":{"event.properties.item_name":{"eq":"iPhone"}}}
  • An optional expiration timestamp
  • An optional delay.

• A data receiver hands over the payload to the Xray SDK along with a arbitrary context and the Xray SDK persist it until it is triggered by a trigger

Data Triggering

When the conditions (triggers) are met, the Xray SDK delivers the actual data and its context via a delegate call back to the level above in the stack. For instance, the 360dialog SDK would parse the data to json to create a InApp campaign.

• The context can be used by any caller to identify under which circumstances the data was originally received (e.g. user tapped notification) and decide whether it should be processed or not.

• The Xray SDK persists the payloads until

  • they expire
  • they are triggered and the level above in the stack marks them as processed or discarded

The data triggering could in the future come from a local ORC running campaign and would be delivered via the same API to the user of the SDK.

• The data payload should be able to optionally preload itself. The Xray SDK decides when is the best to preload and updates the persisted payload when the preloading succeeds. How is the preloading done is abstract.

What is not part of the Xray SDK

• Definition of events: what events and when they are sent is up to the SDK user (e.g. 360dialog SDK knows when to send the d360_app_open).
• The Xray SDK does not emit any event by itself
• The existing transport implementation (360 transmitter and receiver) that can talk to the current xray protocol would remain private

Unresolved questions

• Swift vs Objective-C: Swift is way cooler for an open source project but will make the integration of the SDK difficult into a Objective-C project.
• Too minimal? The Xray SDK alone is too minimal for an integration of a new CRM customer which will be possible only using 360dialog
• When open sourcing the entire platform, we should rethink the protocol and provide default transport implementations (Receiver + Transmitter)

Future Evolution

• As open source examples, we can provide example implementations of Transmitters and Receiver that use WebSockets or MQTT to show the flexibility of the SDK
• We can provide in a separate framework a default HTTP Transmitter and a APNS Receiver that talk to the xray platform to allow basic functionality without using the 360dialog SDK

[JanC]

moved to https://github.com/xray-tech/xorc-xray-platform/issues/16