Connect with us

Künstliche Intelligenz

Cross-Plattform-Applikationen mit Rust 2: Crux-Architektur in der Praxis


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.


Portrait Marcel Koch

Portrait Marcel Koch

Marcel Koch berät mit seinem siebenköpfigen Team kleine und mittelständische Unternehmen und entwickelt branchenübergreifend Cross-Platform-Apps für Desktop und Mobile sowie Webapplikationen – bevorzugt mit TypeScript, Rust, Flutter oder Java, gestützt auf CI/CD und IaC. Dabei setzt er auf pragmatische, passgenaue Lösungen, denn Software ist kein Selbstzweck. Neben soliden technischen Kenntnissen schult er in Gewaltfreier Kommunikation, Transaktionsanalyse sowie Agilität und fördert einen kritischen Blick auf Cloud Hypes. Marcel ist Speaker, Autor von Fachartikeln und Büchern und regelmäßig in Podcasts zu hören.

Die Programmiersprache Rust eignet sich gut für die Umsetzung von Cross-Plattformprojekten. Der erste Teil der Artikelserie hat die grundlegenden Konzepte einer langlebigen Cross-Plattform-Architektur vorgestellt: Ein herausgelöster Core in Rust bildet das Fundament für nachhaltige Apps. Die Implementierung eines einfachen MVVM-Patterns mit ViewModel, Actions und State zeigte eine einfache konkrete Umsetzung dieses Ansatzes. Wie sich die Architektur verfeinern lässt, zeigt sich, wenn man sie um Validierungen erweitert.

Weiterlesen nach der Anzeige

Cross-Plattform mit Crux

Das in Rust geschriebene Framework Crux für die plattformübergreifende Entwicklung implementiert die im ersten Artikelteil vorgestellten Konzepte. Was Aktion hieß, nennt Crux Event. Der Zustand(State) heißt Model. Durch den ähnlichen Namen ist die Grenze zum ViewModel leider nicht mehr ganz so deutlich. Das ViewModel heißt nämlich auch bei Crux ViewModel. Umso wichtiger ist es, die Abgrenzung bei der Umsetzung im Hinterkopf zu behalten.

Zudem bringt Crux mit Effect und Command noch weitere wichtige Konzepte mit.

Ein Effect bildet einen Seiteneffekt der hexagonalen Architektur ab. In diesem Kontext sind Seiteneffekte gleichbedeutend mit Plattformspezifika und dem Rendern des User Interface (UI). Dabei ist ein Effect keine Einbahnstraße. Durch ein Command lässt es sich mit einem Event verknüpfen, sodass der verarbeitete Effekt beantwortet und die Antwort in der App auf ein weiteres Event angewendet werden kann. Auf diese Art lässt sich der Zugriff auf das jeweilige Dateisystem und auf native APIs abstrahieren und umsetzen.

Crux definiert außerdem die Begriffe App, Core und Shell.

Weiterlesen nach der Anzeige

  • Die App ist das zentrale Trait und ein Pendant zum Core aus Teil 1
  • Core umhüllt die App und sorgt dafür, dass ein Event in die App hinein- und nur eine Liste von Effect oder das ViewModel aus der App hinausgeht
  • Shell bezeichnetet den Konsumenten des Cores (bepackt mit der App), wie eine native App auf Basis von Swift, Kotlin oder C#



Die Architektur von Crux unterscheidet App, Core und Shell und Effekte (Abb. 1)

(Bild: Marcel Koch)

Beispiel: E-Mail-App

Das zuvor in Teil 1 implementierte Beispiel wird erneut aufgegriffen und auf Crux übertragen. Als Erstes die einfachen Typen (Listing 1):

Listing 1: Crux: Event/Model/ViewModel-Definitionen


#[derive(Deserialize, Serialize)]
pub enum Event {
    ChangeName(String),
    ChangeEmail(String),
    ApplyChanges,
}

#[derive(Default)]
pub struct Model {
    name: String,
    email: String,
}

#[derive(Deserialize, Serialize)]
pub struct ViewModel {
    pub name: String,
    pub email: String,
}


