UIs auf Kleinstgeräten
Avalonia kommt auf Linux auch ohne Desktop-Umgebung aus und rendert dabei ohne Umwege direkt auf den Bildschirm. Für UI-Entwicklung auf leistungsschwacher Hardware kann das ein spannender Weg sein.
Im Artikel „UIs für Linux“ wurde das Cross-Plattform-UI-Framework Avalonia bereits im Hinblick auf die Entwicklung für Desktop-Umgebungen unter Linux vorgestellt. Dieser Artikel rundet das dort Beschriebene mit einem Fokus auf Embedded Linux ab. Mit Embedded Linux sind in diesem Artikel Linux-Installationen gemeint, die ohne Desktop-Umgebung wie Gnome auskommen.
Avalonia rendert alle Controls selbst und ist damit weitgehend unabhängig von den nativen Controls der jeweiligen Plattform. Aus diesem Grund sehen Avalonia-Applikationen auf allen Plattformen wie Linux, Windows oder macOS gleich aus und verhalten sich auch gleich. Es gibt nur Weniges, was Avalonia als Abhängigkeit vom jeweiligen Betriebssystem braucht – zum Beispiel Fenster. Avalonia nutzt das Windowing-System der jeweiligen Plattform, um eben solche zu öffnen und dort reinrendern zu können. Ein anderes Beispiel ist der Empfang von Eingabe-Events von Maus, Tastatur oder Touch.
Mike James beschreibt genau das in seinem Blogartikel „Why adding new platforms is easy with Avalonia“. Für das Avalonia-Team ist es daher einfach, eine breite Liste von Plattformen zu unterstützen. Speziell für Embedded Linux ist dabei interessant, dass Avalonia auch direkt via Framebuffer oder DRM (Direct Rendering Manager) seine Arbeit verrichten kann. Diese beiden Schnittstellen werden normalerweise im Hintergrund genutzt, wenn wir eine Desktop-Umgebung wie Gnome, KDE Plasma oder Xfce nutzen. Avalonia kann diese Schnittstellen aber auch direkt ansprechen und kommt damit ohne Desktop-Umgebung aus. Technisch setzt Avalonia die Anbindung daran als eigene Plattform um.
Avalonia-Applikation für Embedded Linux fit machen
Jumar Macato vom Avalonia-Team beschreibt in einem Blogartikel, welche Schritte notwendig sind, um eine Avalonia-Applikation für Embedded Linux fit zu machen. Der wichtigste Baustein ist das NuGet-Paket Avalonia.LinuxFramebuffer. Obwohl der Name vielleicht anderes vermuten lässt, unterstützt das Paket nicht nur den Framebuffer, sondern auch den vorher angesprochenen DRM.
Im Unterschied zu Desktop-Umgebungen haben wir auf einem Embedded System kein echtes Windowing-System. Avalonia betrachtet eine Applikation auf einer solchen Plattform daher als SingleViewApplication. Für uns bedeutet das, dass wir kein Hauptfenster haben, sondern direkt mit einem UserControl starten. Typischerweise nennen wir dieses MainView. In Listing 1 sehen wir, wie die Instanz der MainView erzeugt und dem Application-Objekt zugewiesen wird.
Listing 1: Erstellen der MainView in App.axaml.cs
public override void OnFrameworkInitializationCompleted()
{
if (ApplicationLifetime is ISingleViewApplicationLifetime singleView)
{
singleView.MainView = new MainView();
}
base.OnFrameworkInitializationCompleted();
}
Die Schnittstelle ISingleViewApplicationLifetime ist dabei eine Abstraktion für solche Plattformen, bei denen wir keinen Zugriff auf ein Windowing-System haben. Andere Beispiele für eine solche Plattform sind mobile Plattformen (Android, iOS) und der Browser.
Im nächsten Schritt muss noch die Program.cs wie in Listing 2 angepasst werden, um die Applikation als Embedded Applikation zu starten.
Listing 2: Program.cs zum Starten einer Avalonia-Applikation mit Linux DRM
public static class Program
{
[STAThread]
public static void Main(string[] args)
{
using var consoleListener = EmbeddedConsoleUtil.SilenceConsole();
BuildAvaloniaApp()
.StartLinuxDrm(args: args, card: null, scaling: 1.0);
}
public static AppBuilder BuildAvaloniaApp()
=> AppBuilder.Configure()
.UsePlatformDetect()
.WithInterFont()
.LogToTrace();
}
Die Magie liegt in diesem Fall hinter dem Aufruf der Methode StartLinuxDrm – Avalonia erledigt hier im Hintergrund alle Einstellungen, um das Rendering in den DRM zu starten. Das Programm bricht mit einer Exception ab, falls dabei etwas fehlschlägt.
Obiger Aufruf von EmbeddedConsoleUtil.SilenceConsole ist optional, und es handelt sich dabei um kein API von Avalonia. Es ist eine eigene Methode, die den Cursor der Console ausgeblendet. Zusätzlich wird auf Eingaben wie die [ESC]-Taste oder [STRG]+ [C] gelauscht, um das Programm in diesen Fällen ordentlich zu beenden. Optional ist das deswegen, weil es im Produktivbetrieb so in der Regel nicht benötigt wird. Während der Entwicklung und des Testens ist es aber durchaus ein sinnvolles Hilfsmittel. Der vollständige Code dazu ist im Beispielcode zu diesem Artikel enthalten.
Entwickeln und Testen
Während der Entwicklung empfiehlt es sich, neben Embedded Linux auch den Desktop zu unterstützen. Am Desktop lässt sich die Applikation deutlich einfacher über die IDE debuggen. Technisch kann die Unterscheidung mittels eines Kommandozeilen-Parameters erreicht werden, oder alternativ mit zwei verschiedenen Kopf-Projekten. Im Beispielcode dieses Artikels ist es mit letzterer Variante umgesetzt.
Für den Test der Embedded-Variante der Applikation gibt es mehrere Möglichkeiten. Direkt auf dem Zielgerät ist zwar eine Option, die Analyse von Fehlern kann sich aber aufgrund eines kleinen Displays und fehlender Analyse-Tools schwierig gestalten. Eine weitere Alternative ist es, speziell dafür einen Test-Laptop oder eine VM aufzusetzen. Der Autor dieses Artikels macht es etwa so: Aktuelles Ubuntu-Linux auf einem Laptop mit Touch-Display, grafische Umgebung beenden (zum Beispiel mittels Kommandozeile sudo init 3), anschließend die zu testende Avalonia-Applikation im Embedded-Modus starten.
Einschränkungen
Beim Verzicht auf eine Desktop-Umgebung gibt es einige Einschränkungen, die man kennen sollte. Der wichtigste Punkt betrifft die Eingabegeräte. Avalonia unterstützt in diesem Modus nur Touch-Eingaben. Maus- und Tastatur-Unterstützung fehlen. Auf den ersten Blick kann das unverständlich wirken. Es ergibt allerdings Sinn, wenn man betrachtet, auf welchen Geräten Avalonia ohne Desktop-Umgebung genutzt wird. Typischerweise sind das kleine Displays ohne Tastatur, bei denen die Eingabe – wenn überhaupt – mittels Touch erfolgt.
Bezüglich Tastatur-Eingaben existiert speziell zum Testen der Applikation ein Workaround. Es ist weiterhin möglich, Eingaben über die Console entgegenzunehmen. Innerhalb der Avalonia-Applikation etwa für Texteingaben kann das nicht genutzt werden. Es ist aber möglich, eigene Funktionen hinter bestimmte Tasten zu legen. Ein gutes Beispiel wäre das Beenden der Applikation via [ESC]-Taste oder das Behandeln der Tastenkombination [STRG]+[C].
Abhängigkeiten am Gerät
Auf dem Zielgerät gibt es im Wesentlichen folgende Abhängigkeiten:
- Es muss .NET ausführen können
- Es benötigt einen DRM/Framebuffer fähigen Treiber
- Es muss Skia ausführen können (Skia ist die 2D-Rendering-Bibliothek, die Avalonia unter der Haube verwendet)
Je nach Linux-Distribution müssen weitere Zusatzpakete installiert werden. Auf Raspbian Lite sind das laut der Dokumentation von Avalonia libgbm1, libgl1-mesa-dri, libegl1-mesa und libinput10. Daneben geht es primär darum, dass genügend Arbeitsspeicher vorhanden ist, um die Applikation ausführen zu können.
Für weitere Informationen empfiehlt es sich hier, direkt auf das Avalonia-Team zuzugehen. Dieses bietet im Rahmen des kostenpflichten Supports Unterstützung für den Betrieb auf Linux-Distributionen an, die sich nicht in der Liste der offiziell unterstützen befinden.
Fazit
Die Möglichkeit, Applikationen auf Geräten ohne Desktop-Umgebung ausführen zu können, ist nur in wenigen UI-Frameworks vorzufinden. Im .NET-Umfeld sind es entsprechend noch einmal deutlich weniger. Avalonia besetzt damit eine Nische und liefert ein modernes, XAML-basiertes UI-Framework mit mächtigem .NET-Unterbau für die Embedded-Welt.
