5 ms·
AFIncrementalStore: Core Data with AFNetworking, Done Right
- shawnwall 14y agoAs a long time Obj-C/iOS dev, web service interaction frameworks and/or best practices have been lacking for some time now. While RestKit works, it's learning curve is a tad steep and the sheer size of it can be a tad frightening in terms of 3rd party component reliance. If AFIncrementalStore is as great to work with as AFNetworking itself devs may have found themselves a new standard.
- frankdenbow 14y agois there any good central repository for these kinds of frameworks / best practices?
- matttthompson 14y agoAll of the best Objective-C libraries can be found on CocoaPods (https://github.com/CocoaPods/specs/ https://github.com/CocoaPods/specs/)
- newhouseb 14y agoWoah, who knew NSIncrementalStore has been exactly what so many of us have been looking for. After a quick scan through, this looks like it completely replaces, not wraps, the default SQLLite store, yes? In other words, if the network is down, you can't save anything that would be synched later or request any queries that weren't cached? Or maybe I'm just not reading things right. Full offline functionality is pretty important to us so I wonder if there is a nice way to make the NSIncrementalStore wrap a regular old SQLLite CoreData store and fault out to the network if something isn't found locally and conversely, store any new calls that need to be made until network is available.
- jacobu9 14y agoRestKit (http://restkit.org/ http://restkit.org/) is working on something similar. Right now you have to manually push your data back to the REST service, but in version 0.11.0, they are going to add exactly the kind of functionality you're looking for: https://github.com/RestKit/RestKit/pull/573 https://github.com/RestKit/RestKit/pull/573
- newhouseb 14y agoYeah, we've written our own REST framework also which is actually surprisingly similar (and small, ~1k lines) to AFIncrementalStore which does all the things I mentioned except in a leakier abstraction completely outside of the CoreData store. It works well, but it pains me that there isn't a cleaner way.
- matttthompson 14y agoI have a theory that this could be accomplished in the NSPersistentStoreCoordinator by setting up sister contexts--one for network, one for SQLLite. Network is the master, and replicates to SQLite, which could be used for reads if the network is slow or down.
- newhouseb 14y agoYeah, that sounds like a fair strategy, except that lots of nice things using KVO are now really hard because if you go online/offline you would be switching between different NSManagedObjects in different contexts. (In practice, we rarely use NSFetchRequests because our usage patterns fit well into the object graph, thus we use lots of KVO). The two solutions would be A) make a NSManagedObject proxy class that actually proxies between the two NSManagedObject instances in different contexts (and maybe handle the replication here as well), or B) use two different NSPersistantStores in one context - but I cannot, for the life of me figure out how CoreData resolves conflicts between different Stores (network and sqlite) in the same Coordinator (NSMergeConflict doesn't seem to discuss this case). Does anyone have experience using multiple stores and actually understand how NSPersistentStoreCoordinator handles conflicts?
- 14y ago