Hierbei gibt es keine Überraschungen. Actions werden zu Event (Einzahl), State wird zu Model und das ViewModel bleibt bestehen.

Als Nächstes die neuen Typen (Listing 2):

Listing 2: Crux: Effect-Enum und App-Struct


#[effect]
pub enum Effect {
    Render(RenderOperation),
}

#[derive(Default)]
pub struct EmailApp;


Das Enum Effect definiert alle möglichen Kommunikationen aus dem Core hinaus. Das Struct EmailApp bleibt leer. Es implementiert im nächsten Schritt das Trait App von Crux.

Die Implementierung von App ist in drei Blöcke (siehe Kommentare in Listing 3) unterteilt.

Listing 3: Crux: App-Trait-Implementierung


impl App for EmailApp {
    // 1
    type Event = Event;
    type Model = Model;
    type ViewModel = ViewModel;
    type Capabilities = (); // deprecated
    type Effect = Effect;

    // 2
    fn update(
        &self,
        event: Self::Event,
        model: &mut Self::Model,
        _caps: &Self::Capabilities,
    ) -> Command<:effect self::event=""> {
        match event {
            Event::ChangeEmail(email) => {
                model.email = email.clone();
            }
            Event::ChangeName(name) => {
                model.name = name.clone();
            }
            Event::ApplyChanges => {}
        }
        render()
    }

    // 3
    fn view(&self, model: &Self::Model) -> Self::ViewModel {
        ViewModel {
            name: model.name.clone(),
            email: model.email.clone(),
        }
    }
}


Der erste Block legt die grundlegenden assoziierten Typen fest, die App vorsieht. Diese Typen sind aus Listing 1 und 2 bekannt. Der Typ Capabilities ist ein Relikt und gilt als veraltet (deprecated). Dieses Konzept wurde vor der Einführung von Command genutzt. Daher ist es lediglich aus Gründen der Rückwärtskompatibilität vorhanden und lässt sich ignorieren.

Die update-Methode nimmt eingehende Events entgegen und passt daraufhin den Zustand (Model) an. Änderungen am Namen oder der E-Mail-Adresse werden auch hier direkt im Model gespeichert. Nach der Verarbeitung eines Events wird ein Render– Effect ausgelöst. Dieser kann in der Shell aufgegriffen, das ViewModel angefragt und das Re-Rendering angestoßen werden.

Die view-Methode in Abschnitt 3 bietet die Schnittstelle, um das ViewModel zu erstellen. Wie zuvor erzeugt das ViewModel das aktuelle Model (Zustand) und bereitet die relevanten Informationen für die UI so auf, dass die Benutzeroberfläche sie direkt anzeigen kann.

App im Core einwickeln

Um die App zu verwenden, gilt es diese im Core zu umhüllen (zu wrappen):

let core: Arc> = Arc::new(Core::new());

Dieser Core-Instanz lässt sich ein Event übergeben und die zurückkommenden Effekte können verarbeitet werden (Listing 4).

Listing 4: Crux: Effect-Verarbeitung


let effects: Vec =
    core.process_event(ChangeEmail("marcel.koch@example.org".into()));

for effect in effects {
  match effect {
    Effect::Render(_) => {
      let view_model = core.view();
      
      assert_eq!(view_model.email, "marcel.koch@example.org")
    }
  }
}


process_event nimmt das Event entgegen und gibt eine Liste von Effekten zurück. Das Beispiel behandelt nur eine Art von Effect: Render. Es wird geprüft, ob das ViewModel die eben übergebene E-Mail-Adresse enthält.

Ist das UI verbunden, tritt es bei jeder Änderung der E-Mail-Adresse auf.

Core in Bridge wrappen

Geht es nicht um einen reinen Aufruf innerhalb von Rust, ist die Integration in andere Technologien abhängig von Serialisierung. Diese Aufgabe übernimmt auf der Rust-Seite die Bridge. Ein einfacher Einsatz sähe in Rust wie folgt aus:

Listing 5: Crux: Bridge-Integration


