7 ms·

Kotlin Multiplatform looks really cool and limiting code sharing to non-UI code makes much more sense to me. However, I wonder if/when/to what extent the abstra

Kotlin Multiplatform looks really cool and limiting code sharing to non-UI code makes much more sense to me. However, I wonder if/when/to what extent the abstractions become leaky. For me it makes perfect sense to e.g create an internal API client using this. You use platform specific frameworks for making the actual HTTP requests[1], but can write all higher level business logic in Kotlin and expose that. Adding a new REST route or change data validation would be done only once and be in sync on all platforms. But I'm guessing that you have to pretty knowledgeable about the underlying platforms to know how (and if it's even possible) to create a good abstraction above the platform code. For something like audio/video playback or BLE, I'm guessing that there might be enough differences between Android and iOS that an abstraction that fit both is really unwieldy. And even if you create something resonable today, one of the platforms might introduce new features which destroys your abstraction. [1]: I noticed that they even have some kind of built-in HTTP client abstraction: https://kotlinlang.org/docs/mobile/use-ktor-for-networking.html#select-an-engine https://kotlinlang.org/docs/mobile/use-ktor-for-networking.h...

dakna 6y ago
> noticed that they even have some kind of built-in HTTP client abstraction It goes one step further, you can have platform-neutral code to parse the API returns into Kotlin models. https://blog.jetbrains.com/kotlin/2020/10/kotlinx-serialization-1-0-released/ https://blog.jetbrains.com/kotlin/2020/10/kotlinx-serializat... A lot of business logic is shared in the domain layer on each platform client (and possibly on the server), and I think re-use of that is/will be Kotlin's main selling point. Add SQLDelight for shared data access code on clients, and you can cover a lot of ground with one codebase.
tootie 6y ago
What exactly is the value of this though? Isn't most non-UI code going to be buried in your server APIs no matter what? Most apps end up being 90% UI code.
- ffggvv 6y ago
  that’s not true at all. especially for apps like netflix or youtube, but even average apps source: have worked on apps you likely use every day
  - tootie 6y ago
    I've worked on plenty of small to mid-size apps and that's not how we ever do it. Like I said, we build views and API requests. That's just the same MVC framework for the past decade or so. And I've done the same for streaming services albeit not at the scale of Netflix. Given how apps like Netflix and YouTube are so nicely synced between mobile, web and STBs I'd still imagine all the logic and persistence is server-side. I can only speak from my experience though, I'd love to understand how you've done it and when you need to embed a lot of non-UI code in a client.
    - filleokus 6y ago
      Both Netflix and Youtube (premium) can be used completely offline. I would guess that the iOS and Android apps have a pretty encompassing local data model to keep track of everything from watched status to settings changed in the preferences. Not to say that it isn't synced with the server, but the server isn't the only representation.
    - ffggvv 6y ago
      most MVC apps do still have a decent amount of business logic for things like caching (either http responses, or images, or a local db), authentication etc.. In theory the goal for a lot is to have a dumb client like you said but that's rarely the case. If you can have your apps share their data models between both android and iOS you can have the apps share the HTTP request/response handling and their DB code etc and then it truly becomes just a dumb client. YouTube/Netflix also have complex video encoding/playback code that can be written in c++ and shared between clients. Most social media apps liek FB/Insta/Snapchat have complex camera and photo handling code as well as async messaging code. Which if you have things like retries or photo compression/encryption you'd probably want to share between clients. etc..
liuliu 6y ago
I am really curious to see people's take on Kotlin Native's compiler. From what I can see with Swift compiler development, there are tons of bugs when compiling down a high-level language. Of course, part of these Swift problems can be that the team choose to pursuit performance and low-overhead above everything else (which complicated the implementation quite a bit). But still, I wonder what Kotlin has done differently to make Kotlin Native reasonably cheap to maintain going forward.
- mrath 6y ago
  I believe kotlin does not persuit performance and low overhead. But given that there are multiple variants of kotlin compilers (js, jvm, native) I think it will be a lot of work to maintain that, any behaviour need to be done in three places. Assuming that JetBrains can make some money from the Tools they sell, kotlin is probably in the right hands. May be good also have some vested interest for Kotlin to suceed.
  - snappytrap 6y ago
    fyi Jetbrains is combining the js, jvm, and native compiler pipelines. All three will use the IR infrastructure currently used by kotlin/native.
