The client-server pattern perpetuates power imbalances, and “Super apps” make that problem much much worse.
It’s just something you keep repeating, but that’s just not true. Coupling the UI with the business logic of the application is a fundamentally wrong approach. It makes it effectively impossible to compose apps the way you can compose command line utils with piping. Apps should be designed as client/server by default, and then you could always leverage the service API for the app any way you want, slap a custom UI, use it in automation scripts, etc. It’s just way more flexible that way.
@yogthos Nobody in their right mind couples UI to business logic, we have MVVM for that and it enables some very impressive integration and UI switching in apps.
However, thinking at the application level is ignoring everything I just said about the ways that apps communicate.
@yogthos MVVM stands for Model-View-ViewModel, and is a pattern commonly used in dotnet and winui apps for decoupling backend business logic from frontend UI.
What on earth do you mean by “no app provides APIs to access the business logic layer outside the UI?” These apps are using APIs to begin with, the app doesn’t NEED to provide them. The devs provides them to the app, the other way around.
I understand how MVC works perfectly fine. This is not what the discussion is about. What you’re being told is that apps you’ll find in the wild typically DO NOT provide APIs that can be leveraged in the way I described. You completely ignored that.
Show me what Android or iOS apps can be used at API level to create a custom UI on top of them using a third party app.
@yogthos Everything, this entire thread and several others that people have started with you.
It’s worth saying twice:
The client-server pattern perpetuates power imbalances, and “Super apps” make that problem much much worse.
It’s just something you keep repeating, but that’s just not true. Coupling the UI with the business logic of the application is a fundamentally wrong approach. It makes it effectively impossible to compose apps the way you can compose command line utils with piping. Apps should be designed as client/server by default, and then you could always leverage the service API for the app any way you want, slap a custom UI, use it in automation scripts, etc. It’s just way more flexible that way.
@yogthos Nobody in their right mind couples UI to business logic, we have MVVM for that and it enables some very impressive integration and UI switching in apps.
However, thinking at the application level is ignoring everything I just said about the ways that apps communicate.
Pretty much no app provides APIs to access the business logic layer outside the UI. You’re just trolling at this point.
@yogthos MVVM stands for Model-View-ViewModel, and is a pattern commonly used in dotnet and winui apps for decoupling backend business logic from frontend UI.
For example, this: https://youtu.be/Nb6fEeYfDAU
I feel like I’m the one being trolled here.
What on earth do you mean by “no app provides APIs to access the business logic layer outside the UI?” These apps are using APIs to begin with, the app doesn’t NEED to provide them. The devs provides them to the app, the other way around.
I understand how MVC works perfectly fine. This is not what the discussion is about. What you’re being told is that apps you’ll find in the wild typically DO NOT provide APIs that can be leveraged in the way I described. You completely ignored that.
Show me what Android or iOS apps can be used at API level to create a custom UI on top of them using a third party app.
@yogthos
Also— nobody is telling me. I’ve been doing this for over a decade.
Show me what Android or iOS apps can be used at API level to create a custom UI on top of them using a third party app.
@yogthos Bro that’s not how apps work. What you’re describing is a platform.