WEBVTT

00:00.080 --> 00:00.920
Welcome back.

00:00.960 --> 00:06.080
We succeeded in getting all the markers from Firebase Firestore database.

00:06.320 --> 00:12.040
Now let's fetch the current location of the user inside the repositories.

00:12.160 --> 00:12.720
Package.

00:12.720 --> 00:20.080
Create a new Kotlin interface named as Location Repository.

00:20.120 --> 00:21.040
Hit enter.

00:21.200 --> 00:26.240
This interface contains two variables and two functions.

00:26.280 --> 00:30.800
The first variable is called user location.

00:30.840 --> 00:40.120
It's of type stateflow of lat long and val has location permissions.

00:40.120 --> 00:44.520
It's of type mutable state of type boolean.

00:44.560 --> 00:46.440
Let me import the Stateflow.

00:46.640 --> 00:47.680
The left lung.

00:47.880 --> 00:49.360
The mutable state.

00:49.360 --> 00:51.680
Create the two functions.

00:51.680 --> 00:58.400
Start location updates and function stop location updates.

00:58.440 --> 01:06.960
The location repository interface defines a contract for managing device location updates in an Android

01:06.960 --> 01:12.600
application using modern Kotlin coroutines and state management patterns.

01:12.760 --> 01:16.190
This interface abstracts location tracking.

01:16.190 --> 01:18.310
Start or stop updates.

01:18.350 --> 01:25.950
Current location exposure as a reactive stream has location permission used for permission.

01:25.950 --> 01:27.430
State management.

01:27.470 --> 01:35.030
The state of flow A hot observable flow that always holds the latest value.

01:35.190 --> 01:44.030
The Latlong location data class typically latitude and longitude, nullable when no location is available.

01:44.070 --> 01:49.670
Purpose of this provides the app with real time location updates.

01:49.710 --> 01:54.670
Automatically notifies observers when location changes.

01:54.670 --> 02:00.830
Has location permission which is of type Boolean mutable state Boolean.

02:00.990 --> 02:09.550
Jetpack composes observable state holder tracks whether the location permissions are granted.

02:09.550 --> 02:13.710
Can trigger permission requests when false y.

02:13.750 --> 02:18.750
Mutable state optimized for compose UI recomposition.

02:18.750 --> 02:26.270
When permission state changes, the start location updates function starts listening for location updates

02:26.270 --> 02:28.990
and stop location updates.

02:28.990 --> 02:37.780
Stops location updates to save battery when location is no longer needed or the app goes to background,

02:37.780 --> 02:42.180
it's very important and critical for preventing battery drain.

02:42.300 --> 02:50.220
So the purpose of creating this interface is to use the user location, has location permissions, start

02:50.220 --> 02:52.980
location updates, and stop location updates.

02:53.020 --> 02:56.700
Why we use the Stateflow and mutable state.

02:56.740 --> 03:02.260
The state flow automatically clean up tied to a coroutine scope lifecycle.

03:02.460 --> 03:07.060
Reactive UI compose can collect and recompose on changes.

03:07.260 --> 03:13.700
Single source of truth always holds the latest location and why.

03:13.740 --> 03:21.100
Mutable state for permissions compose integration directly works with remember and recomposition and

03:21.100 --> 03:26.620
simple state permission state is binary granted or not granted.

03:26.660 --> 03:34.380
Okay, now in the next video we'll continue with um with the default location repository or the location

03:34.380 --> 03:36.380
repository implementation.

03:36.380 --> 03:40.580
And we're going to use those variables and functions.