i'm really interested in how the coroutine model w...

# coroutines

[jw]

i'm really interested in how the coroutine model will translate into that as well. i'm glad others are taking the plunge. i'm trying to follow along on issues and the like, but not getting my feet wet just yet.

[spierce7]

Probably better to use a thread than pollute the main channel. My team moved to a new project early in the year, and lots of things got delayed on the server, and we don't have a deliverable until Q2 next year. We've spent a lot of time experimenting with cross platform arch's and trying to push as much as possible into common modules. We've found lots of things we don't like.

[jw]

Things you don't like about what common modules force you to do or only about kotlin/native?

[spierce7]

Basically the coroutine model for Kotlin/native will be that only frozen objects can move between threads. You will have to call freeze() on an object, effectively making it immutable, and then it will be able to be able to be shared with the coroutine scope.

It's my understanding that multi-thread coroutines require some additional work for the native compiler, and once that's implemented they will circle back and add it to the kotlinx.coroutines. They just released single-threaded coroutines

[spierce7]

Most of the issues I've found with common modules have to do with IDE scalability. Most of the things we've found we don't like I was more or less talking about different architectures we've experimented with.

[spierce7]

We tried a lot of things. Creating an MVVM framework, moving normal processing off of the main thread, etc. Thinking through how the Kotlin/native threading model would work threw a wrench into a lot of different things. We're currently refactoring things to a fairly standard MVP / main thread appraoch.