Kotlin Multiplatfom In Action
0 likes28 views
The document discusses reasons for using Kotlin Multiplatform including writing code once that can run on multiple platforms, sharing business logic between server and client apps, and accessing native platform APIs from Kotlin. It notes Kotlin Multiplatform allows optional code sharing so only common code is shared. It also discusses why other cross-platform solutions may not be ideal and provides an overview of Kotlin/Native and concurrency in Kotlin.
Kotlin Multiplatfom In Action
- 7. Why share code? • DRY • same code/logic for different platforms • productivity, features, less bugs, more platforms
- 8. Why share code? • crossplatform in the past • networking library in C • Windows Mobile • Windows • Android • Linux
- 9. Why share code? • sharing entire components • JVM servers can share business logic with Android apps • All client apps share similar logic and features
- 11. Why share code? • Mobile platforms share a lot in common
- 12. Why NOT share code? • Performance • Slower innovation • shared UI • All or nothing • Vendor lock-in • Future • Bugs/lack of features
- 13. Why use Kotlin Multiplatform? • modern, industrial language • similar to swift, easy for java devs to learn • great tooling, ecosystem and community • open-source • write once, run native everywhere
- 14. Why use Kotlin Multiplatform? • doesn’t limit you to subset of all platforms • native access to entire platform API from Kotlin • each platform get native, optimized binary • fix bug once, for all platforms • interoperability • optional sharing
- 15. Why use Kotlin Multiplatform? optional sharing
- 16. Why not other solutions? • Flutter, React Native, Xamarin • not same usecase • sharing UI - risky • new language, new tools, new libs • accessing platform APIs is hard, bridges • frameworks
- 18. Why not other solutions? “Anything that requires you to make large decisions and potentially large rewrites, perform large retrainings and rehirings, or anything that has to share UI or doesn’t work well with a native platform is, well, very risky.” - Kevin Galligan, Touchlab
- 20. JetBrains • Coroutines • Ktor • kotlinx.serialization
- 21. • SQLDelight • okio • okhttp? Touchlab • Stately
- 23. How to start? • Android Studio • InteliJ IDEA
- 31. Expect/actual declare expected class/fun/property in common code actually implement in platform-specific code
- 35. Kotlin/Native • iOS, Linux, Windows, MacOS, WebAssembly... • build full apps or libs • access to native platform APIs • interoperable with C/ObjC(/Swift) • Kotlin can call C/ObjC/Swift and vice-versa • Kotlin can extend ObjC/Swift classes and vice-versa
- 36. Concurrency is hard • languages/runtimes allow unsafe concurrency • tools - locks & volatile • no warnings • deadlocks • entire burden on devs • no guaranties of safety • bugs leak into production
- 37. Saner concurrency • new, stricter memory model • ARC with cycle collector • 2 simple rules • Immutable state can be shared among threads • Mutable data belongs to one thread • compiler and runtime check the rules • thread-safe code
- 38. Saner concurrency ＋GC per thread, no suspends ＋shared reference counter with swift －no global mutable state －new concepts, patterns, practices －coroutines
- 39. Saner concurrency • Any.freeze() • passing mutable data by detaching • No manual concurrency management • Workers • Atomics - AtomicRef/Int/Long/... • “Stranger threads” (link in resources)
- 40. Saner concurrency • work in progress • multithreaded coroutines • similar rules for JVM • relaxed memory model
- 42. Status • beta but relatively stable • low-risk • production • large projects - wait for release • smaller projects - maybe • part of a project - yesterday
- 44. resources: cutt.ly/kmp-ns email: mmitic89@outlook.com android-serbia slack: @Marko Mitić kotlinlang slack: @Marko Mitic