9.0.0

Introduces LocationFetcher-Compose, a completely independent artifact that enables location fetching in Composable componentes.

8.2.2

Release 8.2.2

• Stop sharing locations between LocationFetcher instances.
  This allows for preciseness of LocationFetcher.Config configurations.
  Permission status and settings status are still shared as they are really
  a global state.

8.2.1

Release 8.2.1

• Update AGP to 7.1.3, Gradle to 7.4.2
• Only collect location from API if user is collecting
  LocationFetcher.location. The previous restriction
  (only collect if Lifecycle.State >= STARTED) still holds, so the new
  logic for collecting from API is:
  1. Lifecycle.State >= STARTED
  2. User is collecting LocationFetcher.location

8.2.0

• Created demo application.
• Removed default values for LocationRequest. (Fixes bug where interval is not respected).
• Removed GPS and Network providers from default providers config. We now only keep Fused provider by default (which is an abstraction over GPS and Network providers). This gives more expected behavior relating to the LocationRequest configs.
• Changed fastestInterval, interval and maxWaitTime types to Duration instead of Long.
• Other minor changes.

8.1.1

• Add support for Fragment alongside the
  already supported ComponentActivity and Context.

• Add builders with support for lazy rationales.

  These builders allow building LocationFetcher passing in
  a rationale producer instead of a rationale string.
  This enables the possibility for using getString in
  a field assignment in a ComponentActivity/Fragment:

  class MyFragment : Fragment() {
      private val locationFetcher = 
          locationFetcher({ getString(R.string.rationale) }) {
              // ... config
          }
  }

• Bump versions:

  Kotlin: 1.6.0-RC2 -> 1.6.10

  com.android.library: 7.1.0-beta02 -> 7.1.2
  kotlinx.coroutines: 1.5.2 -> 1.6.0
  play-services-location: 18.0.0 -> 19.0.1
  activity-ktx: 1.4.0-rc01 -> 1.4.0
  fragment-ktx: 1.4.0-rc01 -> 1.4.1
  appcompat: 1.4.0-rc01 -> 1.4.1
  lifecycle: 2.4.0 -> 2.4.1

8.1.0

• Add support for Fragment alongside the
  already supported ComponentActivity and Context.

• Add builders with support for lazy rationales.

  These builders allow building LocationFetcher passing in
  a rationale producer instead of a rationale string.
  This enables the possibility for using getString in
  a field assignment in a ComponentActivity/Fragment:

  class MyFragment : Fragment() {
      private val locationFetcher = 
          locationFetcher({ getString(R.string.rationale) }) {
              // ... config
          }
  }

• Bump versions:

  Kotlin: 1.6.0-RC2 -> 1.6.10

  com.android.library: 7.1.0-beta02 -> 7.1.2
  kotlinx.coroutines: 1.5.2 -> 1.6.0
  play-services-location: 18.0.0 -> 19.0.1
  activity-ktx: 1.4.0-rc01 -> 1.4.0
  fragment-ktx: 1.4.0-rc01 -> 1.4.1
  appcompat: 1.4.0-rc01 -> 1.4.1
  lifecycle: 2.4.0 -> 2.4.1

8.0.0

What's Changed

• Release 8.0.0 by @psteiger in #15

Full Changelog: 7.0.0...8.0.0

Breaking changes

• Location flow, permission flow and settings flow are now SharedFlow. Using StateFlow is conceptually wrong because it does not necessarily mean the current state. If you used .value on the previous flows, you can now use replayCache.last().
• LocationFetcher.location is now a SharedFlow<Either<Nel<Error>, Location>>. It now reports the errors in the left side of the Either value in case it failed to obtain a location.
• LocationFetcher.permissionStatus and LocationFetcher.settingsStatus are now SharedFlow<Boolean>. The old enums PermissionStatus and SettingsStatus are now deprecated.
• Removed LocationFetcher.requestLocationPermissionOnLifecycle and LocationFetcher.requestEnableLocationSettingsOnLifecycle configs from LocationFetcher.Config. Instead of requesting permissions and setting enablement on their own, it's now requested automatically once the location flows is subscribed to.
• Removed the possibility to ask for location indefinitely. We now use (and require) a rationale for asking for location. If user denies the permission once, the rationale is shown and we ask the permission one more time. If the user denies it, we respect the user decision and don't ask again. This is in accordance with Google's best practices and policies on location fetching. The rationale is a String passed to the LocationFetcher builders.

Other changes

• Added LocationFetcher.shouldShowRationale(): Boolean. Should return true after user denied location permission once. It's used internally to decide whether to show a rationale to the user before asking for permission again, but it's also exposed as an API.

8.0.0-alpha08

8.0.0-alpha08

8.0.0-alpha07

8.0.0-alpha07

8.0.0-alpha06

8.0.0-alpha06