I'll adopt it and help make it work along with you, but shouldn't we move it into wonder source?
I'll be at wowodc to see the seminar, but I'd like to get further along than watching videos I'm left in the dark about the client side, and only mostly in the dark with the server stuff... Seems we should be able to get it into shape somehow, eh? Sent from my iPad On May 23, 2012, at 1:31 PM, David Aspinall <[email protected]> wrote: > Hi Jesse, > > Chuck's right, he is trying to kill me. > > I have been planning updates and demonstration code since last year, but > paying customers come first. I am supposed to present a practical > implementation at WOWODC which is only ... a month and a bit away. > > I am both freaking out and totally screwed. > > If you have specific questions you can send them to the list and I will > attempt to address them. > > David > > > On 2012-05-23, at 1:04 PM, Jesse Tayler wrote: > >> I'd like to ask >> >> whats the status of ersync? >> >> I see a great video, but the github is a year without updates and there is a >> placeholder for the iOS companion? >> >> Also, it is mentioned at video time, last year, that it was not production >> ready. >> >> So, is it now? Is there an iOS demo app where we can see how the transport >> works in practice on the client? >> >> Id love to add this to my Errest based app but I'm uncertain how to setup my >> app and client >> >> Can anyone help with that? >> >> >> >> >> >> >> >> Sent from my iPad >> >> On May 23, 2012, at 3:12 AM, Rich <[email protected]> wrote: >> >>> 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/jtayler%40oeinc.com >>> >>> This email sent to [email protected] >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Wonder-disc mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wonder-disc > _______________________________________________ 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]
