Connect with us

Entwicklung & Code

Cross-Plattform-Applikationen mit Rust 2: Crux im Einsatz


close notice

This article is also available in
English.

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

.




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

Entwicklung & Code

USA verbieten alle neuen Router für Verbraucher


Die USA lassen ab sofort keine neuen Router für den Verbrauchermarkt zu, sofern sie nicht in den USA hergestellt sind. Damit hat die Regulierungsbehörde FCC am Montag (Ortszeit) den Markt schockiert. Gemeint ist nicht nur der Zusammenbau; vielmehr muss die gesamte Herstellungskette, vom Design über Chips bis zur Software, ausschließlich in den USA liegen und von Firmen mit US-Eigentümern und -Management gestellt werden. Dies betrifft sowohl Router mit als auch ohne Funk.

Weiterlesen nach der Anzeige

Als Grund für das umfassende Verbot wird Nationale Sicherheit genannt. Das Problem: Wir haben noch keine Routermodelle für Verbraucher gefunden, die in Stückzahlen komplett in den USA hergestellt werden.

Bereits zugelassene Modelle dürfen weiter genutzt und verkauft werden. Allerdings führt das Verbot, in Verbindung mit einer Regeländerung vom Dezember, dazu, dass auch Updates von Firmware oder Software für bereits zugelassene Modelle ab sofort unzulässig wären. Eine Ausnahmegenehmigung erlaubt bestimmte Softwareupdates noch bis 1. März 2027.

Die Ausnahme gilt offenbar nicht für Updates, die neue Funktionen mit sich bringen. , aber Sicherheitslücken dürfen vorerst noch geschlossen und Kompatibilitätsprobleme mit Betriebssystemen noch gelöst werden. Ob diese Genehmigung für eingeschränkte Software- oder Firmwareupdates 2027 verlängert wird, bleibt abzuwarten.

Hohe Hürden für Ausnahmegenehmigungen

Ausnahmegenehmigungen sind möglich, aber mit so hohen Auflagen verbunden, dass sich das nur wenige Hersteller antun dürften.

Mehr in Kürze.


(ds)



Source link

Weiterlesen

Entwicklung & Code

WWDC 2026 am 8. Juni: Apple gewährt ersten Blick auf iOS 27 und macOS 27


Am Montag, 8. Juni, gewährt Apple einen ersten offiziellen Blick in die nächsten großen Versionen seiner Betriebssysteme. An diesem Tag findet der Auftakt zur Entwicklerkonferenz WWDC statt, wie das Unternehmen am Montag mitteilte. Traditionell beginnt die Konferenz mit einer Keynote und der anschließenden „Platforms State of the Union“, der speziellen Entwickler-Keynote. Erwartet werden unter anderem die Betriebssystem-Updates iOS 27, iPadOS 27 und macOS 27.

Weiterlesen nach der Anzeige

Bis zum 12. Juni können App-Entwickler dann online Details zum erwarteten neuen Framework Core AI erfahren, mit Designern und Entwicklern von Apple in Kontakt treten oder an Workshops teilnehmen. Dabei dürfte auch das bereits in Xcode integrierte agentische Coding für Entwickler eine wichtige Rolle spielen.

Der Termin war bereits – dem Rhythmus der Vorjahre folgend – erwartet worden. Über weitere Inhalte gibt Apple nur wenig preis. Das diesjährige Logo, ein grell leuchtender Kreis in Anspielung auf das kreisrunde Apple-Hauptquartier in Kalifornien, und der ebenfalls leuchtende Schriftzug WWDC26 lädt zu Spekulationen ein. Die Erfahrung lehrt aber, dass die Bildsprache so abstrakt ist, dass sich selbst rückblickend nicht zwangsläufig Rückschlüsse herstellen lassen.

Großer KI-Aufschlag erwartet

Als recht wahrscheinlich gilt, dass Apple nach der Erstvorstellung der Apple Intelligence im Jahr 2024 nach zwei Jahren umfassende neue KI-Funktionen auf Basis von Google Gemini plant. Apple selbst hat in der Medienmitteilung bereits erwähnt, dass es KI-Neuigkeiten geben wird. Angesichts der Kooperation mit Google und der Integration des LLM Gemini wird spätestens zur WWDC erwartet, dass die kontextsensitive Siri als echter Chatbot Gestalt annimmt. Sie sollte eigentlich schon in iOS 18 kommen. Außerdem soll laut Gerüchten ein Hauptaugenmerk in diesem Jahr auf Fehlerbehebungen und Optimierungen der Software liegen.

Wie in den Vorjahren haben ausgewählte Entwickler und Studenten die Möglichkeit, am 8. Juni persönlich bei einer Sonderveranstaltung im Apple Park dabei zu sein – die Teilnehmerzahl ist begrenzt. Die Bewerbungsfrist für das Losverfahren läuft bis zum 30. März, die Benachrichtigung der ausgewählten Teilnehmer soll am 2. April erfolgen.

50 Swift-Challenge-Gewinner erhalten Einladung

Weiterlesen nach der Anzeige

