Re: [aerogear-dev] Sync on Android

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(a)redhat.com&gt; 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.

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(a)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@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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev