Is this a good strategy for doing some work in viewmodel and

Question

Is this a good strategy for doing some work in viewmodel and mid way requesting a user selection using some dialog before continuing to complete work Note using an `Event` wrapper since dialog is persisted through configuration changes when using navigation component The view layer would be responsible for `complete`ing the deferrable when the user clicks an item ```val itemSelectorLiveData = MutableLiveData lt Event lt Pair lt List lt String gt CompletableDeferred lt String gt gt gt gt suspend fun doSomethingFunButWorthwhile Boolean val items List lt String gt = workOutWhichItemsToChooseFrom val deferredItem = CompletableDeferred lt String gt itemSelectorLiveData postValue Event Pair items deferredItem wait for user to select item val selectedItem = deferredItem await return doSomethingWorthwhile selectedItem ```

Mark · Answer

There is one nasty part to this where the selector dialog needs to peek into the event s `CompletableDeferred` obtained via a shared viewmodel in order to complete it Alternatively I could use the new alpha fragment result API but then still the calling fragment needs to grab a reference to that `CompletableDeferred` so doesn t offer much in the way of advantage

Adam Powell · Answer

I m not sure why persisting the dialog calls for an event wrapper I think that s going to give you problems It always does because event wrappers in LiveData are a code smell anyway slightly smiling face

Adam Powell · Answer

That Pair also probably wants to be a class instead that exposes an API for completing the operation and letting `doSomethingFun` proceed and since it looks to be a one time operation you can probably use `suspendCancellableCoroutine` and store the continuation instead of a `CompletableDeferred`

Adam Powell · Answer

that would replace your call to `await`

Adam Powell · Answer

wrap that call in a try finally that nulls out the LiveData when it resumes and perhaps do the whole thing in a `Mutex withLock ` block to keep more than one call to `doSomethingFun` from stepping on each other s toes it ll form an orderly queue for concurrent callers

Adam Powell · Answer

the whole thing might look something like this

Adam Powell · Answer

```class DialogPrompt val options List lt String gt private val continuation Continuation lt String gt fun select item String require item in options $item is not a valid selection from $options continuation resume item class FooModel private val promptMutex = Mutex Must hold promptMutex to modify private val dialogPrompt = MutableLiveData lt DialogPrompt gt val dialogPrompt LiveData lt DialogPrompt gt get = dialogPrompt suspend fun doSomethingFunButWorthwhile Boolean val items = workOutWhichItemsToChooseFrom val dialogResult = prompt items return doSomethingWorthwhile dialogResult private suspend fun prompt options List lt String gt String = promptMutex withLock withContext Dispatchers Main try suspendCancellableCoroutine continuation gt dialogPrompt value = DialogPrompt options continuation finally dialogPrompt value = null ```

Adam Powell · Answer

you can also do things like add a method to `DialogPrompt` that resumes the continuation with a `CancellationException` if the user cancels the prompt

Mark · Answer

Ooh that s very nice thanks very much Adam handling prompt cancellaton is essential because of the mutex Is it preferable to continue with CancellatiionException rather than using null

Mark · Answer

Is it possible that `select` could be called multiple times e g after first call and before the livedata has a chance to be set to null

Mark · Answer

Regarding the `Event` wrapper I guess without it I d have to check whether the dialog has already been added to the fragment manager

Adam Powell · Answer

Suspending code always has to deal with `CancellationException` as a teardown it s much better to lean into it

Adam Powell · Answer

But up to you It makes calling code cleaner imo

Mark · Answer

The livedata is observed by a fragment which will then `navigate` to the dialog fragment At this point is it recommended to not use any arguments `navArgs` but rather let the dialog fragment grab the livedata directly from say a `navGraphViewModels` In the case where the `String` arg is actually something say non parcelable this seems like the only reasonable way but even for `String` it seems in some way cleaner because then the fragment is working entirely on `DialogPrompt` which ties the input and output together

Mark · Answer

Regarding `CancellationException` since the continuation is a `CancellableContinuation` better to just call `cancel ` in dialog cancel listeners I guess

Mark · Answer

Regarding the mutex lock the dialogs will queue up which is often not what you want At the moment I make a quick check beforehand to see if the mutex is locked and so break out if it is This seems a little hacky but probably good enough