Firebase Background Data Sync

Question

I have an Android GCM based Alarm Clock application that, for our specific industry use case, works great.

Here’s how it works now: A back-end system sends a GCM message to the phone. A BroadcastReceiver starts the Alarm Clock Activity which overrides volume settings, plays the alarm, turns on the back light, displays a full screen UI over the lock screen, and communicates (via upstream GCM) to the back-end when the Alarm is dismissed. The phone can be restarted, the app not launched by the user, and the Alarm Clock will still get launched when the back-end pushes the GCM message.

Programming design question: What is the correct way to replace this with Firebase?

Approaches I have tried out:

• Simply replace GCM with FCM (not using a Firebase Realtime database)
• Start a Service at boot (and within onCreate) that keeps a reference to a Firebase Realtime database. (https://gist.github.com/vikrum/6170193)

Both of those approaches work. Certainly replacing GCM with FCM is straightforward. Is keeping a Firebase reference alive in a Service the right architecture for processing an Alarm? Doesn’t feel right.

I have not yet coded with keepSynced(true). Perhaps that is what I should be using. I’m looking for a design that uses Firebase data synchronization instead of having to deal with the FCM RemoteMessageBuilder layer directly - I'll be able to retire a lot of XMPP code, a Windows Service, etc..

What’s the correct way to implement my Alarm Clock using Firebase?

Answer 1

This guidance from Doug Stevenson on Quora is the best I've found:

The big difference between Firebase Cloud Messaging and Firebase Realtime Database is this: With messaging, you will be able to wake the device from sleep even while the app is not running. The database can only receive updates to registered listeners while the app is currently running, and if the device is not in doze mode (for Android M).

Use Realtime Database when users are in your app and actively interacting with its data.

Use Cloud Messaging for times when you don’t know if the user is in your app, but you want to get them into your app (or make your app do something at a particular moment that you decide).

Messaging also has very restricted payload sizes (4k). With Database, you can read as much as you want from any node in your structure.

I’m speaking here in a general sense for all of Android, iOS, and Chrome. Each platform has their own particular ways of handling messages, but the semantics are similar.