https://kotlinlang.org logo
Join SlackCommunities
Powered by
Hi guys. Hopefully this is the best place to ask. ...
# multiplatform
g
Hi guys. Hopefully this is the best place to ask. I'm currently evaluating building our app in Kotlin Multiplatform. There is a separate iOS project being developed, but the idea is to keep the door open to implement the iOS version in the KMM project later down the line. I've been researching app architectures, and there doesn't seem to be a main consensus on the best one to use (even a link to a page on the kotlin homepage discussing this is no longer available). One of the requirements is we'll be using Jetpack Compose and SwiftUI, and it seems only the MVI pattern allows us to be truly multiplatform without separate presentation logic and testing. The issue is that most of these articles i've been reading are a few years old now, and I wanted to know what the latest recommendations are? I found the todoapp example project which seems to satisfy our requirements. Would this be the recommended way to go? https://github.com/JetBrains/compose-jb/tree/master/examples/todoapp (edited)
👍 1
m
Not quite sure about the latest recommendations, as far as I know there isn’t any established convention as to what would be the optimal pattern. You can take a peek here to see different approaches: https://github.com/terrakok/kmm-awesome#-architecture
I’m doing some form of MVVM with a shared VM (+ Combine wrapper on Native iOS) and it seems to be decent.. To me it looks like you can really have the business logic fully shared, but native implementation, such as the Combine wrappers, need to still be implemented
g
@Matti MK Thanks, I'll take a look! Some of that I've already seen, but definitely a few things I haven't yet.
a
I'm also working on a kmm banking app with ios and android and we are using an arcitecture like on that example https://github.com/Kotlin/kmm-production-sample
we call "VideModel" as "ViewStore" and all the viewstores are in common module and they expose a single state object as a flow a side effect flow and a navigation flow
the pattern is very smilar to redux
m
How do you handle threading for iOS, for example, in networking?
a
For the networking part we are using ktor
and the new memory model of kotlin
which is uder development right now
m
Oh neat! I kinda want to switch to the new model as well 😅 but not sure
a
its version 1.6.0-M1
m
Are you in production yet?
a
we ll be in like 1 year so im a bit relax about choosing the new mm
we also moved string resources to de multiplarform side
m
Nice! I’ll try to be in prod in about 1 month so not quite sure about switching over to the new MM 😄
a
ehehe 😄 dont !
also its not compatible with the compose compiler yet
m
So you are not using compose then?
a
we sould swtich between compiler versions right now
we are using but we are using 1.5.31 for android
m
Same here
a
Because there is no problem about concurrency on android
m
Yup, Android is very straightforward thankfully
a
we can use any version on android
but on ios its pain in the ass so we are using new mm
m
For iOS, did the new MM solve the old issues for you? In terms of no more freezing / run time crashes?
a
yes nor more freeig
freezing
its wonderful 😄
m
So just launch coroutines on 
Dispatcher.Default
and everything just works 😄 ?
a
yes
m
I might really switch over, my user base should be quite low at first, unfortunately maybe 70/30 split between iOS / Android
a
the only obstacle is compose compiler
m
Once you figure things out let us know how you solved the obstacles, would be nice to hear 👍
a
new memory model ll be in beta in 2022 spring
g
Thanks guys! I also had questions about the MM, it was a sticking point when the team evaluated KMM earlier this year, but thankfully it looks like it's going to be a non issue
a
👍
l
@Graeme Laws if you're looking for a 'simpler' example, that uses the same concepts as the todoapp (which uses MVIKotlin and Decompose), I made 2 very basic demo apps just showing that (of course using MVI in this case). The MVI example also uses ktor https://github.com/falcon4ever/KMM-demos
❤️ 2
g
@Laurence Muller Thank you! very helpful
@Laurence Muller I'm new to both MVI and MVVM (I'm from a game dev background, and have recently moved into business apps), I wondered if you could answer a quick question. Ours is a relatively small application, it only needs a few things like user authentication, a webview to manage the bulk of the apps content shared with the web version, settings screen, and a few other screens that use an SDK from another area in the company. I'm expecting to have some issues with the SDKs and KMM, but that's not important at right now. I've read that KMI is quite complex, and a lot more effort than using MVVM, however the trade off seems to be that you can't unify as much code with MVVM as you can with KMI, there needs to be separate coding for unit tests and presentation logic. Would you think the extra effort required for KMI is worth it in comparison to having to write platform specific tests and presentation code? Apologies if you haven't used MVVM before, but I thought worth asking!
l
I'm currently rewriting a travel app and explored some MVVM (based on Google/Android's tutorials) but I find MVI (together with MVIKotlin/Decompose) way easier/nicer to use. No longer need to have so many livedata watchers in your UI code and it makes the actions (user input or triggered by some service) predictable
I mean, MVVM might be ok to use with the old view systems, but for Compose/SwiftUI I think MVI just takes away a lot of hassle
of course my opinion, but that's how I feel about it. I'd be cautious about using webviews (unless you don't have a choice ofcourse), they can make app development a lot more painful.
g
OK, perfect, thank you. I have read that MVI was recommended for using with Compose and Swift UI on KMM specifically, but I read a lot of posts where people found it unnecessarily complicated compared to MVVM, but they were speaking from a Native Android point of view, and unfortunately KMM is relatively new, so I've not found many people discussing this.
No, I don't have a choice with the webview. I'm rewriting an education app, and the original version has the content written into the app, but they want to be able to share the same content as the web version. I haven't actually had the discussion about why they decided to implement it as a webview, so I'll bring it up tomorrow to find out their thinking.
l
I think when you come from a traditional background (android/xml / ios/storyboards/xibs) it takes some time to understand the mental model. It took me a while wth 'remember' was doing in the code and even though Decompose/MVIkotlin make things easier, i had to do multiple takes on the docs before i fully understood what was going on. Many kudos to @Arkadii Ivanov for his patiences and explaining things here on slack and on github (and for create the awesome libs).
g
Oh, was it this channel you had these discussion in? It might be helpful for me to read them to understand some of the concepts you had problems with.
l
I mean, people that say it's unnecessarily complicated either are just old school or stubborn... (or maybe dont have a choice). App architectures change over time, if you can't adjust, software development is not the place to be. I think that KMM for sure is a bit more challenging (we currently have 2 independent apps) and I think since it's in alpha stage you can expect things to break quickly but get fixed quickly too
#mvikotlin is the place if you have more questions about that particular library
g
Yeah, I've noticed a lot of hesitancy to try new things with some developers. I've been told I can go ahead and write it Android Native if I want, but I like the idea of integrating the iOS version in later down the line.
l
If you're coming from Native Android (and only doing Google's way of Android using AAC/ViewModels I can imagine that one is probably heavily invested in the google android ecosystem with ViewModels, Room etc etc, so MVVM is the obvious choice (well before Jetpack Compose came around)). I'm trying to stay away from those since they lock you into Android only code.
g
I'm actually not too used to Android UI. I've been working for 2 years on embedded apps for hardware running on Android OS, that haven't had a screen. So the only time I touched any UI was to build a debug menu. So I'm learning fresh. I have some experience with flutter previously, so frankly using Jetpack Compose is a lot more appealing to me than the old system.
m
I wouldn’t be fully convinced that KMM at this point is the best approach if you are not familiar with Android / iOS. Not saying that it’s not a valid option, but the road might be more rocky than the fully native approaches. The reasoning for this is that the tooling and material available for fully native approaches is on a different level.
g
@Matti MK Yes, I'm fully aware this is going to be a steep learning curve, and the support and sophistication of the tools on native will be a lot better. However, we've discussed this and agreed that we will try it out first and switch to native if it's problematic. The iOS version is fully native at the moment, but we're just investigating multiplatform for Android, as we can salvage the Kotlin code if things don't work out.
m
That seems like good way to approach the problem, hope you can utilize KMM to it’s fullest potential 👍
👍 1
🙏 1
Open in Slack
PreviousNext
Powered by