Viele Benutzeroberflächen entstehen auf Basis von Webtechnologien. Dennoch sind native Applikationen weiterhin für viele Anwendungsfälle der bessere Ansatz oder sogar alternativlos. Sowohl Desktopprogramme mit Hardwareanbindungen als auch mobile Apps fordern die Entwicklung für ein bestimmtes Betriebssystem.

Native Applikationen haben Vorteile wie gute Performance, natives Look and Feel und direkten Zugriff auf angeschlossene Hardware. Zu den Nachteilen gehören spezifische Codebasen für jedes Betriebssystem, Unterschiede zwischen den nativen APIs und eine umständliche Installation der Software.

Die Idee von Cross-Plattform-Frameworks ist, zumindest den ersten beiden Nachteilen zu begegnen. Besonders für schnelle Ergebnisse mit wenig Aufwand sind Frameworks eine gute Wahl. Dynamische Sprachen ermöglichen schnelle Ergebnisse. Soll die Applikation lediglich für ein, zwei Jahre laufen, können Entwicklungsteams bedenkenlos zu solchen Frameworks greifen.

Will ein Team aber eine Anwendung zehn oder mehr Jahre weiterentwickeln, muss es verschiedene Aspekte kritisch hinterfragen: Wie lange entwickelt der Hersteller das Framework weiter? Genügt die Unterstützung von Android, iOS und Web? Reicht die Performance einer Web View? Soll die Anwendung neu aufkommende UI-Technologien oder Betriebssysteme integrieren? Wie laufen (automatisierte) Tests, um die Qualität hochzuhalten?

Langlebigkeit durch einen herausgelösten Core

Da sowohl Cross-Plattform-Frameworks als auch UI-Technologie einem schnellen Wandel unterliegen, liegt es nahe, das UI vom beständigen Teil zu trennen. Diese Idee ist durch die hexagonale Architektur bekannt. Mit dieser können sich Entwicklerinnen und Entwickler auf die Kernfunktionen konzentrieren und technische Notwendigkeiten als Ports definieren, die von außen an den Core andocken. Bei einer Cross-Plattform-Anwendung ergeben sich Ports für die Benutzeroberfläche und andere plattformspezifische APIs. Beispiele für APIs sind Zugriffe auf die Kamera oder das Dateisystem. Der Core beinhaltet die vollständige Geschäftslogik und alle weiteren Teile der Applikation, die Bestand haben und lange leben sollen.

Auswahl der Core-Programmiersprache

Der herausgelöste Core muss auf allen anvisierten Plattformen laufen. Als Beispiel für Zielplattformen seien Android, iOS, Windows, macOS und Raspberry Pi definiert. Als Kriterien einer für den Core geeigneten Sprache sind Stabilität, Robustheit, Langlebigkeit und Flexibilität wichtig.

Eine Programmierumgebung gilt als stabil, wenn sie produktionsreif ist und nur noch wenigen grundlegenden Änderungen unterliegt. Robustheit bezieht sich auf den in der Programmiersprache geschriebenen Code. Die Sprache soll weiterhin ermöglichen, den Code zu erweitern, umzuschreiben und für die nächsten zehn Jahre verständlich zu halten.

Dafür muss auch die darunterliegende Sprache langlebig sein. Auch soll sie sich möglichst flexibel verwenden lassen und am besten alle großen Betriebssysteme, Single-Board-Computer, Mikrocontroller und den Browser abdecken. Für diesen Artikel fiel die Wahl auf die Programmiersprache Rust, die sich für zahlreiche Plattformen verwenden lässt.

Rust für den Core

Rust ermöglicht mit vertretbarem Aufwand die Gestaltung eines wartbaren und performanten Core für flexible Einsatzgebiete. Die Sprache läuft auf allen Desktop-Betriebssystemen, mobilen Endgeräten, Single-Board-Computern, vielen Mikrocontrollern und via WebAssembly durch kompakte wasm-Module auch gut im Browser.

