I've just posted the core part of my offline requestfactory implementation. http://puretech.siderakis.com/2012/10/offline-requestfactory-gwt.html
Basically all you need to do is extend it and override processPayload (to save the request payload in local storage), and then send the request payload at a later time when the apps back online. I hope its helpful, and I'd love to get some feedback. On Tuesday, October 9, 2012 10:41:56 AM UTC-4, Christoph Henrici wrote: > > > > Am Dienstag, 9. Oktober 2012 12:59:19 UTC+2 schrieb Thomas Broyer: >> >> >> >> On Tuesday, October 9, 2012 9:03:35 AM UTC+2, Christoph Henrici wrote: >>> >>> Best thanx. Szenario 1, would mean that you have to deal with two >>> different sets of data structures online = entityproxies and offline >>> something else..... or you have to develop your "own" layer above request >>> factory.... which to avoid was the rational behind using requestfactory. >>> >>> Szenario 2 seems like a interesting approach, but i must confess i not >>> knowlegable enough of the internals of Requestfactory to really be able to >>> see what that means. >>> >> >> Have a look at >> http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/web/bindery/requestfactory/shared/ProxySerializer.htmlbut >> beware that there are issues with it (known and probably unknown too). >> > Great pointer, thanx! > >> >> >>> Also for adressing the issue with the potential confict resolution this >>> is probably not the "right" layer.... >>> >>> So probably you need something above RequestfFactory, which deals with a >>> "higher level" batching and offline / online awareness etc....... >>> >> >> Synchronization (and conflict resolution) is hard. In the end, it's >> probably easier to either use the "last write wins" (possibly at the >> property level rather than object level; that would make it more of less >> equivalent to OT) or to simply store duplicates and then provide a mean to >> reconcile/merge data. It seems to be more or less what Google does for the >> contacts for instance. >> > Very true.... the approach with "secondary" unconsolidated data > structures, which are consolidate in a second step might a sound > approach.... > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/QSB2H_2lEeAJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
