An abstract class for retrying operations. The idea is to provide a clean and easy way to create retrying operations. For instance, if you make an operation to fetch some network resources, the operation might fail because there is no Internet right now. However, Internet might be back soon! Instead of bothering your user by telling him there’s no net and he should retry, you might want to wait a few seconds and retry the request(s).
The retrying operation class gives you a way to easily handle the retrying process.
Note: Cancelled operations are not retried.
RetryingOperation is an abstract class.
In order to use it you must subclass it.
Usually, when subclassing Operation, you either subclass start(), executing, finished and asynchronous
if you want to write an asynchronous operation, or simply main() for synchronous operations.
To subclass RetryingOperation correctly, you only have to subclass startBaseOperation() and asynchronous.
In your implementation, you are responsible for starting your operation,
but you do not have to worry about managing the executing and finished properties of the operation: they are managed for you.
When your operation is finished, you must call baseOperationEnded().
The parameters you pass to this method will determine whether the operation should be retried and the retry delay.
The method must be called even if the operation is finished because the operation was cancelled
(even though the retry parameter is ignored if the operation is cancelled).
Indeed, if your operation is synchronous, the method must be called before the startBaseOperation() returns…
When your operation is in the process of waiting for a retry, you can call retryNow() or retry(withHelpers:)
to bypass the current retry helpers and either retry now or setup new helpers.
Note: If the base operation is already running, never started or is finished when these methods are called,
nothing is done, but a warning is printed in the logs.
startBaseOperation() and cancelBaseOperation() will be called from the same, private GCD queue.
Do not make any other assumptions thread-wise about these methods when you’re called.
Also note you might not have a working run-loop.
If you’re writing an asynchronous operation, you must leave the method as soon as possible,
exactly like you’d do when overwriting start().
Use case: I’m using a framework which provide nice operations.
I would want to make these operations retryable, but I cannot make them inherit from RetryingOperation as I do not own them.
What can I do?
A solution is to use RetryableOperationWrapper.
See the doc of this class for more information.
This project was originally created by François Lamboley while working at happn.