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