Changing the timeout interval is almost certainly not the best solution to the problem you're describing. Instead, it seems like what you actually want is for the HTTP client to handle the network becoming unreachable, no?
AFHTTPClient
already has a built-in mechanism to let you know when internet connection is lost, -setReachabilityStatusChangeBlock:
.
Requests can take a long time on slow networks. It's better to trust iOS to know how to deal slow connections, and tell the difference between that and having no connection at all.
To expand on my reasoning as to why other approaches mentioned in this thread should be avoided, here are a few thoughts:
- Requests can be cancelled before they're even started. Enqueueing a request makes no guarantees about when it actually starts.
- Timeout intervals shouldn't cancel long-running requests—especially POST. Imagine if you were trying to download or upload a 100MB video. If the request is going along as best it can on a slow 3G network, why would you needlessly stop it if it's taking a bit longer than expected?
- Doing
performSelector:afterDelay:...
can be dangerous in multi-threaded applications. This opens oneself up to obscure and difficult-to-debug race conditions.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…