WEBVTT 00:00.120 --> 00:01.040 Welcome back. 00:01.080 --> 00:08.720 Before we continue implementing start and stop location updates function, we need to create the location 00:08.720 --> 00:09.480 callback. 00:09.880 --> 00:12.960 So here I want from you to focus with me. 00:13.000 --> 00:21.000 And because this is a very important video, you will learn how to get and how to fetch the location 00:21.200 --> 00:22.000 updates. 00:22.040 --> 00:27.480 Let me start with private Val fused location client. 00:27.520 --> 00:38.000 It's of type fused location provider client use by lazy and set location services. 00:38.160 --> 00:47.240 Dot get fused location provider client and pass the context fused location provider client is part of 00:47.640 --> 00:51.280 Google Play Services location APIs. 00:51.600 --> 01:00.560 Combining multiple location sources GPS, Wi-Fi cellular to provide optimal location data. 01:00.880 --> 01:07.480 Handling battery efficiency automatically by lazy, lazy initialization. 01:07.520 --> 01:11.800 The client is created only when first accessed. 01:11.840 --> 01:19.440 Thread safe default behavior ensures safe initialization, avoiding unnecessary instantiation if never 01:19.440 --> 01:20.040 used. 01:20.280 --> 01:27.080 Delaying play services connection until needed and saves memory location services. 01:27.360 --> 01:29.040 Get a fused location provider. 01:29.040 --> 01:38.000 Client factory methods that requires a context, and before this purpose, we pass the context and injected 01:38.160 --> 01:40.680 in the constructor of this class. 01:40.720 --> 01:44.480 Returning a managed location. 01:44.680 --> 01:46.400 Client instance. 01:46.400 --> 01:50.800 Handling connection to Google Play services. 01:50.840 --> 01:52.080 Why this pattern? 01:52.120 --> 01:53.880 Performance optimization. 01:53.880 --> 01:57.760 Memory efficiency and lifecycle safety. 01:57.800 --> 02:05.560 In terms of performance optimization, play services connections are expensive, only established when 02:05.600 --> 02:06.880 actually needed. 02:07.120 --> 02:12.990 Avoiding holding unnecessary Resources and initialising. 02:13.310 --> 02:17.830 Initialization happens when the property is first accessed. 02:17.870 --> 02:26.150 Can be placed in application class for app wide usage, but for this is for the location services. 02:26.310 --> 02:30.630 How to get and and create the fused location provider client. 02:30.670 --> 02:36.470 Now we need to use this client in order to get the location. 02:36.470 --> 02:46.750 So in this case continue with private val location callback equals to it's of type object returning 02:46.830 --> 02:52.430 type location callback or an object location callback. 02:52.430 --> 03:00.710 Here, if we go to the location callback, we have two methods on location result and on location availability. 03:00.750 --> 03:03.230 We need to use one of them. 03:03.230 --> 03:09.950 We need to use the on location result, so override on location result. 03:09.990 --> 03:19.460 This code defines a custom location callback that handles incoming location updates from Android's fused 03:19.460 --> 03:20.980 location provider. 03:21.020 --> 03:30.580 The location callback receives periodic location updates and updates, and observable state holder with 03:30.580 --> 03:32.540 the latest coordinates. 03:32.580 --> 03:39.180 Let me change P0, which is the location result and name it as location result. 03:39.380 --> 03:45.740 And here remove super, then location result dot location. 03:45.780 --> 03:50.660 We can access the last location if it is not null. 03:50.700 --> 03:55.340 Go and create and you current location. 03:55.460 --> 03:57.980 What we need to do with the current location. 03:57.980 --> 04:07.100 We need to update the user location dot value equals to a new lat long. 04:07.380 --> 04:07.860 What? 04:07.900 --> 04:17.420 What is the new lat long location result or my current location dot latitude and current location dot 04:17.460 --> 04:20.380 longitude the location callback. 04:20.660 --> 04:31.100 Abstract class from Android location APIs receives updates when new location is available, and location 04:31.100 --> 04:39.460 availability changes must override on location result and optionally on location availability on location 04:39.460 --> 04:44.260 result called when new locations are available. 04:44.380 --> 04:48.580 Location result contains last location and location. 04:48.580 --> 04:57.780 So if we open it contains the locations list of all locations since last update and last location most 04:57.780 --> 05:00.300 recent location objects. 05:00.500 --> 05:07.380 Also, you can notice them here if you get the last location or location. 05:07.380 --> 05:10.220 So last location and locations. 05:10.260 --> 05:11.140 Locations. 05:11.140 --> 05:19.300 List of all locations since last update and most recent location object is called from last location 05:19.300 --> 05:21.020 and this is the save call. 05:21.060 --> 05:23.540 Last location is nullable. 05:23.540 --> 05:30.700 Might be null on first call or if location unavailable, only processes not null. 05:30.900 --> 05:34.420 Locations and user location updates. 05:34.740 --> 05:37.340 A mutable mutable state flow. 05:37.380 --> 05:44.300 Lat long with new coordinates and lat long is typically a data class holding lat long. 05:44.500 --> 05:52.780 Current location, dot latitude and longitude are being processed and getting them with lat long and 05:52.780 --> 05:55.100 saved into the lat long object. 05:55.140 --> 05:56.260 How it works. 05:56.420 --> 06:03.340 In the next video we're going to create the location request setup, then the callback registration. 06:03.500 --> 06:07.620 Then the update flow system delivers location result. 06:07.660 --> 06:16.500 The callback is triggered on location, result is triggered and state flow is updated and the UI reacts. 06:16.740 --> 06:22.980 This is how we decouple location updates from UI and state flow. 06:22.980 --> 06:25.900 Enables automatic UI update.