let serialized = 
    bincode::serialize(&ChangeEmail("marcel.koch@example.org".into())).unwrap();

let effects: Vec = bridge.process_event(&serialized).unwrap();

let effects: Vec> =
bincode::deserialize(effects.as_slice()).unwrap();

for request in effects {
  let effect = request.effect;
  
  match effect {
    EffectFfi::Render(_) => {
    let view_model = bridge.view().unwrap();
    let view_model: ViewModel =
    bincode::deserialize(&view_model).unwrap();
    
    assert_eq!(view_model.email, "marcel.koch@example.org")
    }
  }
}


Es ist der gleiche Ablauf wie zuvor mit dem reinen Core. Die einzigen Unterschiede sind die Serialisierung des Events und die Deserialisierung der Effekte und des ViewModel. Diese Serialisierungen werden in einem realistischen Einsatz in den jeweiligen Fremdtechnologien (.NET, Swift etc.) durchgeführt. Diese Umsetzung zeigt der nächste Teil dieser Artikelserie.



Source link

Verwandte Themen:
Weiterlesen

Künstliche Intelligenz

iX-Workshop: Mastering Azure – Administration der Azure Cloud Services


Microsoft Azure ist eine Cloud-Plattform, die Unternehmen eine skalierbare Infrastruktur, sichere Datenspeicherung und vielseitige Analyse-, virtuelle Verarbeitungs- und Netzwerkdienste bietet. Sie ermöglicht die schnelle Entwicklung, Bereitstellung und Verwaltung von Anwendungen ohne eigene IT-Infrastruktur.

Weiterlesen nach der Anzeige

Im viertägigen Intensiv-Workshop Mastering Azure: Administration und Konfiguration der Microsoft Cloud lernen Sie die Komponenten der Microsoft Azure Cloud kennen und anwenden.

Jede Menge Praxis und Übungen

Unter der Anleitung von Cloud-Experte Mustafa Radha Jassim lernen Sie die wichtigsten IaaS- und PaaS-Dienste von Azure sowie die Azure Security Services kennen. Sie erfahren, wie Sie Azure effektiv mit verschiedenen Tools wie der grafischen Benutzeroberfläche (GUI), der Kommandozeilenschnittstelle (CLI) und Automatisierungstools administrieren, Anwendungen mit virtuellen Maschinen, Containern und anderen PaaS-Diensten in der Cloud bereitstellen, Azure-Speicherlösungen und Dateifreigaben verwalten und die Monitoring-Funktionen von Azure nutzen. Dabei liegt der Schwerpunkt auf praktischen Übungen, für die jedem Teilnehmer eine eigene Laborumgebung mit einem Azure-Abonnement zur Verfügung steht.

April
20.04. – 22.04.2026 		Online-Workshop, 09:00 – 17:00 Uhr
10 % Frühbucher-Rabatt bis zum 23. Mrz. 2026
November
09.11. – 11.11.2026 		Online-Workshop, 09:00 – 17:00 Uhr
10 % Frühbucher-Rabatt bis zum 12. Okt. 2026

Der Workshop richtet sich an Administratoren, Cloud-Architekten und DevOps-Ingenieure, die ihre Fähigkeiten in der Administration und Konfiguration von Azure erweitern möchten. Referent Mustafa Radha Jassim arbeitet als IT-Consultant bei der Söldner Consult GmbH mit den Schwerpunkten Cloud Computing, Cybersecurity, Virtualisierung und End-User Computing, insbesondere die Azure Cloud-Lösungen von Microsoft, VMware vSphere, Workspace ONE und Carbon Black.


Upgrade für Ihre IT-Skills - Von Experte zu Experte

Upgrade für Ihre IT-Skills - Von Experte zu Experte


(ilk)



Source link

Weiterlesen

Künstliche Intelligenz

„Weiße SIM-Karten“: Ausnahme von Irans Internetsperre für Regimetreue bestätigt


