These workers are concerned with the generation of raw location updates by Mapbox and sending it to subscribers over the ably connection.
The RawLocationChanged worker should do nothing if raw locations are not enabled. It should set the last publisher location on the publisher. It should then processes the location update for each trackable - requesting the publisher send it over the ably connection. If there are any raw location commands defined, they should be run and then commands cleared. In android, this only appears to be setting the destination on the publisher after the first raw location update is received.
As a result of the publisher sending the raw location over the ably connection, the publisher then posts one of two workers:
On a successful send, SendRawLocationSuccess is posted. This work unmarks the trackable as having a pending raw location message, sets the last sent saw location and clears any skipped locations. It the instructs the publisher to process another pending message, if there any.
On a failed send, SendRawLocationFailure is posted. If the error is not a fatal connection error and we've not passed the max retry count - then the publisher should be instructed to retry sending. Otherwise the update should be unmarked as pending and added to skipped locations for future sending. The publisher should then be instructed to send the next location update (if one is pending).
Current differences between the Android and Swift implementations:
AAT Android does not check if the publisher is stopping or stopped when sending the update.
When a raw location should not be sent, AAT Android immediately begins to send the next one (processNextWaitingRawLocationUpdate)
Implement the following workers from AAT Android:
These workers are concerned with the generation of raw location updates by Mapbox and sending it to subscribers over the ably connection.
The RawLocationChanged worker should do nothing if raw locations are not enabled. It should set the last publisher location on the publisher. It should then processes the location update for each trackable - requesting the publisher send it over the ably connection. If there are any raw location commands defined, they should be run and then commands cleared. In android, this only appears to be setting the destination on the publisher after the first raw location update is received.
As a result of the publisher sending the raw location over the ably connection, the publisher then posts one of two workers:
On a successful send, SendRawLocationSuccess is posted. This work unmarks the trackable as having a pending raw location message, sets the last sent saw location and clears any skipped locations. It the instructs the publisher to process another pending message, if there any.
On a failed send, SendRawLocationFailure is posted. If the error is not a fatal connection error and we've not passed the max retry count - then the publisher should be instructed to retry sending. Otherwise the update should be unmarked as pending and added to skipped locations for future sending. The publisher should then be instructed to send the next location update (if one is pending).
Current differences between the Android and Swift implementations:
This work is dependent on: