Types of U.I.s

Command Line Interfaces

Typically used nowadays for "expert" tools or tools which should support automation.

 

Problems:

• it is not user friendly at all; 
• it has very limited visual display capabilities.

 

 

Desktop applications

Problems:

• Usually OS dependent,
• User needs to have dedicated software installed.

 

Initially built for any kind of scenario, nowadays mostly focused on computationally / visually expensive or real-time applications.

Native Apps

Problems:

• Usually OS dependent,
• User needs to have dedicated software installed.

 

They can offer access to native capabilities, have offline support, have a more consistent look & feel, and have a uniform distribution model.

Web applications

Historical problems:

• Heterogeneous browser support,
• No offline support,
• No native capabilities,
• Less performant.

 

The clear advantage is that users do not need to install anything else than a browser. Nowadays, most of the above problems are solved.

MV* Architecture

Introduction

The first complex user interfaces that were built hit a big problem: the user interface logic and state was mixed with the rest of the application.

 

This is because most applications are actually driven by the U.I.

 

To circumvent this, the application code was split into:

• Model (the domain - for example the services and entities),
• View (the purely presentational components),
• * (the glue, which can be of several flavors).

Model - View - Controller

MVC: arguably the simplest MV* pattern.

 

Also comes in several flavors (depending on which of the three components directly communicate with each other).

Other MV* patterns

• MVP: Model - View - Presenter: decouples the "Controller" of MVC from the view by introducing an interface for the view (inversion of control).

 

• MVVM: Model - View - View Model: for each view, a dedicated view model is constructed which binds the properties and events of the view with fields and methods of the model.

Observer

Purpose

The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.

Pitfalls

• Memory leaks due to observers never being detached thus never being garbage collected.
• Event hell: cyclic dependencies between subjects causing a waterfall of events.
• Timing issues: events lost due to the observer being attached too late to the subject.