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/
Xem thêm Bài Viết:
- Hướng dẫn cách lắp anten ngoài trời đúng kỹ thuật, thu sóng khỏe nhất
- Giải đáp bí ẩn Xamarin là gì? Ưu và nhược điểm khi sử dụng Xamarin
- Tuyệt chiêu sửa lỗi window photo viewer can’t open this picture because
- Bộ nhớ đệm là gì? Có nên xóa bộ nhớ đệm trên thiết bị không?
- Bật mí 3 cách chụp ảnh bằng máy tính win 7 dễ như ăn kẹo
20 Comments
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
How do you guys test this much complicated scenarios?
Anybody else thought that that timer is sloppy programming? @20:36
Kotlin discover async/await from C# #justKidding xD
thanks
It would be great if they put the slides in somewhere
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!
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.
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.
Best explanation of coroutines i've seen!
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.
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?
so tell me how does this work with MVVM which has a repo, viewmodel and view !!!!
do you seriously think that coroutines are easier than mvp with rx? I was expecting something really easy but got frustrated.
Sorry but worst talk ever. I could not be anymore confused.
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.
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…
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?
Yes
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?