The entire software stack revolves around services. All communication happens over HTTP or WebSockets because it is the only thing that browsers support. All services are packaged into developer-friendly objects via providers, which take care of asynchronous requests, possible caching and error handling. The display and manipulation of the data is then the responsibility of the screens, which in turn use recurring widgets.

Architecture overview

Services

Services come in the two categories HTTP or WebSockets.

HTTP

HTTP is used where classic requests make sense and no bidirectional communication is necessary. This applies, for example, to the API for adding or deleting locomotives, changing device settings or querying the current system status. The following endpoints are defined for HTTP.

/dcc/locos/
- DELETE
- GET
- PUT
/settings/
- GET
- POST
/sys/
- GET
/*
- GET

WebSockets

WebSockets are used where fast bidirectional data communication is necessary. This primarily affects all the different APIs for firmware and sound updates, e.g. DECUP or ZUSI, but also the Z21 endpoint. The following endpoints are defined for WebSockets.

/decup/zpp/
/decup/zsu/
/mdu/zpp/
/mdu/zsu/
/ota/
/z21/
/zusi/

Providers

The frontend uses Riverpod providers as a state management solution. Different types of providers (e.g. NotifierProvider or FutureProvider) encapsulate the services and allow reacting to state changes through their reactive API. The created providers are injected into the user code by inheriting from special so-called ConsumerWidgets.

For a detailed description of each provider see Providers.

Screens

Screens are... well, screens. A screen is essentially a display-filling widget. The only difference to a "smaller" widget is that there is only ever one instance of a screen and when you switch from one screen to another, the entire display usually changes. It is also helpful to distinguish screens from widgets in order to find a clear vocabulary. It is much easier to explain a list of tiles on the decoder screen to someone than a list of widgets on a widget (although that is essentially what it is).

For a detailed description of each screen see Screens.

Widgets

Widgets are user-defined GUI elements that combine Flutter’s own classes. A classic example of such a widget are the dialogs shown during firmware and sound updates or the locomotive controller.

For a detailed description of each widget see Widgets.

Previous	Next
Configuration	API Reference