This worker is called when publisher.add() or publisher.track() are called, and uses a user-provided callback to indicate that the add operation is successful.
If the publisher already contains a trackable and is not in the process of removing it, then the user-provided callback is immediately called. In the case of AAT Android, the result contains a StateFlow of the trackables state.
If the trackable is in the process of being removed, a delay is applied and the work is re-queued.
If the first trackable is being added, the publisher is set to the CONNECTING state.
In all other cases, the trackable is immediately added to the publisher and resolutions are resolved. The user-provided callback is then called (again with the StateFlow in AAT Android) to tell the user that the operation has succeeded, whilst ably connections proceed in the background.
In the background, if the first trackable is being added the ably connection is started. A fatal ably error at this point results in FailTrackable work being posted. ably.connect is then called to attach to the channel, again posting FailTrackable if a fatal error occurs.
Once the channel attach has succeeded, the worker posts the EnterPresence, SubscribeToPresence and ConnectionReady work.
In the event of the publisher being stopped before the work is run, or an unexpected error occurring in the synchronous code - the user provided callback is called with FAILURE.
In the event of asynchronous work encountering an unexpected error, if the work is currently being delayed (because the trackable is in the process of being removed), then the work is re-queued. If not, then FailTrackable work is posted.
As part of this work, we can remove the "duplicate trackable guard" as this should no longer be possible to do.
Implement the following worker from AAT Android:
This worker is called when
publisher.add()
orpublisher.track()
are called, and uses a user-provided callback to indicate that the add operation is successful.If the publisher already contains a trackable and is not in the process of removing it, then the user-provided callback is immediately called. In the case of AAT Android, the result contains a StateFlow of the trackables state.
If the trackable is in the process of being removed, a delay is applied and the work is re-queued.
If the first trackable is being added, the publisher is set to the CONNECTING state.
In all other cases, the trackable is immediately added to the publisher and resolutions are resolved. The user-provided callback is then called (again with the StateFlow in AAT Android) to tell the user that the operation has succeeded, whilst ably connections proceed in the background.
In the background, if the first trackable is being added the ably connection is started. A fatal ably error at this point results in
FailTrackable
work being posted.ably.connect
is then called to attach to the channel, again postingFailTrackable
if a fatal error occurs.Once the channel attach has succeeded, the worker posts the
EnterPresence
,SubscribeToPresence
andConnectionReady
work.In the event of the publisher being stopped before the work is run, or an unexpected error occurring in the synchronous code - the user provided callback is called with FAILURE.
In the event of asynchronous work encountering an unexpected error, if the work is currently being delayed (because the trackable is in the process of being removed), then the work is re-queued. If not, then FailTrackable work is posted.
As part of this work, we can remove the "duplicate trackable guard" as this should no longer be possible to do.
This work depends on:
Closes https://github.com/ably/ably-asset-tracking-swift/issues/534