So I've been using Multiplatform for a while now a...

# multiplatform

[krtko]

So I've been using Multiplatform for a while now and I have been enjoying the current set up.
I think the features which would help me out the most are
1. Inline platform specific code: Helps onboarding new users and beginners. Helps prototyping and simple platform calls
2. Abstract specific platform code: Helps library creators and reduces nesting
1. Inline platform specific code:
Ex.

//LoginViewController is a pure kotlin class that inherits from the MPP class ViewController. ViewController contains several platform specific fields such as `context` on Android
class LoginViewController: ViewController {
   fun someButtonWasPressed() {
      //A button was pressed callback
      //uh oh we need to drop into native code for some reason
      android { //An auto generated inlined lambda for the Android MMP
         this.context //we have access to LoginViewController's Android side
         this.androidDoSomething(this.context)
      }
      ios { //An auto generated inlined lambda for the iOS MMP
         NSLog("You have access to anything from the iOS MP project")
         val appDelegate = UIApplication.shared.delegate as AppDelegate
      }
   }

   @platform("android") fun androidDoSomething(context: Context) { //can have platform specific arguments
      //this method can only be called from an android context
      Log.d("hi","from android")
   }
   //this could also be nested in some "subclass" like structure like `android { fun androidDoSomething(context: Context) {} }`
}

This produces messier and harder to read code in most circumstances, however I think it provides huge benefits in these particular cases:
1. Onboarding new users and beginners. Explaining the current MP project set up is not easy. I think if someone can start a project or contribute to a code base in the fashion above it will be significantly more clear to them. It's also a lot simpler to grasp out of the box vs the Actual/Expect system. Theres no indirection weaving back and forth between the different subproject for each platform.
2. Prototyping. The current Actual/Expect system works very well. It forces you to cleanly separate platform specific code from common code. Thats great except this can get in the way for when you are prototyping something and you just need to get the whole thing running in the most quick and simple fashion possible. I think the above system helps solve that as it reduces the need for nested platform code.
3. Simple platform calls. The current Actual/Expect system adds a lot of overhead for small platform specific methods. If the method is only ever going to be 1-3 lines per platform, its a lot of boiler plate to have a separate file for each platform specific instance of the method
----

2. Abstract classes with the ability to declare abstract specific platform code:
Ex.
Library author

abstract class ViewController {
   @platform("android") abstract fun getView(context: Context): View //even tho we are in common kotlin, the method declaration can access Android
   @platform("iOS") abstract fun getView(): UIView //even tho we are in common kotlin, the method declaration can access iOS
}

Library consumer

class LoginViewController: ViewController {
    @platform("android") override fun getView(context: Context): View {
         //inflate and return a view
    }

    @platform("iOS") override fun getView(): UIView {
        val view = UIView()
        return view
    }
}

Library authors can currently do something like this by having an Actual/Expect abstract class with specific abstract methods for a given platform. My main issue with doing this is its not as clear to the library consumer and it requires more class nesting than the example above
----

[Luoqiaoyou]

hi, I just started using MPP. I think the Inline will cause unreadable. Combining Jepack Compose with SwiftUI through the Kotlin compiler might be a better way to hide UI layer differentiation. For now, flutter may be better, but it requires an extra learning cost

[Luoqiaoyou]

Did you have any problems using kotlinx.serialization in MPP module？

[krtko]

What do you mean by "Combining Jepack Compose with SwiftUI through the Kotlin compiler might be a better way to hide UI layer differentiation."? Those are two different UI libraries that are a few years away from being stable.

[krtko]

Yes I've used kotlinx.serialization a lot. I've never had any issues with the library. Have u?

[Luoqiaoyou]

i transform a android lib into mpp lib, some code operate JsonObject. when i put a JsonObject into JsonObject will got error in ios. here is detail https://github.com/Kotlin/kotlinx.serialization/issues/759

[Luoqiaoyou]

Discussion of SwiftUI and jetpack frameworks. I would like to talk about the thinking behind both frameworks. For example, if both are declarative, it might be easier to turn Kotlin's Jetpack compose into SwiftUI with a compiler. Another way is for Jetpack compose to support IOS directly as MPP. Of course, none of them is stable yet.

[krtko]

Well one of the great features of Kotlin MP is using the platforms own view system seamlessly in your code. If theres ever going to be any bridging between Compose and iOS' view system thats a very long way off, as both of those libraries are a long ways off themselves.

[krtko]

Your serialization error looks like you are casting the JsonObject to the wrong type.
Why not just create a hash map of the json u want before serializing it?

[Luoqiaoyou]

JsonObject is a subtype of JsonElement and Map<>. Normally it should work. i do that,Because it's transform from android library, there's a lot of code and i want to make as few changes as possible.😂

[krtko]

Aren't you casting to MutableMap?

[krtko]

Most likely there isn't an underlying difference between MutableMap and Map on teh JVM/Android side

[krtko]

but on native there is

[Luoqiaoyou]

if i donw cast to MutableMap how can i modify the jsonobject

[Luoqiaoyou]

json {
     "data" to json {
         "status_code" to 0
     }
     "required" to jsonArray { +"s" }
}

this case cause same error