Saving results from GWT-RPC call on client

[JeanV]

I was wondering if there's anyway to save the returned results from an RPC call to an HTML5 enabled browser. Basically the only way I have found would be to convert the results into strings and use LocalStorage to save them to the browser. I guess my question then would be how can IsSerializable java objects be converted to a string and back.

Any help would be appreciated.

Jean

[monkeyboy]

It is feasible. In my solution I used GWT-RPC's serialization but I had to tweak it since GWT-RPC messages are assymetric (the message sent from the client to the server is in a different format than the message sent from the server to the client even if they transfer the same object). Basically you have to make the serialization symetric. I did this by implementing the streamwriter to output the same message that the serverside would output. I did this basically by porting the server code to the gwt side. I then leveraged the already existing reader in the client and generated (by using generators) a class that returns the desired reader and writer. The reader is of course used to read the string and outputs the object and the writer takes the object and outputs the string. By using this method you can not only save results from RPC calls but any serializable object in the LocalStorage.

Since the storage in the LocalStorage is limited a further improvement is to compress the string. For this I use the LZMA algorithm which can compress the strings to about 60% of their original size. Based on my tests, bigger objects compress better but this is based on objects in my project and might not be the case for other kinds of objects.

Hope this helps.   

Regards,

           M

[JeanV]

Very good idea. I also thought of using GSON to convert the result into a string and saving it that way to localstorage

On Wednesday, October 10, 2012 4:33:25 PM UTC+2, Roy wrote:

An alternative is to make the GWT-RPC request using GET instead of POST, and have the server return cache headers so the result gets cached in the browser.  I'm doing that in my app - works great.

Roy

[Joseph Lust]

It really depends how intelligent you want your store to be. For example, if a user is perusing a set of N objects, and you hit the server up for 3 of these objects, you'd want to first check your LocalStorage cache for any of those 3 objects (say 2 hits), via a proxy cache, and relay on the RPC's for the (1 object) cache misses. This way, after playing around a little bit in your app, most requests will be local cache hits and you minimize request time and UI latency. Then you also need to limit what's in the cache, so you need a LIFO approach like LinkedHashMap. To do this however, there is no need to change your GWT-RPC code, but rather make requests to you client side caching layer, not directly to the RPC, and let that layer make the RPC requests.

That however is an intelligent caching strategy we used for 10K expensive objects. I suspect you want a passive GWT-RPC cache which would be most readily achieved by exploiting the browser cache with cache headers, but consider how you'll expire those objects (TTL?).

Sincerely,

Joseph

[Chris Lercher]

One alternative for serialization would be to work with AutoBeans. 

- Advantage: They can be decoded from/encoded to Strings via AutoBeanCodex.

- Disadvantage: AutoBeans (or the interfaces they represent) can't be used as parameter types for GWT-RPC, so you'd have to convert them to Strings here, too. So effectively you lose type safety. 

On the upside, AutoBeanCodex can also be used on the server side, so it's easy to en-/decode between AutoBeans and Strings on both sides, and using the same methods for your cache.

On Wednesday, October 10, 2012 7:13:20 AM UTC+2, JeanV wrote:

[JeanV]

That's a good idea but it doesn't solve the issue of converting the RPC received objects into a locally persistable objects. In my case, the user is loading a list but I want to pre-populate it with the latest list and have him/her manually refresh it.

Thanks for your assistance

[JeanV]

That's a good idea unfortunately I also use GWT-RPC calls for authentication and it breaks when using this approach. While I do want to cache the retrieved list, I also want the user to be able to update the list. Caching it might prevent getting the latest copy. 

On Wednesday, October 10, 2012 4:33:25 PM UTC+2, Roy wrote:

An alternative is to make the GWT-RPC request using GET instead of POST, and have the server return cache headers so the result gets cached in the browser.  I'm doing that in my app - works great.

Roy

On Wednesday, October 10, 2012 6:13:20 AM UTC+1, JeanV wrote:

[JeanV]

Thanks Moneyboy,

Can you post an example of how you achieved this. Not the storage part but the implementation of the streamwriter on the client side.

Many thanks,

Jean

[monkeyboy]

Hello JeanV,

I made a googlecode project for you (and everybody else who wishes to use the serialization library). You can download the libs or build them from source. I included the explanation on how to use the code. Check it out and let me know if there are problems. I'll try to fix them.

Cheers

[Xi]

Hi,

    I've made a framework to do the serialization/deserialization of object in client side. Just like monkeyboy's solution, it is based on GWT RPC's serialization/deserialization. But the difference is, my framework is more like an extension of localStorage/sessionStorage, that provides the possibility of put/get an object item directly into/from localStorage/sessionSotrage.

    You can find it here : http://code.google.com/p/gwt-storage/
   
    This solution is already used in our applications in production. So, if you have any question (performance, serialization/deserialization timing, ...), I would be very pleased to exchange with you.

    Hope this helps.
    Best regards.

 Xi