Don't hard code Dispatchers.Main.immediate

[rjrjr]

WorkflowLayout and now AndroidDialogBounds.kt hard code use of Dispatchers.Main.immediate. Make them look for that in the ViewEnvironment. Maybe also give them a shared implementation of View.takeWhileAttached. Maybe.

[rjrjr]

Also consider adding a useful name to the scope, e.g.:

      val scopeName = window.peekDecorView()?.getTag(R.id.workflow_modal_dialog_content)
        ?.let { contentView ->
          contentView as View
          contentView.getRendering<Any>()?.toString()
        }
        ?: this@maintainBounds.toString()

      scope = CoroutineScope(Dispatchers.Main.immediate + CoroutineName(scopeName)).also {

[rjrjr]

@steve-the-edwards @RBusarow @vRallev Thinking about this hard coded Main.immediate issue and wondering if we actually care.

• We've been shipping this way for nearly two years and haven't noticed
• In the spot where it happens
  • with the current code it's torn down when the view goes away
  • with the fix this week (WorkflowLayout.start needs a Lifecycle, BackStackScreen is supported. #632), it will be torn down when the activity instance is torn down
• both of those things happen in our Espresso tests before any of our custom injected dispatchers are cleaned up

tl;dr: no harm, no foul, let's not introduce complexity that won't solve any actual problems.

[RBusarow]

It's not a big deal.

Espresso handles syncing with the main thread automatically. Hard-coded dispatchers only become a problem if you leave the main thread, and there's basically zero risk of that here.

[rjrjr]

The only remaining non-test, non-deprecated use of this is in AndroidDialogBounds, and it looks like it would be pretty silly to make it configurable:

    override fun onAttachedToWindow() {
      scope = CoroutineScope(Dispatchers.Main.immediate).also {
        bounds.onEach { b -> onBoundsChange(this@maintainBounds, b) }
          .launchIn(it)
      }
    }