<@U2E974ELT> ohh, I forgot to add link to the proj...

# coroutines

[gildor]

@elizarov ohh, I forgot to add link to the project repo, I should sleep more 😅
https://github.com/gildor/kotlin-coroutines-android

[elizarov]

gildor: Thank you. Here is a feedback for coroutine dispatcher implementation in android module. I cannot comment on the android lifecycle stuff, though (I’m not an expert in Android). I’ve also found deficiencies in the kotlinx.coroutines dispatcher implementations themselves during this review. Committed a fix for the next version.

Comments here explain rationale. Feedback is welcome: https://github.com/elizarov/kotlin-coroutines-android/commit/459baf9a8d0c1fe39159bb795de1cb6d3df5d3ad

[elizarov]

Here’s feedback for retrofit Call.await(): https://github.com/elizarov/kotlin-coroutines-android/commit/d6b6658cd4fd4f859c341bd1c2d73e171b72aab7

[gildor]

Wow, really helpful feedback. I will merge your changes to my code and keep your comments I think it will be really helpful for everyone who writing code with coroutines.
I will provide rationale for Android lifecycle, main idea to create coroutine for Android that lifecycle-aware (to avoid memory leaks) that works on main thread by defaullt.
Also I want to implement coroutine wrapper for Android Dialogs

[elizarov]

I’ve actually added all the comments to the documentation of the corresponding kotlinx.coroutines functions for next release. You are welcome to keep them in your code, too.

[kenkyee]

How would coroutines avoid memory leaks? You can still get them with rxjava if the lambdas hold references to views and you don't unsubscribe.

[elizarov]

They will not, if you hold references to views from your coroutines. However, you can write a simple utility library that cancels all the coroutines that were created in the context of the view when it disposes. It should be quite straightforward to create a Job object that is linked to your view lifecycle (e.g. cancel it when view is disposed) and then create all your coroutines as children of this job.

I'm not an Android expert, though. It looks like @gildor is writing something along these lines in his android helper library.

[gildor]

@kenkyee Yeah, it’s not a way to avoid all memory leaks by magic, it’s just a way to create coroutine that implicitly subscribed on life-cycle events to cancel your coroutine onPause/onStop/onDestroy, same idea that used in RxLifecycle but also you shouldn’t register coroutine explicitly to lifecycle events, because in my implementation you create coroutine using lifecycle extension function