WEBVTT

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

00:01.280 --> 00:08.240
We used dry sand and a way to close functions, but there are errors here.

00:08.440 --> 00:14.640
None of the following candidates is applicable because of receiver type mismatch.

00:14.680 --> 00:15.120
Okay.

00:15.320 --> 00:19.040
And if we hover here unresolved reference trace.

00:19.040 --> 00:28.400
This type of error occurs because these functions need to be called within the proper coroutine context

00:28.520 --> 00:32.440
or because you are missing necessary imports.

00:32.480 --> 00:36.240
Let's try to use the callback.

00:36.400 --> 00:42.360
So here equals to callback flow and scroll down.

00:42.520 --> 00:44.920
The errors are solved.

00:45.160 --> 00:53.720
But what are try send and await close functions and why we use them in Kotlin coroutines, particularly

00:53.720 --> 00:59.600
when working with flows and callback based APIs like Firebase Firestore.

00:59.880 --> 01:08.720
Try sand and await close serve specific purposes to bridge between callback style APIs and reactive

01:08.720 --> 01:13.120
streams flow in this this function.

01:13.120 --> 01:15.240
Get all markers from Firestore.

01:15.680 --> 01:26.000
We used the reactive streams of the flow and the callback style API, which is the listener, and the

01:26.000 --> 01:27.240
Firebase collection.

01:27.280 --> 01:32.720
The bridge between them is try and await close functions.

01:32.760 --> 01:38.880
Try send non-blocking emission of values to a flow from a callback.

01:38.920 --> 01:43.520
I want from you to write those notes down.

01:43.640 --> 01:51.640
The purpose of try sand is non-blocking emission of values to a flow from a callback used in callback

01:51.640 --> 01:59.200
flow or mutable shared flow to safely emit values without suspending the coroutine.

01:59.240 --> 02:08.240
Why we use it Firebase's ad snapshot listener uses callbacks, but we want to expose data as a flow.

02:08.280 --> 02:13.360
Try send allows emitting values from the callback into the flow.

02:13.400 --> 02:24.170
Non suspending regular sand suspends if the buffer is full, dry sand is non-blocking and returns immediately

02:24.210 --> 02:27.250
true if the value was emitted successfully.

02:27.450 --> 02:36.730
False if the buffer is full or the flow is closed, a wait close suspends the coroutine until the flow

02:36.730 --> 02:46.650
is canceled, then runs clean up code, ensuring resources like Firebase Firestore listeners are released

02:46.650 --> 02:49.330
when the flow is no longer needed.

02:49.330 --> 02:59.050
Resource cleanup means the callback based APIs like Firestore listeners need to be unregistered to avoid

02:59.170 --> 03:00.010
leaks.

03:00.250 --> 03:07.050
Await close provides a way to run cleanup when the flow collection stops.

03:07.090 --> 03:15.490
Flow lifetimes in Jetpack Compose flows collected via collect as a state function are canceled when

03:15.490 --> 03:22.690
the composable leaves the composition and await close function ensures that Firebase Firestore listener

03:22.690 --> 03:25.410
is removed at the right time.

03:25.650 --> 03:32.410
So here the coroutine suspends the await close until either the flow is canceled.

03:32.450 --> 03:37.330
Triggered the cleanup block or close is called explicitly.

03:37.410 --> 03:43.050
And here we need to use close and use the error.

03:43.090 --> 03:43.610
Okay.

03:44.010 --> 03:48.730
So this will cancel the flow and close it.

03:48.850 --> 03:49.410
Okay.

03:49.690 --> 03:55.290
One last thing we need to solve is the return type of the flow.

03:55.410 --> 04:01.450
Here we change it from list of destination marker to flow of list of destination marker.

04:01.490 --> 04:12.250
Let me go back to the marker repository and change it to a flow of list of destination marker.

04:12.290 --> 04:13.370
Import flow.

04:13.690 --> 04:14.810
And here we go.

04:14.930 --> 04:21.330
So this is the usage of wait close and try send functions.
