You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 4, 2023. It is now read-only.
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
To pick up a draggable item, press the space bar.
While dragging, use the arrow keys to move the item.
Press space again to drop the item in its new position, or press escape to cancel.
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.
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.
Don't emit a second network call, if a previous one for the same resource is already "in flight"
To pick up a draggable item, press the space bar.
While dragging, use the arrow keys to move the item.
Press space again to drop the item in its new position, or press escape to cancel.
@orta best bet might be to separate networking layer from your persistence layer and use something like NSFetchResultsController for that binding goodness
Activity
orta commentedon Aug 5, 2014
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 commentedon Aug 6, 2014
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 commentedon Aug 10, 2014
Another great feature would be:
segiddins commentedon Aug 10, 2014
@orta best bet might be to separate networking layer from your persistence layer and use something like NSFetchResultsController for that binding goodness
orta commentedon Aug 11, 2014
I agree with both ( that's a smart one @shepting )
ashfurrow commentedon Aug 17, 2014
(Working on something here)
orta commentedon Sep 3, 2014
Closing, the responsibilities for this issue now lay in
