Networking Overview

[orta]

This was discussed in an artsy hangout, but I wanted to get it into something actionable, Our NetworkingAPI should:

• Make it easy to run offline
• Make it possible to run network requests synchronously
• Treat stubs as a first class citizen
• Allow tests to state only networking request X is allowed during this test run
• Allow iterating through all potential API requests at runtime for API sanity checks
• Keep track of current requests and don't support dupes

Think this is best done by having the request generation & the networking API client separate. A lot like how we have it in existing apps. Not assigning someone, but they should get ticked off as it happens, definitely better to do it earlier.

[orta]

I'd like the ability to easily cancel requests too, not really sure if that's the job of the PAI or the Network Models though.

[orta]

Ideally in this use case most of our requests should be cached, we could try having an API layer that insta-returns data synronously, then makes the network API call, updates the objects then does the async call. My gut impression is that this is how they do it in the tumblr app.

[shepting]

Another great feature would be:

• Don't emit a second network call, if a previous one for the same resource is already "in flight"

[segiddins]

@orta best bet might be to separate networking layer from your persistence layer and use something like NSFetchResultsController for that binding goodness

[orta]

I agree with both ( that's a smart one @shepting )

[ashfurrow]

(Working on something here)

[orta]

Closing, the responsibilities for this issue now lay in