Mehr als 11 Tage nach Beginn der jüngsten kompletten Internetsperrung im Iran gibt es eine offizielle Bestätigung, dass bestimmte Individuen und Organisationen davon nicht betroffen sind. Die kommt von Fatemeh Mohajerani, der Sprecherin der Islamischen Republik. Sie hat erklärt, dass „Maßnahmen ergriffen wurden, damit solche Ausstattung nur denjenigen zur Verfügung steht, die unsere Stimme an andere weitergeben können“, zitiert IranWire. Auch wenn sie dabei nicht konkreter geworden ist, bezieht sie sich wohl auf spezielle SIM-Karten, über die man weiter online gehen kann und die gezielt für Propagandazwecke verteilt werden. Irans Präsident hatte erst im Dezember versprochen, diese „weißen SIM-Karten“ deaktivieren zu lassen, damit alle die „Schwärze“ gleichermaßen erleben müssen, wie Iran International berichtete.

Weiterlesen nach der Anzeige

Die Sonderregelung für eine kleine Minderheit von regimetreuen Organisationen und Personen zeigt sich laut Netblocks auch in den Daten zum Internetverkehr. Die Organisation weist regelmäßig auf die anhaltende Internetblockade hin und schreibt, dass die Konnektivität der Islamischen Republik auf ein Prozent des normalen Niveaus gefallen ist. Dieser kleine Rest entfällt demnach etwa auf Staatsmedien, die die Sichtweise der Islamischen Republik verbreiten sollen. Irans Präsident Massud Peseschkian hat dieses bereits erprobte Vorgehen immer wieder kritisiert, aber im Dezember erklärt, dass er dagegen nicht vorgehen könne. Deshalb wollte er die weißen SIM-Karten sperren lassen, aber auch das ist ihm offensichtlich nicht gelungen. Im Iran liegt die eigentliche Macht beim sogenannten Obersten Führer.

Kontakt zum Rest der Welt abgeschnitten

Die aktuelle Internetblockade wurde am 28. Februar verhängt, als Israel und die USA begannen, Luftangriffe auf den Iran zu fliegen. Dabei wurde unter anderem Ali Chamenei getötet, als neuer Oberster Führer wurde inzwischen sein Sohn installiert. Der Iran hat zudem begonnen, verschiedene Nachbarstaaten anzugreifen. Getroffen wurden dabei unter anderem auch zwei Rechenzentren der Amazon-Tochter AWS. Mit der Internetsperrung will das Regime unter anderem Proteste im Keim ersticken. Die vorherige Internetsperre war nach den mutmaßlich größten Demonstrationen in der Geschichte der Islamischen Republik Anfang des Jahres verhängt worden. Als die Kommunikation mit dem Rest unterbrochen war, wurden sie blutig niedergeschlagen.

Der übergroßen Mehrheit der Menschen im Iran steht derzeit nur ein strikt reglementiertes nationales Internet offen, in dem es unmöglich ist, sich unabhängig zu informieren. Dessen Entwicklung wurde seit Jahren vorangetrieben, es firmiert unter den Namen „Internet-e Halal“, also islamisches Netz, oder „Internet-e Melli“ – wörtlich übersetzt Volksinternet. Gegenwärtig gibt es zudem Berichte, dass die Regierung massenhaft SMS verschickt, in denen Menschen davor gewarnt werden, zu protestieren. Ahmadreza Radan, der höchste Polizeichef im Land, hat laut der Deutschen Welle gedroht, dass Protestierende als Feinde behandelt würden: „Alle unsere Kräfte haben ihre Finger am Abzug.“


(mho)



Source link

Weiterlesen

Künstliche Intelligenz

KeePassXC 2.7.12: DLL-Schutz, Passkey-Änderungen und TOTP in Auto-Type


Der quelloffene Passwort-Manager KeePassXC ist in Version 2.7.12 erschienen. Das Release behebt mehrere Sicherheitsprobleme, allen voran einen Schutz gegen DLL-Injection-Angriffe unter Windows. Außerdem bringt es funktionale Erweiterungen, darunter TOTP-Unterstützung in Auto-Type und verschachtelte Ordner beim Bitwarden-Import.

Weiterlesen nach der Anzeige

