[aerogear-dev] Android Sync Status

[Summers Pittman]

On 02/09/2015 05:15 AM, Matthias Wessendorf wrote:
>
>
> On Mon, Feb 9, 2015 at 5:14 AM, Summers Pittman <supittma at redhat.com 
> <mailto:supittma at redhat.com>> wrote:
>
>
>     First the good news, I've refactored a lot of the xmpp-client code so
>     now the sync client is correctly handled by an Android service. This
>     gets around issues we were having earlier where the in-memory client
>     would get GCed while the doc was in the background as well as some
>     issues with loading documents when messages came in for the not
>     currently being edited doc.
>
>     Now the bad news, the past two weeks we've been focusing on using
>     Google's two way messaging for being the backbone of sync on
>     Android for
>     alpha.1.  One of the issues we knew about was the 4k message size
>     limit
>     in GCM and that after a POC phase we were going to have to address it.
>     On Friday I noticed that the server was choking on messages much
>     smaller
>     than 4K.  Turns out that 4K includes all of the metadata around the
>     message in addition to the payload.  I do not think the GCM bridge
>     is a
>     good tranport for alpha.1 and (if everyone agrees) will be focusing on
>     the WebSocket based client.
>
>
> +9001 on a solid WebSocket client library for Android.
>
> Especially for privacy our SYNC module should not rely on a 3rd party 
> provider, like GCM, to sync the user's data (either entire documents 
> or even patches).
>
> For the integration of GCM/XMPP, IMO the best usage here is to just 
> signal (or notify) the mobile app (e.g. while running in the 
> background without a persistent connection to the Sync-Server) there 
> is "new data" is available. The app could than (while still in the 
> background) perform a connection to the users' Sync-Server and apply 
> the data (e.g. patch), that was delivered directly from the users' 
> Sync-Server instance. This way the users content is not exchanged over 
> a 3rd party provider, like Google
>
>
>     One thing that this brings up that I didn't see in the AGSYNC Jira
>     (unless I'm blind) was how to manage the socket-connectivity
>     interaction
>     on the clients.  Basically a protocol / pattern for how we manage the
>     socket connections when the device gains and loses internet access or
>     switches networks.  (For instance we should probably disconnect and
>     reconnect when the device leaves a cellular network and joins a Wifi
>     network)This is separate from collision handling/detection which does
>     have a Jira.  If there isn't one (a connection handling Jira) should I
>     make one?
>
>
> Sounds like a good idea, to have that for the next iteration of our 
> SYNC effort
And here it is https://issues.jboss.org/browse/AGSYNC-36
>
>
>     Happy Monday y'all,
>
>     --
>     Summers Pittman
>     >>Phone:404 941 4698
>     >>Java is my crack.
>
>     _______________________________________________
>     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/20150209/e4c96b5c/attachment.html