Neben den Inhalten richtet Apple auch den Blick auf seinen Entwickler-Nachwuchs: Am 27. März werden die Teilnehmer der diesjährigen Swift Student Challenge über ihren Status informiert. Die Gewinner können sich für einen Platz bei der Vor-Ort-Veranstaltung im Apple Park bewerben. 50 besonders ausgezeichnete „Distinguished Winners“ werden zudem zu einem dreitägigen Aufenthalt in Cupertino eingeladen.

Die Konferenz ist über die Apple Developer App, die Webseite und den Apple-YouTube-Kanal zugänglich.

Lesen Sie auch


(mki)



Source link

Weiterlesen

Entwicklung & Code

Jetzt auch für Windows: Terminal-Multiplexer Zellij 0.44.0 erschienen


Der in Rust geschriebene Terminal-Workspace Zellij ist in Version 0.44.0 erschienen. Das Release bringt unter anderem nativen Windows-Support, die Anbindung via HTTPS an entfernte Sessions sowie umfangreiche Erweiterungen der Kommandozeilensteuerung für die Automatisierung.

Weiterlesen nach der Anzeige

Wie die Entwickler im offiziellen Blog mitteilen, läuft Zellij nun nativ unter Windows. Der Funktionsumfang entspricht dem der Linux- und macOS-Versionen. Bislang war der Einsatz unter Windows nur über das Windows Subsystem for Linux (WSL) möglich.

Remote-Sessions über HTTPS

Aufbauend auf dem in Version 0.43.0 eingeführten Webserver können Nutzer sich nun direkt aus dem Terminal heraus per HTTPS an eine entfernte Zellij-Session anbinden – ganz ohne Browser. Der Befehl zellij attach genügt dafür. Die Verbindung nutzt den eingebauten Webclient, der sich wie ein Browser gegenüber dem Zellij-Web-Server authentifiziert.

Ergänzend dazu gibt es neuerdings einen Read-Only-Modus für das Session-Sharing. Über zellij watch oder im Browser mit einem speziellen Read-Only-Token können Dritte eine Session ausschließlich lesend verfolgen. Solche Tokens lassen sich per zellij web --create-read-only-token oder über das Share-Plug-in (Strg+O, S) erzeugen. Dieses Feature eignet sich besonders für Lehrveranstaltungen, Demonstrationen, Screencasting oder das Streaming, bei denen Zuschauer den Terminalinhalt beobachten, aber nicht eingreifen sollen.

CLI-Automatisierung deutlich ausgebaut

Zellij 0.44.0 hat die Kommandozeilensteuerung erheblich erweitert. Der Befehl zellij run unterstützt im aktuellen Release Flags wie --blocking, --block-until-exit-success und --block-until-exit-failure, mit denen sich Kommandos konditionell verketten lassen. So lässt sich etwa eine Sequenz aus Tests und anschließendem Release-Build abbilden: zellij run --block-until-exit-success -- cargo test && zellij run --blocking -- cargo build --release.

Neue CLI-Aktionen wie zellij action list-panes liefern detaillierte Informationen zu geöffneten Panes mitsamt IDs, Titeln, ausgeführten Befehlen und Koordinaten. Mit zellij action send-keys lassen sich Tasteneingaben an bestimmte Panes senden, zellij action dump-screen gibt den aktuellen Viewport oder den Scrollback-Buffer aus. Über zellij subscribe können externe Tools Echtzeit-Updates aus der Session abonnieren. Hinzu kommen verbesserte Befehle für detach und switch-session sowie die Möglichkeit, Floating Panes atomar ein- und auszublenden. Pane- und Tab-IDs werden nun als Rückgabewerte geliefert, was die Skript-Integration erleichtert.

Weiterlesen nach der Anzeige

Neuer Layout-Manager und Bedienverbesserungen

Der überarbeitete Layout-Manager lässt sich über Strg+O, L aufrufen. Nutzer können Layouts in neuen Tabs öffnen, auf den aktuellen Tab anwenden oder den Zustand eines Tabs als neues Layout aufzeichnen. Der ebenfalls neu gestaltete Session-Manager fasst das Erstellen neuer Sessions, das Anhängen an bestehende und das Wiederherstellen beendeter Sessions in einer einzigen Ansicht mit Fuzzy Finding zusammen.

Darüber hinaus lassen sich Pane-Grenzen neuerdings mit der Maus oder per Strg+Scrollrad verschieben. Dateipfade in Compiler-Ausgaben oder Logdateien erkennt Zellij automatisch und öffnet sie per Klick.

Für Plug-in-Entwickler stellt Version 0.44.0 neue Rust-APIs bereit. Sie ermöglichen unter anderem den Zugriff auf Scrollback-Inhalte anderer Panes, das Hervorheben von Text im Viewport, das Setzen von Pane-Farben sowie das Auslesen von Umgebungsvariablen und das Auslösen von Session-Saves. Da neue UI-Funktionen in Zellij grundsätzlich als Erweiterungen umgesetzt werden, stehen diese APIs auch externen Plug-ins zur Verfügung.

Siehe auch:


(fo)



Source link

Weiterlesen

Beliebt