[aerogear-dev] Sync on Android

[Matthias Wessendorf]

On Tue, Oct 14, 2014 at 12: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.


what java client was used?



> This seems to work "OK" but there is a lot of work
> getting websockets working right on Android.


+1


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

on our sync-server, can't have have different "endpoints" (e.g. xmpp,
websocket),
that all connect to its heart, the Netty-based DiffSync engine?



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

not sure I follow here


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

looking forward to that.


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


any link to share?


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

instead of having our Android lib do a WS connection (including all the
required work for maintaining etc), we could leverage the XMPP from GCM.
That's the prefered route you are suggesting, right ?


ANDROID   <----> GCM <------> Sync-Server


This would allow us, to do more than we do atm on "pure" push
notifications, via GCM. In this scenario we can do a two way communication:
Android client can send data to Sync-Server (via GCM), and receive "diff"
from the server, via GCM.


-Matthias


> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141014/cafa0b65/attachment.html