Wie die Entwickler in ihrem Release-Blog mitteilen, enthält die neue Version Mitigationen gegen Exploits über manipulierte OpenSSL-Konfigurationsdateien auf Windows. Bei einer DLL-Injection schleusen Angreifer bösartige Dynamic Link Libraries in den Adressraum eines laufenden Prozesses ein, um beliebigen Code auszuführen oder Rechte zu erhöhen. KeePassXC 2.7.12 verhindert nun, dass OpenSSL-Konfigurationen als Angriffsvektor für solche Injektionen missbraucht werden.

Passkey-Flags ändern sich – Vorsicht beim Update

Eine potenziell aufwendige Änderung betrifft Passkeys: KeePassXC speichert jetzt die Flags Backup Eligibility (BE) und Backup State (BS) mit jedem Eintrag. Das BE-Flag zeigt an, ob ein Passkey als Multi-Device-Credential gesichert und synchronisiert werden kann, das BS-Flag markiert den aktuellen Sicherungsstatus. Bisher waren beide Werte fest auf false gesetzt, ab Version 2.7.12 stehen sie standardmäßig auf true. Die Entwickler warnen ausdrücklich: „Dies könnte bestehende Passkeys brechen, für die die Flags nicht gespeichert wurden, da die Werte als unveränderlich gelten.“

Wer nach dem Update Probleme mit bestehenden Passkeys feststellt, kann den vorherigen Zustand wiederherstellen, indem er unter „Advanced“ zwei String-Attribute manuell hinzufügt: KPEX_PASSKEY_FLAG_BE=0 und KPEX_PASSKEY_FLAG_BS=0. Zusätzlich wird nun der publicKey in die Register-Response für Passkeys aufgenommen.

TOTP-Platzhalter und verbesserter Browser-Dialog

KeePassXC 2.7.12 unterstützt jetzt {TIMEOTP} als Platzhalter in Auto-Type-Sequenzen und als Entry-Platzhalter. TOTP (Time-based One-Time Password) ist ein RFC 6238 spezifizierter Algorithmus, der aus einem gemeinsamen geheimen Schlüssel und der aktuellen Systemzeit zeitbasierte Einmalpasswörter generiert – typischerweise alle 30 Sekunden. Nutzer können damit automatisch den aktuellen TOTP-Code in Login-Formulare einfügen lassen, ohne ihn händisch aus einer Authenticator-App ablesen zu müssen.

Weiterlesen nach der Anzeige

Im Browser-Zugriffsdialog zeigt KeePassXC nun die abgeglichenen URLs in einem Tooltip an. So lässt sich leichter verifizieren, welche Websites tatsächlich Zugriff auf gespeicherte Zugangsdaten anfordern. Außerdem validiert die neue Version die Haupt-Entry-URL bei der Verwendung von Platzhaltern und speichert browserbezogene Werte korrekt in den customData-Feldern.

Bitwarden-Import mit verschachtelten Ordnern

Wer von Bitwarden zu KeePassXC migriert, kann mit der neuen Version auch verschachtelte Ordner übernehmen. Bitwarden nutzt einen Schrägstrich als Trennzeichen für hierarchische Ordnerstrukturen, etwa „Socials/Forums“. KeePassXC 2.7.12 bildet diese Hierarchie beim Import korrekt ab, sodass die Vault-Struktur erhalten bleibt.

Unter Linux haben die Entwickler eine Änderung rückgängig gemacht, die eine Race-Condition in der Auto-Type-Funktion verursachte. Darüber hinaus behebt das Release diverse kleinere Probleme: Die Anzeige des Kontrollkästchen-Werts in den Browser-Integrations-Einstellungen stimmt jetzt, Font- und Theme-Darstellung wurden korrigiert, der „Entfernen“-Button in den Plugin-Daten funktioniert wieder ordnungsgemäß, und Dateinamen werden vor dem Speichern von Anhängen bereinigt.

KeePassXC 2.7.12 steht für Windows, Linux und macOS auf der Projektseite zum Download bereit.


(fo)



Source link

Weiterlesen

Beliebt