lubesGordi 6y ago
Wait, are you suggesting to use http 'internally' meaning within the same process on the device?
- filleokus 6y ago
  No. Internal as in to “your” backend API’s.

dakna 6y ago

> noticed that they even have some kind of built-in HTTP client abstraction It goes one step further, you can have platform-neutral code to parse the API returns into Kotlin models. https://blog.jetbrains.com/kotlin/2020/10/kotlinx-serialization-1-0-released/ https://blog.jetbrains.com/kotlin/2020/10/kotlinx-serializat... A lot of business logic is shared in the domain layer on each platform client (and possibly on the server), and I think re-use of that is/will be Kotlin's main selling point. Add SQLDelight for shared data access code on clients, and you can cover a lot of ground with one codebase.

tootie 6y ago

What exactly is the value of this though? Isn't most non-UI code going to be buried in your server APIs no matter what? Most apps end up being 90% UI code.

ffggvv 6y ago
that’s not true at all. especially for apps like netflix or youtube, but even average apps source: have worked on apps you likely use every day
- tootie 6y ago
  I've worked on plenty of small to mid-size apps and that's not how we ever do it. Like I said, we build views and API requests. That's just the same MVC framework for the past decade or so. And I've done the same for streaming services albeit not at the scale of Netflix. Given how apps like Netflix and YouTube are so nicely synced between mobile, web and STBs I'd still imagine all the logic and persistence is server-side. I can only speak from my experience though, I'd love to understand how you've done it and when you need to embed a lot of non-UI code in a client.
  - filleokus 6y ago
    Both Netflix and Youtube (premium) can be used completely offline. I would guess that the iOS and Android apps have a pretty encompassing local data model to keep track of everything from watched status to settings changed in the preferences. Not to say that it isn't synced with the server, but the server isn't the only representation.
  - ffggvv 6y ago
    most MVC apps do still have a decent amount of business logic for things like caching (either http responses, or images, or a local db), authentication etc.. In theory the goal for a lot is to have a dumb client like you said but that's rarely the case. If you can have your apps share their data models between both android and iOS you can have the apps share the HTTP request/response handling and their DB code etc and then it truly becomes just a dumb client. YouTube/Netflix also have complex video encoding/playback code that can be written in c++ and shared between clients. Most social media apps liek FB/Insta/Snapchat have complex camera and photo handling code as well as async messaging code. Which if you have things like retries or photo compression/encryption you'd probably want to share between clients. etc..

liuliu 6y ago

I am really curious to see people's take on Kotlin Native's compiler. From what I can see with Swift compiler development, there are tons of bugs when compiling down a high-level language. Of course, part of these Swift problems can be that the team choose to pursuit performance and low-overhead above everything else (which complicated the implementation quite a bit). But still, I wonder what Kotlin has done differently to make Kotlin Native reasonably cheap to maintain going forward.

mrath 6y ago
I believe kotlin does not persuit performance and low overhead. But given that there are multiple variants of kotlin compilers (js, jvm, native) I think it will be a lot of work to maintain that, any behaviour need to be done in three places. Assuming that JetBrains can make some money from the Tools they sell, kotlin is probably in the right hands. May be good also have some vested interest for Kotlin to suceed.
- snappytrap 6y ago
  fyi Jetbrains is combining the js, jvm, and native compiler pipelines. All three will use the IR infrastructure currently used by kotlin/native.

lubesGordi 6y ago

Wait, are you suggesting to use http 'internally' meaning within the same process on the device?

filleokus 6y ago
No. Internal as in to “your” backend API’s.