[aerogear-dev] Android Sync Status

[Matthias Wessendorf]

On Mon, Feb 9, 2015 at 5:14 AM, Summers Pittman <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


>
> Happy Monday y'all,
>
> --
> 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/20150209/b316b409/attachment.html