LocalBroadcastManager has been deprecated. What I should use instead in its place?

Question

I\'m working on this project in Android in which an aspect requires a CountdownTimer with a foreground service. A few other answers on Stack Overflow mentioned that LocalBroadca

Answer 1

In addition to "Ryan M" answer, starting with "Fragment" library v1.3.0-alph04 Androidx introduced new "Fragment result Api" which could be used for communication between pair of Fragments or Activity-Fragment. You pass a data/event with a key to a FragmentManager and a Fragment/Activity having access to that FragmentManager, can listen to data with specifying proper key.

It might be more suitable than LiveData to "event"s, but one problem I faced when using it was that you must know the relation between source, target and the FragmentManager. For example let's assume we are using navigation component from Jetpack, and have a simple fragment witch want to communicate with host Activity. You might think that Activity's supportFragmentManager and Fragment fragmentManager are the same instance, but actually there's a NavHostFragment between theme which have a fragmentManager that host the target activity.

Answer 2

LocalBroadcastManager is basically an event bus with a lot of unnecessary ceremony around Intents and intent filters. So one replacement is easy, and functions quite similarly: you can use any event bus library. greenrobot's EventBus is a popular choice (here's a guide for it) and Guava also has one, if you're already using Guava (but Guava is pretty heavy to include just for an event bus).

But event buses suffer from the same problems that LocalBroadcastManager does that led to it being deprecated: it's global, it's not lifecycle-aware, and as your app gets larger, it becomes much more difficult to reason about the effects of a change to an event. For cases of observing data, LiveData solves this quite nicely because it's lifecycle-aware, so you won't get change notifications at the wrong time (like before your View is set up, or after onSaveInstanceState) - but it'll handle delivering the change notifications when you're in the right state again. It's also more tightly scoped - each piece of LiveData is accessed separately rather than having (typically) one event bus/LocalBroadcastManager for the entire app.

For cases where it's more of an event rather than a piece of data being changed, you can sometimes convert it to a piece of data. Consider if you have "login" and "logout" events - you could instead create a LiveData that stores an Account for logged-in users, and becomes null when the user is logged out. Components could then observe that.

There are certainly cases where it really is difficult to convert it to a piece of observable data (though I can't immediately think of any examples that would typically be used with an event bus patten). For those, consider writing your own listener interface, similar to how on-click listeners work.

For your example of a countdown timer, I think LiveData is a pretty straightforward solution, and will be much easier than an event bus or even LocalBroadcastManager would be. You can just have a LiveData of the timer's current value, and subscribe to it from whatever needs to show the value.