Die Sonnenaktivität ist seit 17 Jahren kontinuierlich gestiegen, sollte dieser Trend anhalten, könnten Sonnenstürme und Sonneneruptionen unabhängig vom jeweiligen Sonnenzyklus häufiger werden. Das haben zwei Forscher der NASA ermittelt, die verschiedene Entwicklungen beim Verhalten unserer Sonne ausgewertet haben. Demnach hat ein in den 1980er-Jahren begonnener Trend der abnehmenden Sonnenaktivität 2008 geendet, aber das damals erwartete Verharren auf diesem niedrigen Niveau sei nicht eingetreten. Stattdessen habe die Sonne den Kurs gewechselt und sei immer aktiver geworden. Das könnte künftig nicht nur Folgen für die Raumfahrt haben.

Dass die Sonne bei ihrer Aktivität einen ungefähr elfjährigen Zyklus durchläuft, ist seit mehr als 200 Jahren bekannt. Die wurden von dem Schweizer Astronomen Rudolf Wolf im 18. Jahrhundert bis zum Jahr 1749 zurückgerechnet, dem Maximum des sogenannten 0. Zyklus. Inzwischen wurde der Elfjahreszyklus anhand von Baumringen sogar lückenlos für die vergangenen 1000 Jahre bestätigt und bis ins Jahr 969 zurückverfolgt. Gleichzeitig durchläuft die Sonne aber langfristigere Veränderungen, die dafür sorgen, dass die Aktivität unabhängig von den Zyklen zu- oder abnimmt. Am inaktivsten war die Sonne beispielsweise aus bislang ungeklärten Gründen im 17. Jahrhundert und dann noch einmal am Anfang des 19. Jahrhunderts. Am Beginn des Raumfahrtzeitalters war sie dann so aktiv wie lange nicht mehr.

Sonnenaktivität mit konkreten Folgen auf der Erde

Dass der aktuelle 25. Sonnenzyklus stärker ausgefallen ist als erwartet, war bereits bekannt. Auch sein Maximum hat er früher erreicht. Die beiden NASA-Forscher haben nun aber bestätigt, dass das Teil eines größeren Trends ist: „Die Sonne wacht langsam auf“, meint Studienleiter Jamie Jasinski vom Jet Propulsion Laboratory der NASA. Insgesamt sei das eine Überraschung gewesen, denn eigentlich habe alles darauf hingedeutet, dass die Sonne in eine längere Phase geringer Aktivität eingetreten ist. Dass dem nicht so ist, hat er mit Marco Velli unter anderem anhand von Daten zum Sonnenwind und zum Magnetfeld ermittelt. Ihre Forschungsarbeit haben sie in den Astrophysical Journal Letters veröffentlicht.

Die kontinuierliche Beobachtung und Vorhersage der Sonnenaktivität sind nicht nur für die Erforschung unserer Sonne von Belang, Phasen besonders hoher Aktivität können ganz konkrete Folgen auf der Erde haben. Schlimmstenfalls kann eine besonders aktive Sonne – also eine mit vielen Sonnenflecken und großen Ausbrüchen auf der Oberfläche – technische Systeme wie etwa Satelliten beschädigen oder gar zur Gefahr für Astronauten werden. Eine besonders starke Sonneneruption könnte sogar eine „Internet-Apokalypse“ auslösen. Zudem hat erst vor wenigen Monaten ein Forschungsteam herausgefunden, dass sogenannte Superflares unserer Sonne viel häufiger sind als angenommen. Dabei handelt es sich um gigantische Eruptionen auf der Sonne mit potenziell verheerenden Folgen für moderne Infrastruktur.

(mho)

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