What is the reasoning behind load: and retryLoad: in the AGSLoadable protocol

LinnartBaeker

If I download an AGSPortalItem via the load: method and the download fails (for example there is no network connectivity at that moment) I need to use the retryLoad: method on further download attempts for the same AGSPortalItem. Even if the network is back up, another load: call on the original PortalItem will always fail. I wonder what the design decision is behind this construct. Would't it be much easier to recheck network connectivity on all load: operations?

Best,

Linnart

LinnartBaeker

Loadable pattern for asynchronous resources—ArcGIS Runtime SDK for iOS | ArcGIS for Developers 

If a resource has failed to load, calling loadWithCompletion: on it subsequently will not change its state. The callback will be invoked immediately with the past load error. In order to retry loading the resource, you must useretryLoadWithCompletion: instead. The advantage of this approach is that if, hypothetically, loadWithCompletion:were to retry loading a failed resource, an app could easily end up making many asynchronous requests to load the same resource just because it shared the same resource instance in different parts of the application and each part tried to load the resource without first checking if it was already loading. This pattern allows loadWithCompletion: to be invoked indiscriminately without worrying that it might add overhead, and makes retrying a separate and explicit scenario using retryLoadWithCompletion:.