Solvedkotlinx.coroutines Lifecycle handling

I was trying to use coroutine Jobs for Android lifecycle handling together with the UI dispatcher, but I've stumbled upon an interesting issue where basically the following code can cause a crash:

var job: Job? = null

fun foo() {
  job = launch(UI) {
    val bar = download().await()
    // Cancel could have been called now, but the following code is posted to a Handler and executed anyway
    performSomeWorkOnTheUI(bar) // Causes a crash after onPause
  }
}

override fun onPause() {
  job?.cancel()
}

A more elaborate example that consistently crashes due to the IllegalStateException thrown in onResume can be found here. The repo contains a complete executable project.

Is there any problem to allow the code to be excecuted on the main thread after onDestroy per se?

Actually I believe this issue isn't limited to the main thread or even onDestroy. I'd say no matter what thread, it is at least unintuitive that a coroutine can resume execution after the corresponding job has been cancelled.

The problem, as I see it, is with the code that tries to use that state that was already destroyed in an implementation of onDestroy.

First, I think we need to to define what a resumption is. Is it the process of posting coroutine code to a queue or is it the actual start of execution? I'd argue for the latter definition since it doesn't depend on the internals of the dispatcher and thus may be what users intuitively think when they don't specifically observe the behavior of the coroutine library, which isn't very easy to grasp.

Any program that assumes that code following a suspension point of call to a cancellable function will not be executed after the job is cancelled even on the same thread is broken right now. In the following example the call to bar() will cause a crash due to state modification that happened before resumption, even though it happened on the same thread and the job was cancelled already. If I didn't know better, I wouldn't expect this to happen since I'd expect bar not to run if it didn't yet, setting didBarRun = true in the process.

I am not yet convienced that the idea of directly modifing UI state from the coroutine is a sound arhitectural pattern that we shall endorce by providing the corresponding utility functions.

Are you sure people won't do this anyway even without proper library support? It compiles and seemingly works, except it will cause hard-to-debug crashes every once in a while, which will frustrate developers. I think the best you can do is provide appropriate tools to let them produce correct, though potentially architecturally unsound code.

Having given the above comment, I must stress that this is still an issue. It has to be solved.

Thanks for the acknowledgement and this discussion! 🙂

Thanks, I'll give that gist a try later today!

Asynchronous actions (coroutines) that are bound to UI lifecycle is a design smell, if I may say so.

I disagree. In the commonly used MVP architecture, binding asynchronous actions to the UI lifecycle is frequently done. For example, take a look at the CountriesPresenter in this example of the popular Mosby library. It fetches something from the network and then displays it in the UI, which is fine from a UX perspective if a progress indicator was shown before. It's also fine from a lifecycle POV since it checks isViewAttached() before accessing the UI in the callbacks.

This could be similarly achieved using RxJava, but without having to check isViewAttached():

var subscription: Subscription? = null
fun foo() {
  subscription = downloader.download()
                            .subscribeOn(Schedulers.io())
                            .observeOn(AndroidSchedulers.mainThread())
                            .subscribe { downloaded -> ... }
}
fun onPause() {
  subscription?.cancel()
}

I may be biased, but I've seen this pattern in a lot of apps already. Replacing it with the snippet from my initial post here seemed natural, but currently does not work as expected.

MVVM is an architecture that might work better with the current coroutine implementations in this library, but that I don't think architectures like MVP with asynchronous actions are a design smell. I'd argue that this library should ideally work well with all architectures.

E.g, when screen is rotated, then views should be destroyed and rebuilt, but all the models should continue to operate and to execute their asynchronous activities.

As mentioned before this doesn't apply when the application is finishing / shutting down. In that case, we're forced to either check isViewAttached() (or something similar, but after every suspending call, which is very error-prone) or have a reliable way of cancelling Jobs.

I hear your concern about channels, but I'm not familiar enough with the internals of this library to think of a solution. Thanks already for taking the time to investigate this!

I've played with this problem a bit and found the way to add the required cancellation behavior with a custom continuation interceptor. See this gist: https://gist.github.com/ilya-g/314c50369d87e0740e976818d2a09d3f

@elizarov Maybe you are right about not canceling it to present on resume, but, what if I want to:

