Background tokens in iOS
Performing web service requests in iOS, while the application has already been backgrounded by the user was causing a lot of server commuication errors to be seen.
In our particular case the web services that were affected were idempotent, and the user impact was to click a button to retry the same request again, which though not ideal from the users perspective was not too critical a flaw.
While looking at the relevant material, it was evident that iOS wants individual applications to request tokens that allow the application to perform some cleanup work in the background.
This was a great learning experience, in our case we already had an underlying framework in place that took care of retrieving a background token for 90% of the web service calls, but we are working on a newer way of communicating with the server and we missed this aspect of what the original framework had already implemented.
While searching through our codebase, we recongnized that our existing server communication framework some security stuff + background management stuff + wrapper around URLSession api’s), we found that there were several occasions where developers needed to perform chained web service calls and as such there were several occasions where the token was requested not just by the underlying infrastructure, but also by the folks using the infrastructure to perform web service requests.
The new infrastructure uses a task based approach for performing either a single web service request or a chain of web service requests. So we had two approaches to investigate.
Approach #1: Request a background task for each such task that was currently queued up
Pros:
- Each task could be individually tracked
Cons:
- Required wrapping the tasks that we had in a background task
- Required the entity managing the task to be aware of how to manipulate the queue of tasks, or send additional events that allowed the queue to pause/resume
- There could be limits to number of concurrent tokens that could be requested from the operating system, and iOS could decline those requests.
Approach #2: Request a background token if there is at least one queued task when the user backgrounds the app, but is eventually rescinded when the queue of tasks becomes emtpy (or whenever the expiry handler of the token is invoked).
If the expirty handler is invoked prior to the queue becoming empty, then pause the processing of the queue. Resume the processing of the queue when app comes back into foreground.
Pros
- Retrieval of management of the background token is outside of the queue of tasks, reducing framework dependencies for the queue data structure.
- A single token needs to be managed for the entire app, so we wouldn’t need to get tokens for individual tasks.
- A much simpler approach with lower impact on existing code.
Cons
- No control over how many tasks would be processed with the same token before the expiry handler is invoked by iOS.
- Typically the expiry handler would be invoked within 30 seconds, but iOS may offer more time for frequently used applications (which is some sort of a blackbox for folks not working on the operating system).
We eventually chose Approach #2, since we thought that not additional dependencies on the framework that managed the queue of tasks was good enough a reason.
