LocalBroadcastManager will be deprecated from v1.1

[RoarGronmo]

You should rework this example and codelab soon to comply with the changes done here: https://developer.android.com/jetpack/androidx/releases/localbroadcastmanager#1.1.0-alpha01

---

Version 1.1.0-alpha01 December 17, 2018

androidx.localbroadcastmanager is being deprecated in version 1.1.0-alpha01.

Reason

LocalBroadcastManager is an application-wide event bus and embraces layer violations in your app; any component may listen to events from any other component. It inherits unnecessary use-case limitations of system BroadcastManager; developers have to use Intent even though objects live in only one process and never leave it. For this same reason, it doesn’t follow feature-wise BroadcastManager . These add up to a confusing developer experience.

Replacement

You can replace usage of LocalBroadcastManager with other implementations of the observable pattern. Depending on your use case, suitable options may be LiveData or reactive streams.

---

RG

[Oldes]

I was using LBM for years as a part of downloader for Google Play Services... now I see it's not available and all I can find is the notice:

You can replace usage of LocalBroadcastManager with other implementations of the observable pattern. Depending on your use case, suitable options may be LiveData or reactive streams.

Any tip how to replace it in this exact case?

[codingjeremy]

For this sample, I didn't want the added complexity of saving location data to a database. I just wanted to show how to request and get the location data.

That's a good point though on the LBM, so I will add a DataStore (replacement for SharedPreferences) and read data via a Flow when I get the chance. The Flow will emit every time a data changes (codelabs if anyone reads this and is interested).

I would go with that method if you don't mind using the alpha, although I was playing with it and it worked pretty well.

Otherwise, I usually do a full Room database and observe a LiveData instance to get the data I want. You can see that in the Room with a View codelab, but for this, it would be a little overkill.

Either way, thanks for the catch!

[RoarGronmo]

Go for Flow !!

BTW: LocationRequest().apply{} is deprecated from 18.0.0, since there are many changes in what-to-do / not-to-do concerning location you should rework this codelab. Keep it to the simplest, require location, listen to it, present it. Then you cold expand in another codelab location tracking with use of Room DB.

[barbeau]

@codingjeremy Thank you for this example app! I've been looking at re-architecting several apps that listen for location updates across Services and Activities to follow the architecture you describe in https://github.com/googlecodelabs/while-in-use-location/issues/12#issuecomment-770282388 by leveraging Room or DataStore and Flow.

I wanted to ask you about the best practice for serializing data like Location and GnssMeasurement to Room or DataStore for the use case where it's transient data for an observable pattern and not intended for long-term storage.

Given that both Location and GnssMeasurement implement Parcelable, it's tempting to (de)serialize these as Parcels (see this example). The benefit is that this avoids re-inventing the wheel with new model classes or .proto schemas for data in Location and GnssMeasurement.

However, the Parcel documentation explicitly says:

Parcel is not a general-purpose serialization mechanism. This class (and the corresponding Parcelable API for placing arbitrary objects into a Parcel) is designed as a high-performance IPC transport. As such, it is not appropriate to place any Parcel data in to persistent storage: changes in the underlying implementation of any of the data in the Parcel can render older data unreadable.

The counter argument is that this data isn't intended to be long-term storage and as a result the implementation shouldn't change.

What are your thoughts on this and the best approach for implementing the (de)serialization of location data for the observable pattern with Room or DataStore when the use case isn't long-term storage?

[barbeau]

I've taken a shot at replacing LocalBroadcastManager with Room + Flow (using Hilt for dependency injection) in my fork here: https://github.com/barbeau/while-in-use-location

A summary of the changes are in the README. I'd welcome any feedback from others with more experience for how this can be improved, as it's my first time working with these components! 😃

[Hmerman6006]

I've taken a shot at replacing LocalBroadcastManager with Room + Flow (using Hilt for dependency injection) in my fork here: https://github.com/barbeau/while-in-use-location

A summary of the changes are in the README. I'd welcome any feedback from others with more experience for how this can be improved, as it's my first time working with these components! smiley

There has not been alot of movement on your quoted fork in the last 12 months. Is your suggested solution to "LocalBroadcastManager" deprecation workable and viable?

[barbeau]

@Hmerman6006 AFAIK yes - I haven't heard otherwise. Here's an article I wrote on the Room + Flow implementation: https://barbeau.medium.com/room-kotlin-flow-the-modern-android-architecture-for-location-aware-apps-9c110e12e31a

In my own app I ended up pursuing a lighter-weight approach without Room and using callbackFlow. Code for this implementation is here: https://github.com/barbeau/while-in-use-location/tree/no-database

...and article is here: https://barbeau.medium.com/kotlin-callbackflow-a-lightweight-architecture-for-location-aware-android-apps-f97b5e66aaa2

The 2nd approach without Room and using callbackFlow is implemented in my GPSTest app here: https://github.com/barbeau/gpstest