override fun onPause() {
    if (isFinishing()) {
        job?.cancel()
    }
}

Then would be nice that using cancel really works, because our Activity no longer will be back and we know it. There are some checks that could be handled by the coroutine. metalabdesign/AsyncAwait, for example, do some checks and have different execution options, one safe that do some checks, another one that leave it do the developer.

@elizarov My bet, it doesn't really need to know. I know if we already downloaded, we should cache it and so on, but if my activity is finishing, maybe, trying to save it to cache can actually be harmful, what if saving to cache leads to a corrupt state? And actually, if I am calling cancel directly, I would expect it try to cancel as soon it can. If cancelling will stop me from saving to cache, then its my error as developer, not the library fault.

Android has the AsyncTask class, doing the same sample, using it, we got:

   @Override
   protected String doInBackground(String... params) {
      return download();
   }
   
   @Override
   protected void onPostExecute(T result) {
      super.onPostExecute(result);
      saveDownloadedDataToCache(result);
      performSomeWorkOnTheUI(result);
   }

onPostExecute(_:) method documentations states:

Runs on the UI thread after doInBackground(Params...). The specified result is the value returned by doInBackground(Params...).
This method won't be invoked if the task was cancelled.

As you can see, no cache either in this sample, but there are more callbacks in an AsyncTask, even one for cancelled tasks:

    @Override
    protected void onCancelled(@Nullable T result) {
      if (result != null) {
         saveDownloadedDataToCache(result);
      }
    }

Maybe some onCancelled, onError, finally handler can be used for it? Maybe another kind of flow control? metalabdesign/AsyncAwait, again, as example, had some experiments on it, like .awaitWithProgress(_:) that somehow can handle progress, or an chainable launch(_:) with onError and finally.

So trying to imagine something, could be:

  job = launch(UI) {
    val bar = download().await(finally={
      saveDownloadedDataToCache(it)
    })
    performSomeWorkOnTheUI(bar)
  }

OR

  job = launch(UI) {
    download().await().also {
      performSomeWorkOnTheUI(it)
    }
  }.finally {
     it?.let { saveDownloadedDataToCache(it) }
  }

I was looking through the coroutines guide, and there are some nice samples like the Run non-cancellable-block, maybe we could create different kinds of context like NonCancellable but for other uses, like for Updating UI, Data Flow, and so on.

  job = launch(UI) {
    val bar = download().await() // suspending call, and this can be made `NonCancellable`?
    saveDownloadedDataToCache(bar) 
    run(UISafe) { // UI call, cancellable-on-beginning, with safety-checks.
        performSomeWorkOnTheUI(bar)
    }
  }

Yet another option, maybe is too suggest, that for UI updates, we should have a suspending function, that somehow can use the UI Pool, and we can call it by, for example, .awaitOnUI().

  job = launch(UI) {
    val bar = download().await() // suspending call, and this can be made `NonCancellable`?
    saveDownloadedDataToCache(bar) 
    performSomeWorkOnTheUI(bar).awaitOnUI() // UI 'suspending' call, cancellable-on-beginning, with safety-checks.
  }

OR

  job = launch(UI) {
    val bar = download().await() // suspending call, and this can be made `NonCancellable`?
    saveDownloadedDataToCache(bar) 
    performSomeWorkOnTheUI(bar).await(UI) // UI 'suspending' call, cancellable-on-beginning, with safety-checks.
  }

Or yet, leave this one as it is, call it as Working-As-Intended, and add some AsyncTask wrapper, or just some implementation that can be chainable with an AsyncTask-like flow:

  launch(Android) {
    download().await().also {
      saveDownloadedDataToCache(it) 
      performSomeWorkOnTheUI(it)
    }
  }.onCancelled { 
     it?.let { saveDownloadedDataToCache(it) }
  }

Of course, maybe I am going too deep, maybe you are right, and we should create this ourselves for the projects we are working on, doing so in a generic way can be really tricky and we don't know how it will be used, but if any suggestion I made feel useful or interesting to you, maybe we can look further?

PS: Its late, I am tired, sorry if any inconsistency or redundancy in my text... Thank you for your time.