Re: [aerogear-dev] Android Sync Status

One thing that this brings up that I didn't see in the AGSYNC Jira (unless

clients.

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. 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? Happy Monday y'all, -- 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