[aerogear-dev] Sync on Android

Tue Oct 14 15:47:00 EDT 2014

On Tue, Oct 14, 2014 at 3:37 PM, Summers Pittman <supittma at redhat.com>
wrote:

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

ah, ok

Since we have already agreed that leaning on GPS is OK, I don't feel as bad
> about using it again.
>

yeah, I agree it's not a bad thing to leverage that

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

sounds good.

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

sounds good!

>
>
>
>  -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
>
>
> _______________________________________________
> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
>
>
> _______________________________________________
> 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/cfb37764/attachment-0001.html 