Re: WebObjects + ERRest + iOS + CoreData (Yes another post on this)
Re: WebObjects + ERRest + iOS + CoreData (Yes another post on this)
- Subject: Re: WebObjects + ERRest + iOS + CoreData (Yes another post on this)
- From: Pascal Robert <email@hidden>
- Date: Tue, 22 May 2012 10:33:03 -0400
Hi Ricardo,
You should listen to the ERSync presentation from WOWODC 2011 for ideas. David will talk again about ERSync at WOWODC 2012, and Dan Beatty will present something for the Cocoa and Cocoa Touch part that sync with ERRest/ERSync.
> 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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden