Hi folks, I am trying to figure out the workings o...
# touchlab-tools
k
Hi folks, I am trying to figure out the workings of the KaMP kit and i saw the creation of
NativeViewModel
in the shared code. Wondering if that is needed for avoiding any concurrency issues on native or is it because android ends up using the standard android
ViewModel
component and we are trying to create a VM for Native with almost the same functionality except android specific one. Another query I had was, if instead of doing a MVVM architecture, if I create a project structure in MVP(going a bit old school), can I put both my Model and Presenter in common code and avoid creating 2 different ViewModels that are platform specific. Considering KaMP kit uses MVVM, I am sure this debate would have come up in the past and would be very glad if you could share its outcome and avoid me some future pains 😂.
r
We wanted the Android side of KaMPKit to use Android built-ins for coroutine handling, so it scopes things in an architecture components
ViewModel
. Then
NativeViewModel
is a place where iOS can handle scoping in parallel fashion. It also gives a layer for the native side to convert suspend functions to callbacks for consumption from Swift, which isn't necessary for Android since it's coroutine-aware the whole way through.
Regarding MVP, you certainly can do so and some people are. However in that case you need to do more work on the Android side to make sure you're handing configuration changes. Using the architecture components ViewModel allows us to shortcut that and is the Android team's official recommendation, but it's not the only way to do it.
k
Thanks @russhwolf that does make sense. So the tradeoff is doing more work on each platform for different VMs vs handling all common logic somewhere in a presenter but config changes in android 🙏