Die explizite Syntax von Rust begünstigt die Entwicklung robuster, lange wartbarer Software. Nachteilig sind die Komplexität, die steile Lernkurve und die im Vergleich zu JavaScript oder C++ kleinere Community. Allerdings wächst die Beliebtheit von Rust und damit auch die Community. Das zeigt sich auch durch die an vielen Stellen verlautete Migration von C zu Rust.

2021 wurde die Rust Foundation von AWS, Google, Huawei, Microsoft und Mozilla gegründet. Heute unterstützen viele weitere Firmen die Foundation, darunter Meta, JetBrains und Threema. Die Unternehmen sind daran interessiert, die ursprünglich von Mozilla ins Leben gerufene Sprache lange zu pflegen.

Architektur des Core

Nach der Auswahl der Sprache ergibt sich die Frage der Architektur für den Core. Je größer der Anteil der Anwendung im Core ist, desto stärker wiegen die Vorteile des Architekturansatzes, ohne weiteren Aufwand verschiedene Plattformen abzudecken. Das bezieht sich insbesondere auf Logik und Zustand, aber auch auf Übersetzungen für die Mehrsprachigkeit.

Um die Idee der Architektur besser begreifen zu können, dient im Folgenden als Beispiel eine simple App für das Speichern von Namen und E-Mail-Adressen.

Die auf der Benutzeroberfläche zu rendernden Daten muss man ebenso vorbereiten wie die an Buttons oder Eingabefelder gebundenen Aktionen. Wenn Anwender die E-Mail-Adresse ändern und durch Drücken eines Buttons speichern, soll der Core Schnittstellen für die aktuellen Daten, die Änderungen und für den Bestätigungstext bereitstellen, die sich direkt an den Oberflächencode anschließen lassen.

Klare Trennung durch MVVM

Im Entwurfsmuster MVVM (Model View ViewModel) kapselt das Modell die fachlichen Daten – und gegebenenfalls den Zustand. Das ViewModel enthält eine Aufbereitung dieser Daten, um sie in der View (Benutzeroberfläche) ohne weitere Bearbeitung einbinden zu können. Der Core stellt das ViewModel bereit. In Rust definiert kann es ein einfaches Struct sein:

ViewModel {
    name: String,
    email: String
}

UI-Aktionen als fachliche Aktionen

Bei der UI-Entwicklung lösen native Elemente wie Widgets und Controls technische Events aus, beispielsweise buttonXYClicked(). Diese Events führen zu fachlichen Aktionen wie „ändere E-Mail-Adresse“. Der Core stellt Schnittstellen für diese Aktionen zur Verfügung. Die Aktionen sind so gestaltet, dass eine Anwendung sie direkt an die UI-Elemente anbinden kann. Somit ergeben sich Aktionen, die optimal für das UI und gleichzeitig fachlich geschnitten sind.

In Rust kann die Liste an Aktionen ein Enum sein:

pub enum Actions {
    ChangeName(String),
    ChangeEmail(String),
    ApplyChanges,
}

Verwaltung des Zustands

Auch den Zustand verwaltet der Core. Das UI bleibt zustandslos: Es schickt Aktionen an den Core und reagiert auf die Änderungen im ViewModel. Der Zustand kann ein einfaches Struct sein, das im Speicher gehalten wird:

pub struct ViewModel {
    pub name: String,
    pub email: String,
}

pub enum Actions {
    ChangeName(String),
    ChangeEmail(String),
    ApplyChanges
}

struct State {
    name: String,
    email: String
}

impl Default for State {
    fn default() -> Self {
        State {
            name: "".into(),
            email: "".into()
        }
    }
}

pub struct App {
    state: State
}

impl App {
    pub fn new() -> App {
        App {
           state: State::default()
        }
    }

    pub fn do_action(&mut self, action: Actions) -> ViewModel {
        match action {
            Actions::ChangeName(name) => {
                self.state.name = name;
            }
            Actions::ChangeEmail(email) => {
                self.state.email = email;
            }
            Actions::ApplyChanges => {}
        }
        self.render_view_model()
    }

    pub fn render_view_model(&self) -> ViewModel {
        ViewModel{
            name: self.state.name.clone(),
            email: self.state.email.clone()
        }
    }
}

impl Default for App {
    fn default() -> Self {
        Self::new()
    }
}