keepSynced() and Android activity lifecycle
Martin d'Allens
Kato Richardson
Hi Martin,
Honestly, you’re probably doing more harm than good trying to optimize energy usage here. Firebase and Android probably do better on their own. For example, Android (and iOS, too) will kill network connections for applications which are backgrounded, which probably makes your attempts here to cut down on use of the socket connections redundant.
Additionally, keepSynced(true) is intended to be used with offline persistence. So when you sync a path, it writes that data to local storage, which is a fairly expensive event from a battery life standpoint. But by calling keepSynced(false) when pausing the app, you would effectively tell Firebase that you don’t want that data cached to disk, meaning it would likely be purged. Thus, you might incur two writes to disk without any substantial gain.
Instead, I’d just subscribe using normal event listeners in onResume() and cancel them in onPause(). They will still survive temporary losses of connectivity, and since you’re telling Firebase not to store data when the app is paused/killed, you’ll get the same behavior.
If you happen to know when the user is looking at Firebase realtime data, and when they are not, then there is one optimization that could actually help battery life: Firebase keeps a socket open in a separate thread on Android, so if only some activities are utilizing the connection, you can call goOnline() and goOffline() in onResume/onPause to manually disconnect from the Firebase servers. This would sever the connection faster than the Android OS timeout for activity, and tell Firebase that there’s no need to reconnect immediately when the socket becomes available again.
Note that the gains here are probably insignificant as well, but it’s at least likely to be a positive gain.
☼, Kato
--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAMBZ%2Bfywo4v3HD4oUTmAY%3Dtg%2BbSoAo9Gciig-1y8n0JfKKwvbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Doug Stevenson
On Friday, December 9, 2016 at 12:40:19 PM UTC-8, Kato Richardson wrote:
Hi Martin,
Honestly, you’re probably doing more harm than good trying to optimize energy usage here. Firebase and Android probably do better on their own. For example, Android (and iOS, too) will kill network connections for applications which are backgrounded, which probably makes your attempts here to cut down on use of the socket connections redundant.
Additionally,
keepSynced(true)is intended to be used with offline persistence. So when you sync a path, it writes that data to local storage, which is a fairly expensive event from a battery life standpoint. But by callingkeepSynced(false)when pausing the app, you would effectively tell Firebase that you don’t want that data cached to disk, meaning it would likely be purged. Thus, you might incur two writes to disk without any substantial gain.Instead, I’d just subscribe using normal event listeners in
onResume()and cancel them inonPause(). They will still survive temporary losses of connectivity, and since you’re telling Firebase not to store data when the app is paused/killed, you’ll get the same behavior.If you happen to know when the user is looking at Firebase realtime data, and when they are not, then there is one optimization that could actually help battery life: Firebase keeps a socket open in a separate thread on Android, so if only some activities are utilizing the connection, you can call
goOnline()andgoOffline()in onResume/onPause to manually disconnect from the Firebase servers. This would sever the connection faster than the Android OS timeout for activity, and tell Firebase that there’s no need to reconnect immediately when the socket becomes available again.Note that the gains here are probably insignificant as well, but it’s at least likely to be a positive gain.
☼, Kato
On Wed, Dec 7, 2016 at 2:07 PM, Martin d'Allens <martin....@liberty-rider.com> wrote:
Hi Firebase,What is the recommended usage of keepSynced() with respect to the Android activity lifecycle?I would ideally set keepSynced(true) on all low-traffic nodes that are of interest for local caching as soon as the app starts, to save server round trip times when navigating between activities.From what I understand this would have the same energy-usage implications as setting a listener on each of the nodes, which means that a network connection will be kept open. This sounds like a bad idea.So do you recommend to set keepSynced(false) in the onPause()?Martin
--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CAMBZ%2Bfywo4v3HD4oUTmAY%3Dtg%2BbSoAo9Gciig-1y8n0JfKKwvbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.