Hey Riccardo, I've used pretty much the same setup of WO / ERRest backend presenting JSON for iOS consumers (iPad & iPhone) with CoreData for model / persistence, for a contract I completed fairly recently. Works very well.
I extensivly used the RESTKit framework on the the iOS platform, which has some nice 'automatic' CoreData syncing feature. The framework documentation or RESTkit is sketchy & there are still some bugs in it which can be a big of a pain, but pretty stable and has good features. The ERRest stuff is great and I found it very easy to work out from the sample code. Just make sure you design you EO Model & CoreData model so they have the same entity names & attributes in both. That way sync is a lot easier as you don't have to re-map your JSON payload (which is a headache, trust me). Rich On 23/05/2012, at 2:26 AM, Riccardo De Menna <[email protected]> wrote: > Hi all, > > I'm writing an iOS app that will fetch data from an ERRest-based-WOApp. I > want it to use CoreData on the iOS side and be as integrated as I can get it. > The whole ERRest thing seems really built to that end and the CoreData stack > is obviously an EO spin-off, but I did not find around some design guidelines > to help me identify a correct course of action. > > In particular the very interesting "WWDC2010 Session 117 - Building a > Server-driven User Experience", clearly identifies key points to follow, but > I was not able to find any sample code to show the details of that design. > I'm talking mostly about the iOS side as WO+ERRest basically do everything > for me on the server side. > > Anyway, I'm building something based on those slides… so… > > On my WO side: > > I have an ERRest based app with a custom authentication system that allows > for a login/logout/check action. These are simple DirectActions but with > correct HTTP response codes, and they return the sessionID on success. The > client app should store it in a cookie or provide it on any URL request, it > doesn't matter. > Various entity controllers that provide data in json/plist/xml/whatever with > the added option to request only certain keys on show to minimize traffic if > needed (my showFilter is limited to certain values server-side but the > remaining ones can be on-demand so that, if I only need Person.firstName for > 9000 records, I don't have to fetch unnecessary data. > > On my iOS side I have: > > A category that extends NSManagedObjectContext and provides: > - (NSManagedObject *)localInstanceOfObject:(NSManagedObject *)iObject; > > A category that extends NSEntityDescription and provides: > - (NSString *)route; > - (BOOL)allowsFetch; > - (BOOL)allowsInsert; > - (BOOL)allowsUpdate; > - (BOOL)allowsDelete; > > A category that extends NSManagedObject and provides: > - (NSManagedObject *)localInstanceInContext:(NSManagedObjectContext > *)context; > - (NSDictionary *)toDictionary; > > A category that extends NSFetchRequest and provides: > Incomplete… but would simply add a method that includes on optional endpoint > for the fetch, as well as the qualifiers and sortorderings I want to pass to > the server. > > A subclass of NSManagedObjectContext with overrides for: > - (NSArray *)executeFetchRequest:(NSFetchRequest *)request error:(NSError > **)error; > - (BOOL)save:(NSError **)error; > > A subclass of NSManagedObject that provides a: > @property (nonatomic, strong) NSString *endpoint; > > A model that mimics the EO-counterpart, only with waaaay less attributes. > > A subclass of my custom NSManagedObject for each entity > > This, I hope, is roughly what that session was suggesting and I can see it > would work nicely. > I'm trying to figure out how to implement the background operations that are > to be performed by the two NSManagedObjectContext overrides. My idea is that > the app just fetches on my CoreData stack and gets whatever data we already > have persistently saved previously. But the fetch also initiates a server > side check that eventually results in objects being updated in the UI. This > has to be asynchronous on a custom RunLoop/thread and silently inform the > various NSManagedObjectContexts that data has been updated from the server. > > Has anyone gone down this road? I'd love to look at some code samples, ideas > or design guidelines. Anything really ;-) > > regards, > Riccardo > > > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/richardwjones%40gmail.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
