title: Using Kotlin Coroutines to replace LocalBroadcastManager for Firebase messaging
body: <p>When using <a href="https://firebase.google.com/docs/cloud-messaging/android/client" rel="noreferrer">Firebase Cloud Messaging</a> on Android, it is often desirable to notify the current <code>Activity</code> of an incoming push notification. One of the recommended ways to do this has been to use <a href="https://developer.android.com/reference/androidx/localbroadcastmanager/content/LocalBroadcastManager.html" rel="noreferrer"><code>LocalBroadcastManager</code></a> to send an <code>Intent</code> from the <code>FirebaseMessagingService</code> implementation to the <code>Activity</code> (<a href="https://stackoverflow.com/a/41931325/829970">StackOverflow example answer</a>).</p>
  
  <p>However, as of version 1.1.0-alpha01 (2018-12-17), <a href="https://developer.android.com/reference/androidx/localbroadcastmanager/content/LocalBroadcastManager.html" rel="noreferrer"><code>LocalBroadcastManager</code> is deprecated</a>:</p>
  
  <blockquote>
    <p>LocalBroadcastManager is an application-wide event bus and embraces layer violations in your app: any component may listen events from any other. You can replace usage of <code>LocalBroadcastManager</code> with other implementation of observable pattern, depending on your usecase suitable options may be <a href="https://developer.android.com/reference/androidx/lifecycle/LiveData.html" rel="noreferrer">LiveData</a> or reactive streams.</p>
  </blockquote>
  
  <p>While it is highly likely that this class will remain available for a while longer, I would like to start cleaning up our applications anyway, so I want to migrate to something better before Google actually removes the old way.</p>
  
  <p>Right now, there are two main roles that these local broadcasts have in our apps:</p>
  
  <ol>
  <li>Update the UI with the new data from the push notification. The way this worked was that each <code>Activity</code> that cares about the incoming push data has a broadcast receiver that listens for the appropriate message and updates its own view data.</li>
  <li>Force the user to log out if the server sends a notification to end the session. This works with each activity having an instance of a broadcast receiver that listens for a logout event, ends the Activity, and starts the Login Activity.</li>
  </ol>
  
  <p>As I see it, these use-cases have issues with both of their suggested alternatives:</p>
  
  <ul>
  <li><code>LiveData</code> is easiest to use in an <code>Activity</code> or <code>Fragment</code> as part of a <code>ViewModel</code>. However, <code>ViewModel</code> is only meant to be used from those classes that directly deal with the UI. Accessing the <code>ViewModel</code> from within the <code>FirebaseMessagingService</code> takes an ugly hack and is a really bad idea from an architectural perspective. Also, different activities and fragments have different <code>ViewModel</code> objects, and I don't want the service to need to access them all.</li>
  <li>I can create a Kotlin <code>object</code> (a.k.a. Singleton) with a bunch of <code>LiveData</code> properties, have the <code>FirebaseMessagingService</code> update those <code>LiveData</code> objects from the incoming messages, and have the <code>Activity</code> observe those changes and copy them into its own <code>ViewModel</code>'s <code>LiveData</code> properties. The problem with that is twofold: first, it requires me to have two identical <code>LiveData</code> objects for each piece of data, one in the <code>ViewModel</code> and one in the <code>object</code>; and second, it doesn't help me with handling the "log out event", because <code>LiveData</code> is meant to handle changing data, not listening to a stream of events. (I may be able to handle the second issue using this <a href="https://medium.com/androiddevelopers/livedata-with-snackbar-navigation-and-other-events-the-singleliveevent-case-ac2622673150" rel="noreferrer"><code>LiveData</code> Event Wrapper</a>, but that still feels like a bad hack over something that isn't meant to work this way.)</li>
  <li>While reactive streams, such as RxJava, will probably do what I need, I already forced my team to learn Kotlin, Android Databinding, Android ViewModel, and a bunch of other new stuff in the last few months, and I don't think they can take much more. RxJava is also a large thing to add for just this one use, and we have no plans to rewrite the entire application to take advantage of it in order to justify its addition.</li>
  </ul>
  
  <p>One suggestion I found was to use Kotlin Coroutines with <code>Channel</code>s or <code>Flow</code>s. These can be used very similar to reactive streams, but (unlike RxJava) are intended to be used with Kotlin and benefit from Kotlin's improvements over Java. This option is especially attractive now that Google has announced that they are focusing on Kotlin for Android development instead of Java.</p>
  
  <p>While this seems to me to be the best option, I have not managed to find any feedback from others about whether it works and if there are side-effects and/or pitfalls to such an implementation. The only thing I found was an <a href="https://github.com/Kotlin/kotlinx.coroutines/issues/945" rel="noreferrer">open issue</a> on the <code>kotlinx.coroutines</code> repository about the need for providing an example of an application like this. While I'd love to contribute such an example, I don't think I know enough about it to create a good example, and I don't want my production apps to be the guinea pig. I also don't know whether it is better (or proper) to use explicit couroutines with <code>Channel</code> or to use <code>suspend</code> with <code>Flow</code> for this case.</p>
  
  <p>In summary:</p>
  
  <ul>
  <li>Are Kotlin Coroutines and their associated concurrency structures a good way to handle communication between Android <code>Service</code> and <code>Activity</code>?</li>
  <li>If yes, which Kotlin type makes more sense to use, <code>Channel</code> or <code>Flow</code>?</li>
  </ul>