7

I'm considering the use of keepSynced() for some data from Firebase Realtime Database. I understand that it will automatically sync those paths. But how does that relate to Android lifecycle? If the user leaves all activities (and all normal listeners disconnect), will it stop syncing? I don't want the app to become data or battery hog.

On the other hand, I would like to update cached data when FCM notification arrives. I can launch some service which will connect to Firebase. I would like to sync all paths which are in keepSynced() and stop it when it's synced. I'm not sure how to achieve that. Create a listener to one of the paths and keep the service running for some time? After the service is finished, will it stop syncing?

David Vávra
  • 18,446
  • 7
  • 48
  • 56

1 Answers1

5

firebaser here

Great question!

When there is no active activity, the operating system may close the connection to the Firebase database at any time. Our SDKs don't try to prevent that, but will reconnect when the app becomes active again.

What you're describing in your second paragraph is what we call "push to sync", where you send a push notification (typically a silent FCM data message) to trigger synchronizing of the data.

We did something like that in last year's I/O app and, while it was a bit more complex than we wanted it to be, it worked great. We explicitly managed the connection in that case, calling goOnline() and goOffline() (after 5 minutes iirc). The main sync code can be found in the IOSched github repo.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Thanks for the answer, it's helpful. I have two follow-up questions: 1) you say that "system may close the connection anytime". That's ok, but do you know from experience how long does that usually take? Or more importantly, could it be a problem (measured by battery and data consumption) 2) So if I start a background service, call goOnline() there, and goOffline() after 5 minutes, it will sync paths which are marked as keepSynced()? – David Vávra Feb 13 '17 at 19:09
  • 1) nope, I never was able to get a decent metric for it. 2) I indeed thought we did precisely that in IOSched, but I can't find the specific code for it right now. :-/ – Frank van Puffelen Feb 13 '17 at 19:22
  • 2) OK, I will do some experiments and let you know. – David Vávra Feb 13 '17 at 22:28
  • OK, so I did some experiments and it works really well. When notification arrives, I call goOnline() and also keepSynced() on paths I'm interested at. It correctly synces on background and when I open the app, I see fresh data. If system is managing closing the connection automatically without any significant impact on battery or data (based on your previous answer), I don't have to call goOffline(). Is that right? – David Vávra Feb 22 '17 at 14:01
  • The connection will only be auto-closed if there are no active listeners. As long as there are active listener, there might be updates that need to be pushed from the server to the client, so the connection stays open. – Frank van Puffelen Feb 22 '17 at 15:36
  • I know, but keepSynced() works like a listener, right? As long as there are some keepSynced() paths, connection will be open until system devices to terminate it. – David Vávra Feb 23 '17 at 16:23
  • 1
    Using `keepSynced(true)` on a location indeed keeps the connection open, unless you call `goOffline()` or the OS closes the socket. But I wouldn't just rely on Android there, since it'll likely leave the connection open for quite a long time. Your app has much better knowledge on when it's done retrieving data, so can better decide when to go offline. – Frank van Puffelen Feb 23 '17 at 19:21
  • This is has a problem because in some of the android devices notification with data payload will never come but only notification with notification payload will come in which developers have no control – Praveena Jul 09 '18 at 09:51