RequestFactory in a offline Szenario?

[Christoph Henrici]

What be the best approach to develop a offline capable Application using ReqeustFactory? By Storing Request on locally on the Device and firing later when online?  Or is RequestFactory not recommendable to use, if offline capability is a requirement? 

Best Thanx for any advice.

Christoph 

[Jens]

I think I would store data changes locally and when the device is back online I would send everything to the server and let the server synchronize it with its server database. The server can send conflicts back to the client and then let the user choose which version of the conflicted data should be used.  So I would not store the specific requests, but only the data (along with some meta data like timestamp, isDeleted, etc.).

So its pretty much:

if(online) {

  // requestfactory

} else {

  // use local data cache

}

I am not sure if its possible to implement a custom RequestTransport for RequestFactory, e.g. OfflineRequestTransport, that parses the RF payload and executes/applies all the invocations/operations locally using a local data cache. If it would be possible you could switch to an OfflineRequestTransport as soon as you are offline and you dont need that "if(online)" block everywhere in your code.

-- J.

[Christoph Henrici]

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. 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.......  

[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.html but beware that there are issues with it (known and probably unknown too).

 

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.

[Christoph Henrici]

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.html but 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.... 

[Nick Siderakis]

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.

[Ümit Seren]

I have a question not directly related to the offline functionality. 

Is there any good reason to use a UI class (LoadingIndicator) directly in the OfflineAwareRequestTransport class instead of just using an event (LoadingIndicatorEvent) on the global event bus and let the application handle the displaying of the loading indicator ?