Microsoft macht die Xbox-App zur zentralen Anlaufstelle für alle installierten PC-Spiele. Aktuell verteilt Microsoft ein Update für die Xbox-App, nach dessen Installation auch Spiele in der Xbox-Bibliothek auftauchen, die über andere Plattformen installiert wurden. Zu den unterstützten Stores gehören Steam, GOG und der Epic Games Store.

Angekündigt hat Microsoft diese Neuerung schon im Juni, seitdem wurden die neuen Features getestet. Nun wurde die überarbeitete Xbox-App für alle Nutzer veröffentlicht. Das Update kann auch in Deutschland bereits heruntergeladen werden. Dazu klickt man in der Xbox-App auf die Glocke und stößt den Download der neuen Version an – insofern sie nicht schon automatisch heruntergeladen wurde.

Nach dem Update braucht die App einen kurzen Moment, um alle auf dem PC installierten Spiele aus den unterschiedlichen Stores zu erfassen. Dieser Schritt erfolgt automatisch. Die zuletzt gespielten Titel tauchen in der linken Leiste auf, eine Komplettübersicht bekommt man über den Bibliotheks-Reiter.

Aktuell nicht installierte Spiele, die in anderen Stores erworben wurden, können über die Xbox-App nicht verwaltet werden. Die Integration installierter Spiele beschränkt sich vorrangig auf das Starten der Titel – für alles andere muss man in die App der jeweiligen Plattform wechseln.

Entwickelt für Xbox Ally

Standardmäßig indiziert die Xbox-App Spiele aus allen unterstützten Apps. Wer einzelne Apps abschalten oder das Feature komplett deaktivieren möchte, muss aktiv werden: Über den Klick auf den Benutzernamen und „Einstellungen“ kann man zu „Bibliothek und Erweiterungen“ navigieren. Dort kann man die Einbindung für jede einzelne Plattform aktivieren oder deaktivieren.

Das Feature wurde vorrangig für den Xbox Ally entwickelt: Nutzer des kommenden Handhelds von Asus und Microsoft bekommen eine neue, um die Xbox-App aufgebaute Oberfläche, die viele fürs Gaming weniger wichtige Funktionen in den Hintergrund rückt. Damit Handheld-User nicht ständig zwischen verschiedenen Apps hin- und herwechseln müssen, hat Microsoft an einer Einbindung der Spiele aus anderen Stores gearbeitet. Davon profitieren nun auch alle anderen PC-Systeme.

(dahe)

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.