Visual thought on UI structures

When a developer needs to develop a UI app which will have some scale, the quest for better maintainability, performance, readibility, ease of coding and testability is not straightforward.
From MVC to MVP via MVVM, the ages have seen different answers to this question. But what does it basically means?
From an mobile developer point of view I’ll try to divide the essential components of an classic featured-full android app. After that we just need to put each unique functionnality into the good block of the pattern.

Sample App

The application will be, hummm let’s say a GPS. This kind of app has multiple dynamic views, forms input, complex algorithm, lots of data, networks and asynchronous actions, …
Every use case exemple will be chosen from this perspective.

Dividing the functionnalities of an app

Notes

Logic and control are similar. Control would be more application-technical oriented to handle page opening, algorithm launch (gps fix lost, then launch a suite of position prediction according to speed)… Logic would be a set of logic rules related to business need (If a SuperBurger restaurant is around then add it to the map).

Schematisation

The following graphs are my interpretation of these pattern. They consist on grouping the different functionalities above into related block.

Model View Controller

In an android app, the view would be the xml layout while the controller is the associated activity java code. In simple XAML/C# this structure is pushed forward by hardly associating a C# code with any XAML layout file.

Model View Presenter

The main difference with MVC is splitting the java code of the activity in two. The code who is layout dependant (findViewById, setText) stay in the activity, and is considered as a View which become a dual-file system. The functionnal code (startActivity, …) is moved to the associated Presenter.
It becomes easy to change the View while keeping most of the code in the Presenter.

Model View ViewModel

This pattern becomes more declarative as we connect the data value and user edition with the model container directly. The VM is somewhat a proxy between both of them and control the data lifecycle.
Note that the non-visible UI interaction becomes declarative, like the sound. And that the view allow itself to connect to background services result.

Binding/qml

This one is my interpretation of a pure QML app developement (no C++ except for very extensive functions). It becomes even more declarative than MVVM.
Developing this app would require to follow these ideas:

  • The app heavily rely on signal/slot connection for data, action, dynamism
  • All UI are declaratives blocks in one file, declared in a way to be higly independant from the exterior
  • Very fiew code is outside the view, gathered in presenters/manager files.

Coding becomes very declarative, you think only of the behaviour of the smallest block, exposing signal and slots for every other component to interact with, in a complete loosely way.

The declarative config pattern

Some portion of code above was declarative, usually the view (these blocs had a green background). But most of the functionnalities of the app have to be developed by code.
From some developers point of view, this fact will soon be history. Powerful software would be able to generate the program directly from the user cases. Have a look at such articles

On the way to this User-Interface coding, we can find the config-oriented pattern.
The code consist mostly of a framework. All views, actions, interactions are somewhat configured in a custom format within one are multiple file.