[aerogear-dev] Sync on Android

Tue Oct 14 09:37:49 EDT 2014

I'll skip the questions DanBev Answered.

On 10/14/2014 03:46 AM, Matthias Wessendorf wrote:
>
>
> On Tue, Oct 14, 2014 at 12:12 AM, Summers Pittman <supittma at redhat.com 
> <mailto: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
Google Play Services is proprietary software.  I would prefer to keep as 
much stuff open source as possible.  Since we have already agreed that 
leaning on GPS is OK, I don't feel as bad about using it again.
>
>
>     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?
http://www.androidcentral.com/android-l-preview-battery-and-power-management

Specifically I had the Job Scheduler APIs in mind.

>     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 ?
Yes.  XMPP is only exposed on the server side.  On the client side it 
looks like Push notifications and calling a send method on the gcm client.
>
>
> 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.
Yes.
>
>
> -Matthias
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto: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
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20141014/baa81b0a/attachment.html 