Trying to summarize the difference between the app...

# multiplatform

[Daniele B]

Trying to summarize the difference between the apps of the “past” and the apps of the “future”:

[solidogen]

I don't think view was ever tighly coupled to viewmodel, it's MVVM core principle

[Daniele B]

Leland Richardson explains it well here:
https://medium.com/androiddevelopers/understanding-jetpack-compose-part-1-of-2-ca316fe39050

[Daniele B]

This picture is explanatory:

[Robert Jaros]

It's all the matter of how distant past we are talking about (and how distant future as well 😉)

[Daniele B]

Future is now 🙂
DeclarativeUIs + Kotlin MultiPlatform

[Arkadii Ivanov]

My views stopped being coupled ~3 years ago, once I switched to MVI. I'm already in the feature. 😋

[Robert Jaros]

And it's still just one kind of apps - mobile. Even KMP is not only about mobile.

[Daniele B]

@Arkadii Ivanov exactly! MVI is the way ;-)
But with the classic view-based UIs you still have some degree of coupling.
Declarative UIs are what can dramatically decrease your boilerplate code and coupling.

[solidogen]

I think this graph is correct only in DataBinding scenario though.
Tight coupling is mostly between Fragment/Activity and XML layout because of findViewById or its alternatives, ViewModel does not really add to coupling in most scenarios

[Daniele B]

@Robert Jaros it’s not limited to mobile. You can already have a 85% KMP shared code, and use Koltin/React on the Web. But the most interesting perspective is Compose for Web, who I hope will come sometime soon.

[Daniele B]

@solidogen Not sure I understand what you mean. In the classic View-based system, the ViewModel needs to know which are the IDs of the UI components. That is coupling.

[Arkadii Ivanov]

I think declarative UI had nothing to do with coupling. It does not reduce nor increase it. Same level of coupling can be achieved with normal Android views.

[solidogen]

I meant that ViewModel doesn't need to know IDs, it doesn't search for them any way, it just lets other components observe data

[solidogen]

It depends on how you look at it

[Javier]

Why Android ViewModel has to know UI ids? You can even have a ViewModel in a module which know nothing about views, and the views module implements this ViewModel module.

[Javier]

The ViewModel class is coupled by the lifecycle APIs

[Daniele B]

In a View-based system, you need an extra layer of code that couples the data with the IDs of the UI components.
In the declarative UIs, you apply the data directly on the UI components, without dealing with IDs.

[Javier]

But that layer is not the ViewModel

[solidogen]

Yes, ViewModel is never tighly coupled to View. I think this is not what author had in mind. Ultimately, there is some coupling on ViewModel>Fragment>XML route like in graph, but ViewModel is not coupled at all

[Daniele B]

It depends what you call ViewModel.
In my definition, the ViewModel is anything providing the data to the UI.

[Daniele B]

It’s not necessarily the Android’s ViewModel component.

[solidogen]

It would be misleading to most people though, because of how this component is named

[Robert Jaros]

@Daniele B You are looking at KMP in one dimension only. But KMP allows you to also share code between the frontend and the backend. You are focusing on code sharing between different clients (where declarative UI is in fact the key), but it's absolutely possible, that in many cases much more practical gains/profits comes from code sharing between the frontend and the backend.

[Daniele B]

@Robert Jaros yes, I am focusing on the client-side of the story, which is the most crucial, as it’s what allows you to share 85% of the code which was previously platform-specific. The fact you can also use Kotlin on the server-side is a plus. In such case, the gain is to be able to share the data class definitions between the client’s datalayer and the webservices, which is good, but not paramount in terms of productivity.

[Daniele B]

@solidogen on my article (bit.ly/32Z3pqc), I explain thing in more details.
The shared ViewModel I talk about, in case of Android it’s actually wrapped inside the Android’s ViewModel component.

[jdamcd]

the top three points characterise the potential of KMM well, but the web services argument seems a bit reductive to me - "data optimised" could describe the big generic APIs of 10 years ago, and UI-oriented web services are often as much about moving logic to where it's less painful to change than avoiding client-side duplication

[Daniele B]

With KMP (or KMM, if you just want to consider mobile) client-side logic is inexpensive (no replication costs). This means that you can shift to the client-side any logic that previously you conveniently placed on the webservices.
In this respect, webservices can be UI-agnostic (or app-agnostic, if you want). They just need to provide data in the most optimized/normalized way, which is processed (just once for all platforms) by the client-side code.

[Marc Knaup]

Proper REST or GraphQL APIs were/are already UI-agnostic 🤔

Also APIs could move more towards realtime in general using Websockets, GraphQL subscriptions and alike. That would make them even more event-driven.
APIs could be focused more on flows of data & events rather than on pure data fetching. That would extend the data- and event flow-centered approach of declarative UIs to the back-end and tear down the barrier that currently exists between the two.

[Marc Knaup]

I don’t agree that apps/clients are becoming rich in general.
Yes, code reuse helps with that. But the way app updates are currently distributed work against that as it slows down update cycles. At least React Native is there as a compromise for now.

Look at cloud gaming for example. It’s moving all the way from fat clients to thin clients right now because technology finally allows that. Same could happen to apps at some point. Still a long way to go through as internet coverage and reliability isn’t anywhere near 100%.

[Marc Knaup]

I do agree on declarative UI and shared code though 🙂

[Daniele B]

I talk about “rich client” mainly in terms of data reuse, decreasing the number of situations where a user needs to wait (data fetching) for displaying the next screen.
“Rich clients” makes it very easy to apply complex logic to display data that has already been downloaded. Of course this could have been done even before, bit it came with a high cost of replicating the exact same code for each platform.
With client-side shared code, it’s very inexpensive to apply smart and sophisticated logic, enhancing the user experience.
I agree that there are contexts where it’s important to have the flexibility to makes changes just on the server-side, but this is not contradicting the great power of rich clients for the user experience.

[Marc Knaup]

In that case I’d recommend to not turn it into a general statement about apps but be more specific.
It looks like a general statement in the summary.

[Daniele B]

In this slide I am highlighting the fact that “rich client” capabilities are inexpensive. Then of course it depends on the app (and on the app architect) to define which logic makes sense to be kept on the client-side and which on the server-side.
But surely, with KMP we have greater flexibilities in terms of client-side logic.