I’d like to keep data in sync between server and clients.
I’ve tested Messaging + Push Api exhaustingly.
What I found is:
Messaging works only, when the app is not killed.
Push (GCM) oftn laggs minutes whereas Messaging is extremely fast.
Based on this knowledge my first approach was:
Use Messaging, when application is aktive and combine with GCM as backup, when app is closed.
Turns out that spontanious registration / unregistration to channels via GCM doesn’t work.
Outcome: Messages get delivered via both GCM and Messaging Api.
Next possible approach could be:
Run Messaging in a background Service, not attached directly to the app. Save data locally, observe the data from the app. No use of GCM at all.
Question here: How about battery/connection consumption?
I did not test this approach yet. Would be great to get some information on the Messaing Api internals.
Any other best practices to achieve fast synchronization?
Your observations are correct, except in our experience push notifications (GCM) never take minutes, they are rather instantaneous. Were you sending one off messages or in bulk?
We are about to roll out changes which will significantly simplify it for you. Currently pub/sub messaging using the polling approach. It means the client side sends periodic requests to the server to grab any pending messages which should be delivered to the client. This approach is efficient in terms getting messages quickly to the client (as you have observed), but has the following drawbacks:
It can quickly drain device's battery since frequent http requests take a toll on the battery
It does not help you with the API/sec metric since we count the polling requests toward the limit imposed on all accounts (50 API/sec are free).
Messaging works only while the app is active (on the foreground)
To provide a more efficient alternative, we added (but not released yet) support for publish/subscribe messaging via silent push notifications. Using the same API we have now, you will be able to configure your app to use push notifications to deliver messages to the app. That means you get the following benefits from this approach:
No polling is needed (this is awesome as the battery will not get drained as fast and your API/sec metric is not impacted)
Messaging will continue to work even if the app is not running. Incoming message can wake up the app and is delivered to it.
We anticipate to release these changes very soon. The coding part is done and we're going through QA now.
I was sending one off messages to individual clients.
As I’m using Standalone, my req/s are not limited.
Am I getting you right that you will “replace” gcm with your new api?
However, I’m not quite sure what your advice is to solve the problem.
It sounds like using your next gen messaging api alone without gcm would do the trick?
That solution is very useful I’d like to implement it as soon as it is avaliable, is there some kind of mailing list to know whent this kinds of new features become avaliable?