One of the best Android Jetpack movement, I am only waiting for Kotlin and KSP fixes for Room to work when its entities is in a separate module for KMM.
When I use BundledSqliteDriver, the db file is always in a locked state in app inspection window. If I am using android sqlite driver for android and native for iOS the database is open. and I can see data. Anyone faced this ??
Overall it's cool that Room is now in KMP 😎 But setting up the drivers will be a total disaster for devs. Why can't we just have an annotation, which receives specific variables, that generates drivers per platform? Hope this will be considered in the next release.
I'm at the early stage of building a new KMP project and I setup the database with SQLDelight and it's been great. Should I change it to Room or it doesn't matter?
What a nightmare.... It's cool that works.... But setting up the driver for each platform sux. Can't this step be autogenerated too? Or at least provide a default implementation
@@hinocenciopaulo I've never used Realm for KMP, so I don't know how it works. I think that if you work with multiple platforms, the setup should be simpler. In Flutter, for example, you just need to import the lib and use it... no extra setup. In KMP, I see a tendency to delegate more than necessary to the developer... this can be good because it allows customization of use and the API will hardly change, but in practice, for simple use cases, it's just bureaucratic (there's still the problem that no one is an expert in all platforms). In a real KMP project, you end up having dozens of initializations like this.
@@theolm "dozens" is quite the overstatement, most developers will support 4 platforms max (library authors have a different story tho, but I don't think that's different for Dart library devs either). To be clear, this is not a KMP limitation per-se, but a deliberate design decision by the Room team, as they wanted to optimize for customization first. They could've provided a common API function to create the database in common code, but they chose customizability first here (which maybe a tiny bit more effort at first, but it's not really that bad, you're always in control, and you only ever have to do it once). Maybe this can be something they can add in the future. Another note is that KMP works quite differently to Dart/Flutter. Dart lives in its own little sandbox, and then interacts with the outside world through FFI or other mechanisms. That has its benefits, like a unified interface for developers to access all of these platforms, and less cognitive overhead (to an extent). But has drawbacks, like a not-so-seamless interaction with the underlying platform (the Dart/Flutter devs and famous libraries do an amazing job here, but if you ever have to do it yourself, it's a bit icky). Kotlin blends into the target environment instead (e.g. on JVM, it's Java bytecode, on native, it gets merged with Obj-C/Swift LLVM bytecode) and can interact with it directly without any middle layers, which provides a different set of expectations and capabilities. You'll always find Kotlin Multiplatform code leaning towards _some_ amount of glue code right in your project, because it's very free to do so, and you don't even need to change the language. Still, you'll be covered from head to toe for 95% of cases using KMP libraries, sparingly ever needing to touch platform-specific code. Both are valid and awesome technologies, but have different technicalities! Some people like to call Dart "cross-platform" and KMP "multi-platform", but these words don't make much sense to me, since a lot of the use cases overlap anyways. KMP is still maturing (very fast!), but it's looking quite promising, building on Kotlin's already solid foundations.
To answer your question: yes, they could've definitely made a function for common-code with sane default implementations. That makes a good feature request!
That's what I was about to comment, like it's cool during the first half but everything after that is a total disaster. Oh how I wish this will be updated to be auto generated per platform.
Subscribe for the latest updates → goo.gle/AndroidDevs
bro jetpack is becoming cooler and cooler every day ........ and I love it
Given how involved the steps seem to be, saying "It's definitely easier said than done," at the end was a stab to my heart!
One of the best Android Jetpack movement, I am only waiting for Kotlin and KSP fixes for Room to work when its entities is in a separate module for KMM.
KMP support opens up so much Room for all your Pet projects
When I use BundledSqliteDriver, the db file is always in a locked state in app inspection window. If I am using android sqlite driver for android and native for iOS the database is open. and I can see data. Anyone faced this ??
We are grateful
Love Android, keep improving!
Overall it's cool that Room is now in KMP 😎 But setting up the drivers will be a total disaster for devs. Why can't we just have an annotation, which receives specific variables, that generates drivers per platform? Hope this will be considered in the next release.
great video, love Kotlin and KMP
Wow, Room improvement
I'm at the early stage of building a new KMP project and I setup the database with SQLDelight and it's been great. Should I change it to Room or it doesn't matter?
What a nightmare.... It's cool that works.... But setting up the driver for each platform sux. Can't this step be autogenerated too? Or at least provide a default implementation
Which db does that? Realm? You have to do the same for Sqldelight.
@@hinocenciopaulo I've never used Realm for KMP, so I don't know how it works. I think that if you work with multiple platforms, the setup should be simpler. In Flutter, for example, you just need to import the lib and use it... no extra setup.
In KMP, I see a tendency to delegate more than necessary to the developer... this can be good because it allows customization of use and the API will hardly change, but in practice, for simple use cases, it's just bureaucratic (there's still the problem that no one is an expert in all platforms). In a real KMP project, you end up having dozens of initializations like this.
@@theolm "dozens" is quite the overstatement, most developers will support 4 platforms max (library authors have a different story tho, but I don't think that's different for Dart library devs either).
To be clear, this is not a KMP limitation per-se, but a deliberate design decision by the Room team, as they wanted to optimize for customization first. They could've provided a common API function to create the database in common code, but they chose customizability first here (which maybe a tiny bit more effort at first, but it's not really that bad, you're always in control, and you only ever have to do it once). Maybe this can be something they can add in the future.
Another note is that KMP works quite differently to Dart/Flutter. Dart lives in its own little sandbox, and then interacts with the outside world through FFI or other mechanisms. That has its benefits, like a unified interface for developers to access all of these platforms, and less cognitive overhead (to an extent). But has drawbacks, like a not-so-seamless interaction with the underlying platform (the Dart/Flutter devs and famous libraries do an amazing job here, but if you ever have to do it yourself, it's a bit icky).
Kotlin blends into the target environment instead (e.g. on JVM, it's Java bytecode, on native, it gets merged with Obj-C/Swift LLVM bytecode) and can interact with it directly without any middle layers, which provides a different set of expectations and capabilities. You'll always find Kotlin Multiplatform code leaning towards _some_ amount of glue code right in your project, because it's very free to do so, and you don't even need to change the language. Still, you'll be covered from head to toe for 95% of cases using KMP libraries, sparingly ever needing to touch platform-specific code.
Both are valid and awesome technologies, but have different technicalities! Some people like to call Dart "cross-platform" and KMP "multi-platform", but these words don't make much sense to me, since a lot of the use cases overlap anyways.
KMP is still maturing (very fast!), but it's looking quite promising, building on Kotlin's already solid foundations.
To answer your question: yes, they could've definitely made a function for common-code with sane default implementations. That makes a good feature request!
That's what I was about to comment, like it's cool during the first half but everything after that is a total disaster. Oh how I wish this will be updated to be auto generated per platform.
Love the room puns
Great oogl shirt by the way!
We Need Exoplayer library and Google maps library for multiplatfrom (Kotlin/Compose). Please move also that libraries. Thanks.
In-memory instance still not available?
For tests the is one i think
@@GakisStylianos not for junit
And what about unit testing in the commonTest module? When will we be able to share the in-memory db ?
Love itttttttttt
Как она весело говорит, что у вас всё сломается)))
a little more of boiler plate code, but manageable
Tanisalim mi?
more kmp，please
For the love of god. Please stop using white bg and bright color on these videos. Please make dark mode friendly videos.