Bis hierher hat die Kladde zwei Gesichter: die Webanwendung aus K2 mit Razor-Komponenten und die App aus den Lektionen davor mit XAML-Seiten. Beide zeigen Termine, beide kennen die Buchung, aber ihre Oberflächen haben nichts gemeinsam. Wer die Buchungsansicht ändert, ändert sie zweimal. Diese Lektion zeigt, wie eine Razor-Komponente in beiden Welten läuft: im Browser und in der App.
Als Ausgangsbild nehmen wir an, dass Ihre Lösung so aussieht. Passen Sie die Namen an Ihre Projekte und Seiten an:
| Projekt | Inhalt |
|---|---|
Kladde.Core |
die Regeln, auch FreeSlots |
Kladde.Web |
die Webanwendung mit der API GET /api/slots und POST /api/bookings aus K2 |
Kladde.Web.Client |
die WebAssembly-Insel mit SlotPicker, ISlotSource und HttpSlotSource aus Lektion 2.5.10 |
Kladde.App.Logic |
die ViewModels mit CommunityToolkit.Mvvm und ihre Schnittstellen, ohne MAUI, mit Kladde.App.Logic.Tests |
Kladde.App |
die MAUI-App: Shell, XAML-Seiten für Kontakte und Termine, SQLite, ein HttpClient für die API |
Am Ende der Lektion gibt es ein neues Projekt Kladde.Shared. Es enthält die Buchungsansicht als Razor-Komponente, und sowohl
Kladde.Web als auch Kladde.App zeigen dieselbe Komponente.
Was Blazor Hybrid ist
Microsoft beschreibt Blazor Hybrid so: Die Razor-Komponenten laufen nativ auf dem Gerät, im .NET-Prozess der App, und rendern in ein
eingebettetes WebView-Steuerelement. Sie laufen nicht im Browser, und WebAssembly ist nicht beteiligt. Das Steuerelement heißt in .NET MAUI
BlazorWebView. Weil der Code nativ läuft, haben die Komponenten Zugriff auf die Fähigkeiten des Geräts über die .NET-Plattform.
Ein WebView ist ein Stück Browser in der App. Welcher, hängt von der Plattform ab:
| Plattform | WebView | Quelle der Engine |
|---|---|---|
| Windows | WebView2 | Microsoft Edge (Chromium) |
| Android | android.webkit.WebView |
Chromium, die Version hängt vom installierten Android-WebView ab |
| iOS und Mac Catalyst | WKWebView |
Safari WebKit |
Daraus folgt, was Microsoft ausdrücklich nennt: Das Aussehen der Komponenten kann sich zwischen den Plattformen unterscheiden, und man muss es auf jeder testen. Auf Windows brauchen die Menschen, die Ihre App benutzen, außerdem die WebView2-Runtime.
Die drei Orte, an denen Razor-Komponenten laufen können, unterscheiden sich in dem, was sie dürfen. Die Dokumentation zu wiederverwendbaren Komponenten nennt je ein Beispiel:
| Ort | Was dort geht |
|---|---|
| Blazor WebAssembly | synchrone JavaScript-Aufrufe |
| Blazor Server | Dienste, die es nur auf dem Server gibt, etwa ein Entity-Framework-Kontext |
BlazorWebView |
direkter Zugriff auf Gerätefunktionen, etwa Standortdienste |
Ihre gemeinsamen Komponenten dürfen nichts davon voraussetzen. Wie sie trotzdem Unterschiede nutzen, steht weiter unten.
Wann Hybrid, wann XAML
Beides läuft in derselben App, man kann es mischen. Die Entscheidung trifft man pro Bildschirm. Die folgende Tabelle ist eine Abwägung, keine Regel von Microsoft:
| Frage | spricht für BlazorWebView |
spricht für XAML |
|---|---|---|
| Gibt es die Oberfläche schon als Razor-Komponente im Web? | ja: dieselbe Komponente wiederverwenden | nein |
| Soll sie sich wie ein natives Steuerelement anfühlen (Systemauswahl, Gesten)? | nein | ja |
| Ist der Bildschirm im Kern ein Formular oder eine Liste, die es im Web genauso gibt? | ja | selten nötig |
| Muss das Aussehen auf allen Plattformen exakt gleich sein? | eher ja, mit Test auf jeder Plattform | die Steuerelemente passen sich der Plattform an |
| Braucht der Bildschirm viel Gerätefunktion (Kamera, Sensoren)? | geht über Schnittstellen, mehr Aufwand | liegt näher |
Für die Kladde fällt die Wahl so: Kontakte und Termine des Tages bleiben XAML, denn sie nutzen die Datenbank des Geräts und fühlen sich als App an. Die Buchungsansicht gibt es im Web bereits, und sie ist ein Formular. Sie wird die Hybrid-Seite.