This is my proposed solution for issue https://github.com/metalabdesign/AsyncAwait/issues/25.

• Create two callback methods that are used whenever a coroutine starts execution in a different thread or when all coroutines finish.
• Create an idling resource implementation that register those callbacks and resumes execution only if there are no coroutines being executed.
• Create an espresso test that verifies the new feature works just as expected.

I followed a very similar approach to what Jake Wharton used for OkHttp3 (https://github.com/JakeWharton/okhttp-idling-resource/blob/master/src/main/java/com/jakewharton/espresso/OkHttp3IdlingResource.java). I thought it was better to create two different callbacks to hide as much as possible from the implementation, though.

Personally, I'd recommend to release this feature as a different module so that developers can load the new dependency only for testing builds but being such a small feature I'd understand including it in the very same library.

Thanks for this library - it is really nice to see Async/Await coming to Android. I have a question about the sequence of execution. Consider this example

async {
   progressBar.visibility = View.VISIBLE
   // Release main thread and wait until text is loaded in background thread
   val loadedText = await { loadFromServer() }
   // Loaded successfully, come back in UI thread and show the result
   txtResult.text = loadedText
   progressBar.visibility = View.INVISIBLE
}
someOtherCodeHere()
yetMoreAwesomeCodeHere()

I understand that when we hit await { loadFromServer() }, the execution of the async block is suspended and the control proceeds to someOtherCodeHere(). Is this right?

Also, what happens later when loadFromServer() returns? I assume then txtResult.text = loadedText and the rest of the async block is executed. But, then what? Where does the execution proceed after an async block that had been suspended is un-suspended?

@tsuharesu please take a look how we gonna solve the memory leak issues by calling async.cancelAll. This function should be call when object is not needed anymore (like in Activtity.onDestroy). The significant changes are in AsyncUi.kt file. Thanks!

Hi, I discovered JetBrains (and probably other contributors) made a coroutines Android implementation on the kotlinx.couroutines repo, and I assume you were aware of this while building this library.

Could you add a word in the README.md or another file in the repo on how your implementation and the kotlinx one compare together in different regards such as performance, API design and features (and more if useful)?

Hi,

In a project where I intentionally set android:allowBackup="false" in the <application .../> tag of my manifest, and it clashes with this library, because it's defined here. These attributes should be removed.

Hi,

I was just wondering how hard is to implement/expose some sort of mechanism to be able to create idling resources that wait for the coroutines to finish.

I can try sending you a PR if you point me in the right direction on what you think is the best way to do it. I think it'd be a great addition to the library.

Given a situation where UI elements depend on the AsyncController (like progress bars) while having to cancel tasks, it's necessary to know when a task was cancelled in order to hide progress and such

Currently we need to cancel all the async on destroying Activity.

override fun onDestroy() { super.onDestroy() async.cancelAll() }

With the new component called Lifecycle (Reference link below) we can skip it and the library can itself take care of it by understanding the lifecycle.

Refer: Lifecycle Architecture Component

When I try to execute several tasks in parallel my code looks ugly.

async {
           await {
               async {
                   await {
                       async {
                           await {
                               val it = System.currentTimeMillis()
                               while (System.currentTimeMillis() - it < 5000);
                               Log.w("Executing coroutine", "Task1")
                           }
                       }
                       val it = System.currentTimeMillis()
                       while (System.currentTimeMillis() - it < 5000);
                       Log.w("Executing coroutine", "Task2")
                   }
               }
               val it = System.currentTimeMillis()
               while(System.currentTimeMillis() - it < 5000 );
               Log.w("Executing coroutine", "Task3")
           }

           Log.w("Executing coroutine", "All tasks completed")
       }

Is any way to make parallel execution looks more elegant? Something like this

 async {
            awaitParallel  {
                val it = System.currentTimeMillis()
                while (System.currentTimeMillis() - it < 5000);
                Log.w("Executing coroutine", "Task1")
            }
            awaitParallel  {
                val it = System.currentTimeMillis()
                while (System.currentTimeMillis() - it < 5000);
                Log.w("Executing coroutine", "Task2")
            }
            awaitParallel  {
                val it = System.currentTimeMillis()
                while (System.currentTimeMillis() - it < 5000);
                Log.w("Executing coroutine", "Task3")
            }
            Log.w("Executing coroutine", "All tasks completed")
        }

Fragments from the support-v4 library are recommended for usage over native Fragments, given they are always up-to-date on bug fixes and when new features are added. Plus, it is more likely that someone will be using Support Fragments in their app rather than native Fragments.