Protocols

Interface to be implemented to consume log from the library.

Instances of implemented classes are obtained by the library through the LSLoggerProvider instance set on LightstreamerClient.setLoggerProvider(...).

See more

public protocol LSLogger

Simple interface to be implemented to provide custom log consumers to the library.

An instance of the custom implemented class has to be passed to the library through the LightstreamerClient.setLoggerProvider(...).

See more

public protocol LSLoggerProvider

Protocol to be implemented to receive LightstreamerClient events comprehending notifications of connection activity and errors.

Events for these delegates are dispatched by a different thread than the one that generates them. This means that, upon reception of an event, it is possible that the internal state of the client has changed. On the other hand, all the notifications for a single LightstreamerClient, including notifications to LSClientDelegate, SubscriptionDelegate, ClientMessageDelegate, MPNDeviceDelegate and MPNSubscriptionDelegate, will be dispatched by the same thread.

See more

public protocol ClientDelegate : AnyObject

Protocol to be implemented to receive LightstreamerClient.sendMessage(_:withSequence:timeout:delegate:enqueueWhileDisconnected:) events reporting a message processing outcome.

Events for these delegates are dispatched by a different thread than the one that generates them. All the notifications for a single LightstreamerClient, including notifications to ClientDelegate, SubscriptionDelegate, ClientMessageDelegate, MPNDeviceDelegate and MPNSubscriptionDelegate, will be dispatched by the same thread. Only one event per message is fired on this delegate.

See more

public protocol ClientMessageDelegate : AnyObject

Protocol to be implemented to receive MPNDevice events including registration, suspension/resume and status change.

Events for these delegates are dispatched by a different thread than the one that generates them. This means that, upon reception of an event, it is possible that the internal state of the client has changed. On the other hand, all the notifications for a single LightstreamerClient, including notifications to ClientDelegate, SubscriptionDelegate, ClientMessageDelegate, MPNDeviceDelegate and MPNSubscriptionDelegate will be dispatched by the same thread.

See more

public protocol MPNDeviceDelegate

Protocol to be implemented to receive MPNSubscription events including subscription/unsubscription, triggering and status change.

Events for these delegates are dispatched by a different thread than the one that generates them. This means that, upon reception of an event, it is possible that the internal state of the client has changed. On the other hand, all the notifications for a single LightstreamerClient, including notifications to ClientDelegate, SubscriptionDelegate, ClientMessageDelegate, MPNDeviceDelegate and MPNSubscriptionDelegate will be dispatched by the same thread.

See more

public protocol MPNSubscriptionDelegate

Protocol to be implemented to receive Subscription events comprehending notifications of subscription/unsubscription, updates, errors and others.

Events for these delegates are dispatched by a different thread than the one that generates them. This means that, upon reception of an event, it is possible that the internal state of the client has changed. On the other hand, all the notifications for a single LightstreamerClient, including notifications to ClientDelegate, SubscriptionDelegate, ClientMessageDelegate, MPNDeviceDelegate and MPNSubscriptionDelegate will be dispatched by the same thread.

See more

public protocol SubscriptionDelegate : AnyObject

Contains all the information related to an update of the field values for an item.

It reports all the new values of the fields.

COMMAND Subscriptions

If the involved Subscription is a COMMAND subscription, then the values for the current update are meant as relative to the same key.

Moreover, if the involved Subscription has a two-level behavior enabled, then each update may be associated with either a first-level or a second-level item. In this case, the reported fields are always the union of the first-level and second-level fields and each single update can only change either the first-level or the second-level fields (but for the command field, which is first-level and is always set to UPDATE upon a second-level update); note that the second-level field values are always nil until the first second-level update occurs). When the two-level behavior is enabled, in all methods where a field name has to be supplied, the following convention should be followed:

• The field name can always be used, both for the first-level and the second-level fields. In case of name conflict, the first-level field is meant.

• The field position can always be used; however, the field positions for the second-level fields start at the highest position of the first-level field list + 1. If a field schema had been specified for either first-level or second-level Subscriptions, then client-side knowledge of the first-level schema length would be required.

See more

public protocol ItemUpdate : AnyObject, CustomStringConvertible