[aerogear-dev] Sync on Android

Christos Vasilakis cvasilak at gmail.com
Tue Oct 14 03:23:12 EDT 2014


interesting work Summers  +1 to utilise platform native features 

thanks for sharing

On Oct 14, 2014, at 1:12 AM, Summers Pittman <supittma at redhat.com> wrote:

> TL;DR; Watch this repo over the next few days :
> 
> https://github.com/secondsun/aerogear-sync-server/tree/xmpp-diff-sync
> 
> Currently I am researching integrating the sync client technology that 
> DanBev, LolQuist et al have been working on into Android all proper 
> like.  Danbev wrote a POC demo a while ago* which uses the Java 
> websocket client.  This seems to work "OK" but there is a lot of work 
> getting websockets working right on Android.  However, Google has a two 
> way messaging protocol built into Google Play Services on top of GCM.  
> This is the technology I am trying to introduce to the sync systems in 
> this branch.
> 
> This branch includes a fork of the server library and a fork of the 
> client library which interact with GCM on the client and XMPP on the 
> server side.  Right now it compiles and not much else.  However, because 
> the server is decoupled from the connection handling, adding in the 
> correct hooks has been rather simple.  There are going to be some issues 
> to hammer out once this gets past "compiling" and makes it into "demoable".
> 
> First, the server does not receive implicit connect/disconnect messages 
> from Google per device.  Google does send Ack/Nack messages however so 
> with some bookkeeping connections/shadows/etc can be properly 
> maintained.    There is a similar mechanism on the client side; however, 
> we may need to expand the sync protocol to include some kind of heartbeat.
> 
> Second, the sync server isn't multitenant.  This means that until we 
> figure out how to merge, things listening to WebSockets don't hear 
> things listening to XMPP or see updates from one to the other.
> 
> Finally, Google Play Services is not FOSS by any stretch of the 
> imagination.  However, having a single connection managed by the OS is 
> great for usability, speed of development, battery life, etc so I feel 
> like this is more getting mileage out of the chunk of my soul I tossed 
> in the black Googley shredder for UPS and less of a deal breaker.
> 
> As I've said right now, today, this code is work in progress.  Soon it 
> will be proof of concept and we can discuss how to work around these 
> issues and merge the ideas back into mainline.
> 
> 
> -- 
> Summers Pittman
>>> Phone:404 941 4698
>>> Java is my crack.
> 
> PS: WebSocket's biggest problems are maintaining connections and 
> performing message redelivery in a sporatic connection scenario. This is 
> one of those things which is a lot of work to get right both on our end 
> as service providers and on the developer's end as consumers.  
> Additionally, Android L is going to include a lot more end user 
> configurability which will affect when/how messages are delivered.  To 
> do WebSockets right we will have to respect those settings as well.  It 
> is my assumption (we all know what that means) that Google Play Services 
> will correctly enforce data/power settings out of the box as well as 
> correctly maintain messaging connections and delivery.
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



More information about the aerogear-dev mailing list