Just gave an 1h 20m presentation to our head offic...

# multiplatform

[darkmoon_uk]

Just gave an 1h 20m presentation to our head office advocating a K/MP strategy for the future of our product... 🤞fingers crossed!

[Sean Keane]

I have to do the same. Any tips?

[darkmoon_uk]

I can't tell if it was successful yet so I can't vouch for the tips 😉 But strong points I identified were... that much of the work we would do to transition our (large, mature, Java code-base) to Kotlin Multi-platform would have numerous added benefits due to the language safety; and the Unit Testability would increase due to moving from MVC to MVP (Passive View).

[darkmoon_uk]

See, we are currently running on Android only but the company want to support iOS and are exploring a number of options.

[Sean Keane]

Why MVP and not MVVM?

[Sean Keane]

Have you seen the Moko MVVM sample? https://github.com/icerockdev/moko-mvvm

There are some advantages to be had with this. You can share view models across all platforms and then keep your view native with much less interfaces and cleaner streams using observers.

I plan on going this approach with our system as we build SDK’s and exposing a VM to allow clients to build their own view on top of our logic through observers and actions makes sense.

[darkmoon_uk]

Thanks, this is worth considering... The reason for MVP:
It's familiar to our team, simple, supports Unit Testing very well (via test 'View' implementation) and also lends itself well to representing User Interactions as suspending functions in the View Contract.

[darkmoon_uk]

MVP (particularly the Passive View flavour) also minimises the volume of code in the View layer, pushing more into the Presentation layer where it can be shared.

[darkmoon_uk]

I'm genuinely curious about MVVM but it previously struck me as unnecessarily complicated compared to MVP with no tangible advantage - what am I missing?

[Sean Keane]

But if you go the MVVM route you can actually reduce the code in the view much more and allow for even micro updates based on observers. Keeping your code incredibly clean in the view. all you will do is get a reference from your view model, then listen to observers from it.

The other advantage is that you can use multiple VM’s based on components if you wish. Treating them like use cases for a view, but this isnt as popular, although it is possible.

Testing of the VM is incredibly easy also. There is no real mocking of interfaces out of the VM. You can assert observers are being called when an action is performed on the VM.

So, in essence.
• With MVP you will create a View, Interface for View and Presenter, and Presenter.
• With MVVM you will have a View and a View Model.
MVVM is the current architectural approach of Android, so you will gain a massive advantage by using the components that they provide.

We have a full system built on MVP, but turning those views into standalone components isn’t as clear cut as it is with the MVVM model. These are just a subset of reasons.

[darkmoon_uk]

@Sean Keane Thanks for the info and inspiration to look into it more deeply.

[Thomas]

representing User Interactions as suspending functions in the View Contract.

Kotlin suspend functions are not visible from Swift code. So keep in mind that suspend functions need to stay in the Kotlin part.

[darkmoon_uk]

@Thomas Right, but we're intending to write iOS in 100% Kotlin - which is possible, right down to the AppDelegate and main functions.

[darkmoon_uk]

See: https://git.chrishatton.org/chris/kotlin-multiplatform-template/blob/master/Code/Client/iOS/Example/src/iosMain/kotlin/main.kt

[Thomas]

That will work fine, too. The reason I went with Kotlin and Swift is so you can easily use (Apple's) Swift frameworks. For example the new SwiftUI can not be used from Kotlin, unfortunately.