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()
    }
}

Ab dem 9. Oktober 2025 sind Banken und Sparkassen im Euroraum verpflichtet, SEPA-Überweisungen in Euro auf Kundenwunsch in Echtzeit durchzuführen. Dies gilt neben Online- und Telefonüberweisungen auch für den Überweisungs-Service am Schalter. Das verlangt die Verordnung (EU) 2024/886. Echtzeit bedeutet, dass das Geld innerhalb von maximal zehn Sekunden beim Empfänger angekommen und der Sender über den Eingang informiert sein muss. Für Fehlschläge gilt dieselbe Benachrichtigungsfrist. Durch die Verordnung stehen Echtzeitüberweisungen damit künftig auch Kunden von Banken wie der DKB und der ING vollumfänglich zur Verfügung.

Zusätzlich müssen die Institute bei sämtlichen SEPA-Überweisungen im Euroraum den Empfängernamen und die IBAN untereinander abgleichen. Gibt es Abweichungen, müssen sie den Sender warnen, bevor er die Überweisung freigibt. Mit dieser sogenannten IBAN-Namens-Prüfung oder englisch „Verification of Payee“ (VoP) will die EU Bankkunden besser vor Betrug schützen.

Bereits seit dem 9. Januar 2025 müssen Banken in der Lage sein, Echtzeitüberweisungen zu empfangen. Für Echtzeitüberweisungen wie nun auch VoP dürfen die Institute seither außerdem nicht mehr Entgelt verlangen als für eine SEPA-Standardüberweisung. Kostet eine Überweisung regulär 25 Cent, darf die Bank auch für die schnelle Variante nur 25 Cent verlangen. Sind Überweisungen pauschal im Kontoentgeltmodell inbegriffen, gilt das auch für solche in Echtzeit.

Das war die Leseprobe unseres heise-Plus-Artikels „Online-Banking: Echtzeitüberweisungen und IBAN-Name-Prüfung kommen“.
Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.

Im Mai 2025 gewann der humanoide Roboter Tien Kung (auch Tiangong Walker) des chinesischen Robotikunternehmens UBTech Robotics den ersten Platz in einem Marathonlauf in Peking in 2 Stunden und 40 Minuten. Nun hat der Roboter einen ersten „Vertrag“ erhalten: Er arbeitet als Laufschuhtester. Das berichtet China Daily am Montag. Was sich zunächst wie ein Werbegag anhört, hat allerdings einen ernsten wirtschaftlichen Hintergrund. Die Entwicklung von Laufschuhen könnte dadurch deutlich verbessert und beschleunigt werden.

Der humanoide Roboter Tien Kung ist 1,7 m groß und wurde zusammen mit dem Beijing Humanoid Robot Innovation Center entwickelt. Der Roboter besitzt insgesamt 20 Freiheitsgrade und ist dank seiner verkörperten Intelligenz in der Lage, menschenähnlich zu laufen. Dabei kann er Geschwindigkeiten von bis zu 12 km/h erreichen, Treppen steigen, Anhöhen erklimmen und auch auf Sand, Schotter und Schnee laufen.

Bessere Daten in kürzerer Zeit

Die ersten Laufschuh-Tests hat der Roboter im Li-Ning Sports Science Research Center durchgeführt. Dadurch, dass es sich um einen lebensgroßen Roboter handelt, der menschenähnlich laufen kann, ist der Roboter für solche Tests geeignet. Die Ergebnisse können auf Laufschuhe für Menschen übertragen werden. Zunächst wurde der mit Laufschuhen ausgestattete Roboter auf ein 3D-Kraftlaufband und eine 200 m lange Hallenbahn geschickt. Dabei wurden die Dämpfung, der Rückprall und weitere Leistungsindikatoren der Laufschuhe erfasst. Normalerweise werden dafür Sportler eingesetzt, die mehrere Wochen diese Daten erheben.

Die notwendigen Daten erfasst der Roboter während des Laufens über Sensoren, die in den Hüft-, Knie- und Knöchelgelenken des Roboters eingebettet sind. Darüber erfassen die Tester detaillierte biomechanische Informationen. Yang Fan, Direktor des Li-Ning-Forschungszentrums, sagt, dass solche Daten bei menschlichen Athleten nahezu unmöglich zu erfassen sind.

Der Einsatz humanoider Roboter für Laufschuh-Tests hat aber noch einen weiteren Vorteil: Roboter sind in der Lage, Testabläufe immer wieder gleich zu wiederholen, ohne dabei Ermüdungserscheinungen zu bekommen. Menschliche Athleten müssen dagegen, um einen vergleichbaren Datensatz zu erhalten, über mehrere Wochen hinweg mehrere Testläufe absolvieren. Der Einsatz des Tien-Kung-Roboters liefere dagegen schon nach wenigen Einsatzstunden gleichmäßige, nachvollziehbare und damit verwertbare Ergebnisse.

Die Tests zeigen bereits jetzt, dass der Einsatz des humanoiden Roboters für bessere und schneller vorliegende Testdaten sorgt, die in die Produktentwicklung einfließen können. Das beschleunigt den Zyklus des Produktdesigns und senkt die Kosten. Zudem erhalten die Entwickler ein genaueres Bild der Leistungsfähigkeit der Laufschuhe in der Praxis.

Die Tester des Forschungszentrums wollen die Tests nun weiter verfeinern. Sie planen den Aufbau einer Laufschuh-Datenbank, in der Werte zu Dämpfung, Rückfederung und weiteren Leistungsmerkmalen erfasst sind. Die Datenbank soll dann für Forschung und Materialentwicklung sowie für die gezielte Produktentwicklung von Laufschuhen eingesetzt werden.

(olb)