Alamofire: Per Request retriers

Created on 14 Aug 2017 · 7Comments · Source: Alamofire/Alamofire

I think that retrier variable in SessionManager is not very good...
What do you think put it into the Request?
use way like this:

Alamofire.request("https://temp.com", method: .get, parameters: nil, encoding: URLEncoding.default, headers: nil).response { (response) in



        }.retrier(_ shouldRetry: Bool, _ timeDelay: TimeInterval) //There may be other related parameters

feature request request adapter request retrier

Source

gaoyuexit

Most helpful comment

I might be a bit late to the party, but I'm using my homegrown Rx interface to SessionManager which allows me to do something like this:

func methodName(data: ServiceName.Method.RequestData/*Encodable*/) -> Single<ServiceName.Method.ResponseData/*Decodable*/> {
    return sessionManager
        .rx
        .post(url, body: data/*, ...*/)
        .object()
}

// ...

    let disposable = service
        .methodName(data: data)
        .timeout(configuration.timeout, scheduler: configuration.timeoutScheduler)
        .retry(configuration.retryCount) // automatically retries failed request
        .retryWhen(retryHandler()) // invokes custom retry handler to do more sophisticated retry logic like exponential backoff or presenting a UI
        .subscribe(/*...*/)

This way, the caller has full control over the retry logic. And readily-available instruments in Rx are quite powerful, so I don't even need that functionality in Alamofire.

ivanmisuno on 16 Jun 2018

😄2

All 7 comments

This is something that we're going to investigate in-depth in AF5 @gaoyuexit. Having a single retrier per SessionManager can be a bit limiting when you are trying to funnel multiple authentication systems through a single session manager. More updates to come...

cnoon on 14 Aug 2017

👍2

I have the same problem at the moment. But to channel it in the request seems wrong on the other hand. I think a great addition would be to hold multiply retriers and you can cancel the current one. In this way you could add specific logic for specific requests in the retriers.

mRs- on 21 Aug 2017

👍1

I might be a bit late to the party, but I'm using my homegrown Rx interface to SessionManager which allows me to do something like this:

func methodName(data: ServiceName.Method.RequestData/*Encodable*/) -> Single<ServiceName.Method.ResponseData/*Decodable*/> {
    return sessionManager
        .rx
        .post(url, body: data/*, ...*/)
        .object()
}

// ...

    let disposable = service
        .methodName(data: data)
        .timeout(configuration.timeout, scheduler: configuration.timeoutScheduler)
        .retry(configuration.retryCount) // automatically retries failed request
        .retryWhen(retryHandler()) // invokes custom retry handler to do more sophisticated retry logic like exponential backoff or presenting a UI
        .subscribe(/*...*/)

This way, the caller has full control over the retry logic. And readily-available instruments in Rx are quite powerful, so I don't even need that functionality in Alamofire.

ivanmisuno on 16 Jun 2018

😄2

Yeah not everyone using rx, so we need this directly on alamofire on the request base.

mRs- on 3 Jul 2018

I've solved the offline retrier issue earlier in a project by creating a custom Codable APIRequest struct that holds:

parameters dictionary
url
method
encoding
Every time a request fails, I saved that request on disk locally using FileManager, and I used NetworkReachabilityManager to observe network status changes and retry saved requests, removing the ones that complete successfully.

Maybe a similar approach could be followed for this?
I've been meaning to submit a PR for this, but just saw this issue and thought I'd share this with you 😄