If you're using Realtime subscription after a user...

# supabase-kt

[Remy Benza]

If you're using Realtime subscription after a user has been authenticated, is there a risk of setting up multiple listeners for when the users logs out/in again?

[Remy Benza]

eg I call this code when the supabase.auth.session == Authenticated


private fun listenToUpdate(user: User) {
supabaseClient
.from(USERS_DETAILS_TABLE)
.selectSingleValueAsFlow(User::userId) {
eq("userId", user.userId.orEmpty()) // listen for changes for this specific user
}
.catch { Timber.e(it, "Error inside flow for user details table") }
.filterNotNull()
.onEach {
Timber.tag("~!").d("flow table user details: ${it}")
user.value = it
}
.launchIn(scope)

[Remy Benza]

if you were to call listenToUpdate function multiple times, will it then setup multiple listeners?

[Remy Benza]

in other words, does the SDK cleans up listeners ?

[Jan]

If the flow completes/closes, the SDK cleans up the listener & the channel. (For example the job/scope collecting the flow gets cancelled)
The flows produced by selectSingleValueAsFlow don't interact with each other, meaning you can call them how many times you want.

[Jan]

So in theory, you can save the job collecting the flow somewhere and cancel any previous job in your method before calling the method again

[Remy Benza]

so i should do manual clean up?

[Remy Benza]

eg

var realtimeJob = Job()

and then

[Remy Benza]

realtimeJob?.cancel()

before assigning the new job to the var when calling listenToUpdate()

[Jan]

Well, yeah. The library does not know when to clean up otherwise. In what context is this method called?
If you e.g. have a view model scope, you could just launch a coroutine within that scope and depending on the viewmodels lifecycle, all jobs get cleaned up automatically

[Remy Benza]

thnx, and about performance is using realtime database 'expensive' in terms of performance for the db / supabase costs?

[Jan]

Realtime itself isn't that expensive