Firebase UI version 3: calling startListening() inside onStart() reloads the whole list.

[svidata]

Hello all and thanks for this great library, I am using version 3 of firebase ui in my android app. Now as suggested in the library documentation

I call start listening in onStart() method, like this:

mAdapter.startListening();

I call stop in onStop() method, like this:

mAdapter.stopListening();

These work perfectly they start and they stop no issue with that, but the problem comes when I resume my activity (in other words: when I revisit my activity by pressing back button) then the whole recyclerview restarts and scrolls back to the top. So it doesnt make sense to press item F and go to its detail activity and return to see that you are now on item A due to reload of the list.

If I try to start and stop using onCreate and onDestroy then I cant guarantee that onDestroy will be always called.

I thought startListening() means to attach listener not to reload the whole list.

What should I do to solve this?

[SUPERCILEX]

See #947, we don't have a good solution yet. Sorry!

[svidata]

@SUPERCILEX I checked the link, but I dont understand what do you mean by using view model. I mean how does it help? Thanks.

[svidata]

@SUPERCILEX is it bad if we startListening() in onCreate and stop in onDestroy()? What are the disadvantages?

[SUPERCILEX]

You could stop listening on onDestroy, but the main issue is that you'll still have a connection to the database all the way until Android decides to kill your app (which could be a while on a good device). This can get expensive if the data is changing and a bunch of clients are pointlessly listening to the db (also bad for battery). In addition, killing the connection in onDestroy just postpones the problem since once the user rotates their devices, you'll be doing a full, pointless sync with the db.

The idea with the link I sent you is that you'll keep a connection alive in a ViewModel which lasts for the lifetime of the Activity, but you also have 5 min timeout when your app goes into the background to kill the connection. This solution fixes all the pain points mentioned above: the db lasts through config changes and it dies after the user is done with it.

If you're just starting your app, I'd just go with onDestroy and not worry about it—that can be an improvement for later. 😁

[samtstern]

I think @SUPERCILEX has answered this completely, thank you!

[yashnagda04]

if I use view model them I revisit activity when it is in back stack list is reloading. if I stop it in on destroy data is getting changed while my activity is in the back stack so it's crashing because it can't access UI items.
@SUPERCILEX any possible solution?

[SUPERCILEX]

Yes, you need to store the observable array in a ViewModel and use it when building the options. See this discussion.

PS: I've tried several times to come up with a nice API and it hasn't worked out. 😢 I'm going to try and write a blog post with clearer instructions that I'll post in that thread while waiting for us to figure something out natively.