Coroutines are a feature of Kotlin that help convert callback-based code into sequential code, making code easier to read, write, and understand. This session will show you how to use coroutines on Android, and how the new androidx-concurrent library makes it easy to use them to get things off the main thread. You’ll also learn how the new library helps coroutines work with Architecture Components. This session also covers coroutine patterns, best practices, and even how to test coroutines!

Watch more #io19 here:
Android & Play at Google I/O 2019 Playlist →
Google I/O 2019 All Sessions Playlist →
Learn more on the I/O Website →

Subscribe to the Android Developers Channel →
Get started at →

Speaker(s): Yigit Boyar, Sean McQuillan, Sergey Vasilinetc

TF7514

Nguồn:https://u-os.org/

Author

20 Comments

  1. Dexter Aparicio Reply

    I wonder how different is the problem domain, that they abandon any iota of similarity and feel of the usual POSIX synchronization primitives. I can see that the new lambda construct has a big role in this, but the whole thing is constructed in not-invented-here fashion

  2. Darko Martinović Reply

    Anybody else thought that that timer is sloppy programming? @20:36

  3. L. Kärkkäinen Reply

    These brand-spanking new coroutine concepts are explained in their inventor's blog https://vorpus.org/blog/timeouts-and-cancellation-for-humans/ Kudos to Kotlin team for adopting scopes, cancellation and testing concepts of Trio in such a comprehensive manner!

  4. Дмитрий Толстов Reply

    why there is viewModelScope and no repositoryScope, or applicationScope. A lot of work done in reposiory calling db and network, I don't need viewModelScope because I return already-made livedata from repo. Also, there are a lot of work I would like to do during my app is running and ok with cancelling it when it's gone. I don't get it.. And there is still NewtorkBoundResource in App Arch Guide on android dev website… it's not thaht coroutiny.

  5. Ankit Gusai Reply

    The goal is basically set at 4:26 but at the end of the video it feels like(as always) we are back to square one.
    On the hindsight making anything comprehensive and simple with fragment + activity with their lifecycles is incredibly complex. Throw in a service(Which connects asynchronously and has its own foreground limitations) that needs to be connected and you have to throw everything out of the window.

  6. so many methods and so many scopes. It feels like patch work rather than a complete solution to handling thread calls and orientation changes. Specially in case of fragment. I am sure in future a lot more stuff will come to fix what is done right now. IMHO fragments itself should be re-written. For a beginner this is a very steep learning curve.

  7. 10:23 : transforming to another representation from stack to whatever is used for supsendables and then back when resuming, and copying stuff sounds a bit comp intensive, I don't see why we couldn't build separate substacks for the suspendables in the main stack and switching into them and back when necessary. no copying and transforming involved. or am I dumb and threads couldn't manage that and point to other substacks like that temporarily?

  8. so tell me how does this work with MVVM which has a repo, viewmodel and view !!!!

  9. Kroken Stiv Reply

    do you seriously think that coroutines are easier than mvp with rx? I was expecting something really easy but got frustrated.

  10. Weedy Beats Reply

    Coroutines are horrible. They are complicated. They don't throw an readable and understandable error to the console when something goes wrong (and something WILL go wrong). They don't allow UI changes.

  11. Looking at the actual code of the LifecycleCoroutineScope, I don't think it works the way they claim. Specifically, I don't see any code that would cause coroutines started with 'launchWhenStarted' to suspend when the state is < STARTED. The only thing LifecycleCoroutineScope seems to actually do is cancel when the lifecycle owner is DESTROYED. I'm wondering how much of this talk is actually useable…

  12. Sorry but who are these developers you guys are supposedly talking to? How many completely different async solutions are there now for Android? Like 30? Do all these developers constantly want to learn new ways to perform async tasks?

  13. DiegoTube85 Reply

    I don't get how Coroutines are presented as an "easy" solution.. They are very hard instead to use properly. I'm trying get it but it's far from easy.. Am I the only one?

Write A Comment