KEEP
kotlinx.coroutines
Our great sponsors
KEEP | kotlinx.coroutines | |
---|---|---|
40 | 48 | |
2,623 | 10,755 | |
2.9% | 1.8% | |
6.2 | 9.0 | |
about 1 month ago | 1 day ago | |
Kotlin | ||
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
KEEP
-
Toying with Kotlin's context receivers
KEEP: Context receivers
-
Java record pattern matching in JDK 19
I'd be very interested in a comparison between scala 3 using/given and Kotlin new context receivers https://github.com/Kotlin/KEEP/blob/master/proposals/context...
- Why no one recommends the use of the standard library's Result class but a custom sealed class approach?
-
[Question][Kotlin] Dexter Runtime Permissions development has stopped, whats the alternative?
This will be furthermore simplified with multiple receivers coming very soon
-
Combining scripts and DSLs is Kotlin’s most underrated feature
I’m realizing I forgot to mention the scripting proposal in the post, will add it soon.
-
Java 20 looks like it may be one of the biggest updates in years
Tfw no pattern matching. :(
- Encapsulate successful or failed function execution
-
Preview of Kotlin 1.6.20 With Prototype of Context Receivers, Parallel Compilation on JVM, Incremental Compilation in JS
I hadn't gone over the Context Receivers design proposal until now (and still doing so, so take this with a grain of salt), but the use of what is seemingly a function call(but not) to define them seems like a bad choice. I'm sure there are design constraints that pushed this option forward, but it just seems really odd and out of place in the current Kotlin language design.
-
JSpecify: Express specifications (initially, just nullness properties) in a machine-readable way
I'm aware that kotlin decided against this in kotlin itself, see https://github.com/Kotlin/KEEP/issues/82.
- State of Valhalla
kotlinx.coroutines
-
New candidate JEP: 428: Structured Concurrency (Incubator)
Here's a GitHub issue going into how utterly confusing Kotlin's coroutine error handling is: https://github.com/Kotlin/kotlinx.coroutines/issues/763
-
Why no one recommends the use of the standard library's Result class but a custom sealed class approach?
Sure! runCatching catches Throwable right? Well when you cancel a coroutine it throws a CancellationException and this gets used as a signal to stop execution. runCatching stops that signal so the coroutine keeps running. Lemme find you a link real quick https://github.com/Kotlin/kotlinx.coroutines/issues/1814
-
Struggling with Espresso IdlingResources and coroutines
Recently, a Dev helped with adding an IdlingResource dispatcher provider to help with coroutines. See https://github.com/Kotlin/kotlinx.coroutines/issues/242
-
Is there thread switching when moving from Default dispatcher to IO dispatcher using withContext?
According to the author of kotlinx.coroutines lib, it will try to keep the same thread if possible but not always. After my question, he updated the document of Dispatchers.IO to be like this https://github.com/Kotlin/kotlinx.coroutines/pull/3236/files This dispatcher and its views share threads with the [Default][Dispatchers.Default] dispatcher, so using `withContext(Dispatchers.IO) { ... }` when already running on the [Default][Dispatchers.Default] dispatcher typically does not lead to an actual switching to another thread. In such scenarios, the underlying implementation attempts to keep the execution on the same thread on a best-effort basis.
I think it is a great question and you can ask it on github
This is the issue I posted in GitHub https://github.com/Kotlin/kotlinx.coroutines/issues/3234 Thank you for the suggestion
-
Am I on the right track?
DI: Dependency injection: Check out Dagger Hilt, Koin or Kodine. Architecture: Android tends to be MVVM but, MVP, MVI and some others exist. Async calls: For kotlin, coroutines. Rxjava can be used with kotlin or java. I'm not actually sure how java devs do asyn calls these days.
- Tests run slowly with StateFlow and mocked ViewModel
-
Deprecated/Hidden Flow.collect(action) in coroutines 1.6.0 what's the correct replacement?
FlowCollector is now fun interface, and corresponding inline extension is removed (#3047).
-
Build, Test and Deploy your Android Application📱 with GitHub Actions 🤖
Kotlin based, Coroutines + Flow for asynchronous.
What are some alternatives?
kotlin-coroutines - Examples for coroutines design in Kotlin
kotlin - The Kotlin Programming Language.
compose-jb - Compose Multiplatform, a modern UI framework for Kotlin that makes building performant and beautiful user interfaces easy and enjoyable.
okio - A modern I/O library for Android, Java, and Kotlin Multiplatform.
korim - Korim: Kotlin cORoutines IMaging, Bitmap and Vector graphics for Multiplatform Kotlin
KorGE - KorGE Game Engine. Multiplatform Kotlin Game Engine
spring-kotlin-coroutine - Kotlin coroutine support for Spring.
korio - Korio: Kotlin cORoutines I/O : Virtual File System + Async/Sync Streams + Async TCP Client/Server + WebSockets for Multiplatform Kotlin 1.3
kroto-plus - gRPC Kotlin Coroutines, Protobuf DSL, Scripting for Protoc
coroutinesmanager - Some helpful kotlin coroutines manager classes and extensions CoroutinesManager
jackson-module-kotlin - Module that adds support for serialization/deserialization of Kotlin (http://kotlinlang.org) classes and data classes.