- 1.1.6 and main22.214.171.124.04.2
- 1.1.6 and mainiOSmacOS(Intel)macOS(ARM)LinuxtvOSwatchOS
Retrying operations with no persistence, wrapped in a single Foundation Operation, in Swift
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
Usually, when subclassing
Operation, you either subclass
asynchronous if you want to write an asynchronous
operation, or simply
main() for synchronous operations.
RetryingOperation correctly, you only have to subclass
asynchronous if you want an asynchronous
operation). In your implementation, you are responsible for starting your
operation, but you do not have to worry about managing the
finished properties of the operation: they are managed for you.
When your operation is finished, you must call
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
When your operation is in the process of waiting for a retry, you can call
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.
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
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.