Von Electron zu .NET MAUI?

M icrosoft hat .NET MAUI im Mai 2022 als finale Version veröffentlicht. Nach langer Entwicklungszeit steht damit das Framework für plattformübergreifende mobile und Desktop-Anwendungen zur Verfügung. Zudem ist ein produktiver Einsatz nicht mehr eingeschränkt, sondern von Microsoft freigegeben. Nach und nach befassen sich immer mehr Entwickler mit dieser neuen Möglichkeit, mit .NET und C# Anwendungen zu implementieren. Auch die Community entwickelt sich rasant in Richtung des neuen Frameworks, was sich beispielsweise in Form von externen Bibliotheken und Frameworks zeigt. Anbieter von Steuerelementen und Komponenten aller Art sind bereits seit geraumer Zeit damit beschäftigt, ihre Produkte fit für .NET MAUI zu machen.Das ist kein schlechter Zeitpunkt, um über eigene Anwendungen und Softwareprodukte nachzudenken. Lohnt es sich, diese auf .NET MAUI zu migrieren, oder sind gar neue Projekte geplant, die direkt auf Basis von .NET MAUI begonnen werden könnten? In beiden Fällen ist es notwendig, sich mit dem Framework auseinanderzusetzen. Beispielsweise über Testprojekte oder über die konkrete Planung und Analyse einer Migration. Ein erstes Testprojekt hat der Einführungsartikel zu .NET MAUI in dieser dotnetpro-Ausgabe genutzt [1].In diesem Artikel dagegen geht es um Planung und Analyse einer konkreten Anwendung, die zu .NET MAUI migriert werden könnte. Es ist somit noch gar nicht sicher, ob diese Migration tatsächlich stattfinden wird, ob eine andere Technologie zum Einsatz kommt oder ob es eine Mischung aus allem wird. Letzteres führt dann dazu, dass die in Electron geschriebene Webanwendung zunächst in eine andere webähnliche oder -nahe Technologie übertragen wird, um im weiteren Verlauf die Migration auf .NET MAUI oder Ähnliches zu prüfen. Diese Entscheidung ist ebenfalls ein Ergebnis der Analyse und Planung einer Migration.Hier dreht sich somit alles um die geplante Migration hin zu .NET MAUI: aus allgemeiner Sicht, was beim Einsatz von .NET MAUI zu beachten ist; aus der Sichtweise anderer Technologien für plattformübergreifende Anwendungen und aus Sicht der konkreten Anwendung, die ebenfalls in diesem Artikel erläutert wird. .NET MAUI ist im Kontext der hier vorgestellten Anwendung interessant, da es viele Plattformen unterstützt und bei den Lesern der dotnetpro Erfahrungen mit .NET, XAML und C# vorhanden sind. Das macht einen Migrationsschritt planbarer im Vergleich zu einem komplett unbekannten Ziel-Framework.

Herausforderungen und Lösungsansätze

Bei der Migration einer Anwendung stellen sich zahlreiche Herausforderungen, zu denen es zum Teil konkrete (automatisierte) Lösungsansätze gibt. Generell sind verschiedene Bereiche bei einer Migration zu berücksichtigen. Ganz klassisch sind das Frontend und Backend, die in diesem Fall aber nichts mit der üblichen Trennung bei Webanwendungen zu tun haben. Mit Frontend ist, wie gewohnt, die Oberfläche gemeint. Diese muss auf den XAML-Dialekt angepasst werden, der bei .NET MAUI zum Einsatz kommt. Steuerelemente und andere Komponenten haben andere Namen und sind daher nicht direkt kompatibel mit Elementen aus der Windows Presentation Foundation (WPF) und anderen Technologien; ganz zu schweigen von der Situation, eine nicht in .NET und/oder XAML implementierte Anwendung zu migrieren. Hier sind eine gute Planung und vorherige Analyse besonders wichtig, um nichts Essenzielles zu übersehen.Wer aus der .NET-Welt kommt, kann es mit Tools wie dem .NET-Upgrade-Assistenten versuchen; er beherrscht zahlreiche Projekttypen, wie zum Beispiel für Windows Forms, WPF, UWP und Xamarin.Forms. Diese lassen sich dann automatisch in neue Projekttypen auf Basis neuer .NET-SDKs übersetzen. Damit ist beispielsweise die Migration von einer UWP-Anwendung hin zum Windows-App-SDK (WinUI) oder von Xamarin.Forms zu .NET MAUI möglich. Allerdings gibt es dabei Einschränkungen, da noch nicht alle Projekttypen unterstützt werden. Beispielsweise fehlt noch die Unterstützung für watchOS sowie tvOS, und bei konkreten Implementierungen gibt es noch keine automatisierte Migration. Das erfordert nachgelagerte und manuelle Arbeit. Bezogen auf den Upgrade-Assistenten und .NET MAUI existiert eine Dokumentation im entsprechenden Repository auf GitHub [2].Wer eine Migration plant und eine Anwendung hat, die nicht mit .NET-Technologien erstellt wurde, steht in den meisten Fällen vor größeren Herausforderungen. Hier ist gut zu prüfen, warum diese Migration überhaupt in Angriff genommen ­werden soll, was gegen die aktuell eingesetzten Technologien spricht und ob es irgendwelche Hilfsmittel für diese Migration gibt.In der Regel wird das aber eine nicht unerhebliche ­Menge an manueller Arbeit nach sich ziehen – wie in dem Beispiel, das  diesem Artikel zugrunde liegt. Es handelt sich dabei um Webtechnologien, die in Richtung .NET MAUI migriert werden sollen, vorausgesetzt, dass es sich technisch und inhaltlich anbietet. Ob das der Fall ist, wird sich im Lauf dieser Untersuchung zeigen.

.NET MAUI und Flutter

Flutter ist als Technologie häufig im Gespräch, wenn es um plattformunabhängige Anwendungen geht. Flutter verwendet die Programmiersprache Dart von Google. Dart ist eine C-ähnliche Sprache, die eine zügige Kompilierung zu nativem Code ermöglicht, wodurch sie mit nahezu nativer Geschwindigkeit ausgeführt werden kann. Im Gegensatz zu einigen anderen Native-UI-Toolkits ist Flutter dadurch zu der leistungsfähigen .NET-6-Basis von MAUI konkurrenzfähig.Bis vor Kurzem lief Flutter nur auf Android und iOS. Kurz vor der Veröffentlichung von .NET MAUI hat Flutter jedoch Unterstützung für Windows-, macOS- und Linux-Desktops hinzugefügt, wobei die Linux-Unterstützung von der Community bereitgestellt wird. Darüber hinaus hat Samsung die MAUI-Unterstützung für sein Betriebssystem Tizen bereitgestellt.Da Dart unter Programmierern nicht so populär ist wie .NET, sind die Optionen für Bibliotheken und andere Tools von Dritt­anbietern bei Flutter begrenzter als bei MAUI, was sich aber in der Zukunft schnell in beide Richtungen ändern kann.

.NET MAUI und React Native

Die Entwicklung in React Native soll so kompatibel wie möglich mit in React JS geschriebenem Code sein. Daher verwenden in React Native geschriebene Anwendungen JavaScript und andere Webtechnologien, um den Zugriff auf den nativen Code zu ermöglichen. Da .NET das wesentlich schnellere .NET-6-Framework verwendet, hat .NET einen Vorteil, wenn es um Leistung geht.React Native ist auf ein paar mehr Plattformen verfügbar als .NET MAUI. Wie bei MAUI haben Samsung und die Linux-Community Unterstützung für ihre Plattformen in React Native eingebracht. Darüber hinaus unterstützt React Native Android TV und Apples tvOS. Derzeit gibt es keine Pläne, TV-Plattformen mit .NET MAUI zu unterstützen.React Native gibt es schon seit Langem, und es hat sich ­eine beeindruckende Liste von Bibliotheken von Drittanbietern angesammelt. Dies hat jedoch einige Nachteile, anders als bei der ebenso großen Auswahl an Drittanbieterangeboten von .NET. Es gibt zwei Möglichkeiten, Anwendungen mit React Native zu entwickeln: die ausschließliche Verwendung ­eines JavaScript-Codes oder das Hinzufügen nativer Codefunktionen. Die Verwendung der JavaScript-Option bringt die zusätzlichen Leistungseinbußen dieser Sprache mit sich, während die Verwendung der nativen Optionen die plattformübergreifende Einfachheit des Systems verringert.

Der Funktionsumfang des Monitoring-Tools

Vor der Beschreibung der Analyse und der Planung einer Migration zunächst einige Infos zum Monitoring-Tool, damit klar ist, welcher Funktionsumfang überhaupt migriert werden muss. Die technische Basis der Anwendung wird dann im weiteren Verlauf erläutert.Beim Monitoring-Tool geht es weniger um das Monitoring im Sinne eines Betriebs von zum Beispiel Microservices oder ähnlichen verteilten Anwendungen, sondern um die Überwachung der seriellen Schnittstelle. Der Hintergrund ist ein bildungsorientierter Einsatz in einem Start-up aus dem Bereich Educational Technology [3]. Die Anwendung dient dazu, die empfangenen und verschickten Zeichen über die serielle Schnittstelle an verschiedene Hardware-Komponenten anzuzeigen und steuerbar zu gestalten. Mit Hardware ist hier der Lehrcomputer Calliope mini v1 und v2 gemeint [4], der BBC micro:bit [5] und der Arduino [6]. Weitere Hardware ist in naher Zukunft ebenfalls geplant, beispielsweise der Raspberry Pi [7]. Diese Hardware kommt in Kursen, Workshops und AGs in Schulen und anderen Bildungseinrichtungen zum Einsatz. Teilnehmende lernen dabei, mit beispielsweise Scratch oder einer Scratch-ähnlichen Sprache eigene Programme zu schreiben, die zum Beispiel auf dem Calliope mini laufen und Informationen über die serielle Schnittstelle an den angeschlossenen PC schicken. Bild 1 zeigt dazu ein Beispiel im Calliope-Editor [8] von Microsoft MakeCode.

Diese Informationen werden dann in der Oberfläche des Monitoring-Tools dargestellt, lassen sich speichern und Ähnliches. Auch die Visualisierung mittels Diagrammen ist geplant.Bild 2 zeigt einen Screenshot der Anwendung. Zu sehen ist die Möglichkeit, sich automatisch mit einer beim Start erkannten Hardware zu verbinden (links oben) oder einen Port auszuwählen, der beim Start erkannt wurde (mittig oben).

Zu Testzwecken sind zudem zwei Schaltflächen vorhanden (rechts oben) zur Erstellung von gemockten Objekten für den Calliope mini v1 und v2, um mit diesen zu testen. In der Mitte der Anwendung wird die beim Start erkannte Hardware inklusive COM-Port aufgelistet, um es den Anwendern so einfach wie möglich zu machen, die Hardware zu verbinden. Im bildungsorientierten Kontext ist diese Art von Unterstützung nicht zu unterschätzen.Bild 3 zeigt die Anwendung mit zwei verbundenen Calliope mini. Der obere Eintrag ist von dem Calliope mini v2, wie die kleine 2.0 im schwarzen Kästchen anzeigt. Der zweite Eintrag darunter ist von einem gemockten Calliope mini v1, der zu Testzwecken hinzugefügt wurde. Als Referenz zeigt Bild 3 auch einen Calliope mini v2, da diese Hardware außerhalb des Bildungsbereichs oft unbekannt ist.

Die Screenshots verdeutlichen den übrigen Funktionsumfang, der bisher nicht angesprochen wurde. Der verbundene COM-Port wird angezeigt, es gibt einen Indikator, ob die Hardware noch verbunden ist, die manuelle Möglichkeit zum Verbinden und wieder Trennen der Hardware, zum Löschen der Ausgabe, zum Speichern der empfangenen Daten und zum Senden von Daten an den Calliope mini. Je nach auf dem Calliope ausgeführtem Programm wird der übertragene Text dann auf dem kleinen LED-Display des Calliope angezeigt. Bild 4 zeigt, wie das Monitoring-Tool mit empfangenen und zu verschickenden Daten aussieht.

Das ist die aktuelle Version 0.0.9 des Monitoring-Tools. Um die Weiterentwicklung der Anwendung zu gewährleisten, stellt sich nun die Frage, ob die Software migriert werden sollte oder gar muss. Die technische Basis – Näheres dazu im nächsten Abschnitt – ist zwar solide, unterstützt aber nicht alle zukünftig geplanten Einsatzgebiete. Aktuell von der Migration betroffen sind die folgenden Anforderungen:

• Automatisches Erkennen von Calliope mini v1 und v2, micro:bit und Arduino
• Möglichkeit zum Verbinden über USB (Serialport) mit der zuvor genannten Hardware
• Daten über die serielle Schnittstelle von der Hardware empfangen und textbasiert anzeigen
• Daten über die serielle Schnittstelle von der Anwendung an die Hardware übertragen
• Empfangene Daten herunterladen und in eine Datei speichern
• Zukünftig: Virtuelle Verbindung mehrerer Hardware-Sets über die Anwendung, um beispielsweise von Calliope mini eins zu zwei etwas zu verschicken
• Zukünftig: Visualisierung und Analyse der empfangenen Daten in Diagrammen
• Zukünftig: Verbindung über Bluetooth
• Zukünftig: Cloud-Anbindung, um Daten hochzuladen, zu teilen und für Bildungszwecke zu sammeln

Diese Anforderungen sind inhaltlich sicherlich nicht besonders hoch gegriffen. Wichtig ist, dass die zukünftige Technologie auch die geplanten Funktionen unterstützt, da ansonsten die Migration von einer Sackgasse in die nächste führen würde. Das gilt es mit Nachdruck zu vermeiden. Was die technische Basis dieser aktuellen Anwendung ist, verrät der nächste Abschnitt.

Die technische Basis des Tools

Für alle eingefleischten .NET- und/oder C#-Fans ist die folgende technische Beschreibung des Monitoring-Tools wahrscheinlich etwas gewöhnungsbedürftig. Implementiert wurde die Anwendung mit Visual Studio Code auf Basis von Electron. Das Framework ist mittlerweile sehr bekannt, wozu sowohl positive wie auch negative Aspekte beigetragen haben. Dabei gibt es grundsätzlich gute Gründe dafür, native Anwendungen und Webanwendungen zu vermischen. Nicht selten wird dabei von einem „hybriden Szenario“ gesprochen.Technologien wie Electron und andere erlauben ein plattformübergreifendes Entwickeln mit einer einheitlichen Code- und UI-Basis. Die Host-Anwendung ist dabei in der Regel minimalistisch. Ein weiterer Grund ist, eine native Anwendung schrittweise in Richtung von Webtechnologien und dem Einsatz in Browsern zu verschieben. Damit ist eine gestaffelte Migration möglich. Umgekehrt ist das ebenfalls ein wichtiger Grund, wenn die Webanwendung auf lokale Ressourcen zugreifen muss, die wegen der Sandbox des Browsers nicht zugänglich sind. Durch den Einsatz von Technologien wie Electron lässt sich die grundlegende Codebasis weiterhin verwenden, der native Host bietet dann zusätzlich den Zugriff auf die lokalen Ressourcen an.Zu den positiven Eigenschaften dieses Frameworks gehört, dass sich damit plattformübergreifende Desktop-Anwendungen für Windows, macOS und Linux erstellen lassen. Electron dient dabei als Container mit einer nativen Anwendung für diese Plattformen. Beim Start einer Electron-Anwendung wird somit dieser Container gestartet, der aufgrund seiner nativen Natur auch Funktionen des Betriebssystems nutzen kann. Beispielsweise ist ein Icon im Task-Bereich von Windows möglich oder das Absetzen von Benachrichtigungen unter Windows. Dieser native Container startet intern einen Webserver inklusive Browser, um mit Webtechnologien implementierte Anwendungen anzuzeigen. Electron gilt somit als Inbegriff dafür, Webtechnologien auf den Desktop gebracht zu haben.Wer das jetzt eher abschreckend findet: Das ist technisch sicherlich nachvollziehbar, weil dieser Weg eher wenig technisch und organisatorisch intuitiv erscheint. Allerdings funktioniert dieses Vorgehen tatsächlich sehr gut. Wer sich mit der Webentwicklung auskennt, kann auf diese Weise ohne viel Einarbeitung eine Anwendung auf drei verschiedene Plattformen bringen, ohne sich allzu sehr von dem eigenen Technologie-Stack entfernen zu müssen.Electron hat sich auf breiter Basis durchgesetzt. Ein sehr bekanntes Beispiel – unter Entwicklern zumindest – ist Visual Studio Code. Die IDE basiert auf Electron und wurde durch etliche Optimierungen sehr performant und ressourcensparend. Ein negatives Beispiel ist sicherlich Microsoft Teams, ebenfalls eine Electron-Anwendung und weit davon entfernt, ein gutes Laufzeitverhalten zu haben.Womit wir bei einer der negativen Eigenschaften sind. Electron-Anwendungen gelten als nicht sehr performant. Oder es bedarf einiges an Optimierungen, um diese Anwendungen zu einem guten Laufzeitverhalten zu bewegen. Andere Anwendungen, Spotify zum Beispiel – ebenfalls eine Electron-Anwendung –, liegen im Mittelfeld und funktionieren zumindest auf Windows recht gut. Die Tatsache, dass Webtechnologien auf den Desktop kommen, wird in der Community daher immer noch zweischneidig gesehen.In Electron lassen sich praktisch beliebige Webanwendungen auf Basis von JavaScript und Node.js ausführen. Das Monitoring-Tool wurde mit TypeScript auf Basis von Quasar [9] entwickelt. Quasar ist ein Application Framework, das auf  Vue.js 2 beziehungsweise 3 aufsetzt [10]. Damit lassen sich sehr schnell komplexe Anwendungen entwickeln. Die Basis bildet dabei das Web-Framework Vue, um beispielsweise die Navigation mit Vue Routing oder den Store mit Vuex zu implementieren. Ein weiterer Vorteil von Quasar ist, dass sich damit Electron-Anwendungen direkt implementieren lassen. Über einen Schalter beim Build der Anwendung wird alles Notwendige für die Electron-App installiert, konfiguriert und erzeugt. Das hat die Entwicklung ebenfalls beschleunigt.Diese Kombination hatte eine sehr schnelle Entwicklung der Beispielanwendung zur Folge. Das im vorherigen Abschnitt erwähnte Feature-Set ließ sich in rund drei Tagen implementieren, inklusive Oberfläche. Letztere besteht aus den fertigen HTML-Komponenten, die Quasar mitbringt, und wurde mittels CSS gestaltet – ein Vorteil von Webtechnologien, da der Einsatz von HTML und CSS eine praktisch beliebige Oberflächengestaltung erlaubt.Neben den bereits genannten Frameworks sind auch einige Bibliotheken im Einsatz. Die Webentwicklung bietet für ­JavaScript und Co. mittlerweile einen sehr breiten Fundus an Möglichkeiten an. Beispiele für die eingesetzten Bibliotheken sind unter anderem Intro.js [11], Node SerialPort [12], Strong­ly ­Typed Events [13], Node USB [14] und V-Hotkey [15]. Damit ist der Zugriff auf die serielle Schnittstelle möglich, auf die USB-Schnittstelle, um zum Beispiel das An- und Abstecken von Geräten an den USB-Ports mitzubekommen, für streng typisierte Events, wie sie aus .NET bekannt sind, sowie für die Umsetzung von anwendungsweiten Hotkeys und für das Onboarding mit geführten Hilfetexten. Damit lassen sich auch in JavaScript sehr komplexe und voll funktionsfähige Desktop-Anwendungen implementieren, die bis vor wenigen Jahren nur von nativen Frameworks und Programmiersprachen her bekannt waren. Zudem geben diese Bibliotheken einen weiteren Überblick darüber, wie die aktuelle Anwendung technisch umgesetzt ist. Diese Funktionalität muss auch nach der Migration auf ein anderes Framework und ­eine neue Programmiersprache funktionieren – sofern es dazu kommt.

Einschätzung und Analyse der Architektur

Die Architektur des aktuell implementierten Monitoring-Tools ist denkbar einfach. Quasar bietet eine allgemeine Infra­struktur für Webanwendungen. Vue.js baut darauf auf und stellt Komponenten bereit, um diese mittels einer Navigation zu verbinden. Da sich aber praktisch alles in der Hauptansicht abspielt, ist das ebenfalls nicht komplex.Ansonsten gibt es einige in TypeScript implementierte Klassen und Interfaces, die sich problemlos zu C# portieren lassen. Auch die Datenbindung und die Reaktivitäten der Daten – damit ist gemeint, dass sich die Oberfläche automatisch ändert, wenn sich die zugrunde liegenden Daten ändern – sind mit XAML kein Problem; beispielsweise über Muster wie MVVM und MAUI.Damit ist die aktuelle Architektur nicht komplex und lässt sich problemlos von Vue und TypeScript auf .NET MAUI mit XAML und C# übertragen. Das Frontend mit der Datenbindung und der Reaktivität lässt sich migrieren, ebenso wie das Backend, mittels OOP und einem sehr ähnlichen Aufbau von Klassen und den zu verarbeitenden Daten.

Analyse einer Frontend-Migration

Die Analyse einer möglichen Migration auf eine andere Technologie, ganz vorne mit dabei ist .NET MAUI, lässt sich gut in zwei Teile aufsplitten: zum einen die mögliche Migration des Frontends und zum anderen die dann anstehende Migration des Backends. Die Oberfläche würde, im Falle von .NET MAUI, mit XAML neu implementiert werden müssen. Ansätze lassen sich nur in geringem Umfang, bezogen auf das Design, übernehmen. Ansonsten sind beide Welten recht weit voneinander entfernt.Da aber auch XAML sehr viele Möglichkeiten bietet – nicht nur bezogen auf die Steuerelemente, sondern auch was die optischen Anpassungen ebendieser angeht, ebenso wie die Gestaltung durch das Design und das Theme der Anwendung –, ist die Wahrscheinlichkeit hoch, alles wie bisher im Monitoring-Tool gewohnt umzusetzen. Den Aufbau der Oberfläche zeigt Bild 5.

In Electron wird ein Fenster vom Typ BrowserWindow erstellt [16]. Das ist über einige Optionen auf frameless eingestellt. Das bedeutet, dass keine Rahmen, Steuerelemente oder dergleichen für das Fenster erstellt werden – egal auf welcher Plattform, das Fenster besitzt keinen Frame und keine Steuerelemente. Diese werden, um sie optisch anpassen zu können, in der App per HTML und CSS nachgebildet und über TypeScript mit Eventhandlern verknüpft, etwa um das Fenster zu verkleinern oder zu schließen. Das erlaubt eine optisch deutlich bessere Anpassung an das Gesamtlayout und an das komplette Design, auch wenn es etwas mehr Aufwand bei der Implementierung bedeutet.Bild 5 verdeutlicht zudem, dass der restliche Teil ausschließlich aus <div>-Elementen in HTML erstellt und über CSS-Flexboxen positioniert wird. Das trifft sowohl auf die Controls am oberen Rand zu wie auch auf die Aufteilung der Hauptseite mit dem Protokoll links und den Elementen zur Steuerung einer verbundenen Hardware auf der rechten Seite. Die anderen Elemente sind wahlweise HTML-Steuerelemente, wie beispielsweise Eingabefelder und Schaltflächen, oder Icons mit Links dahinter, die mit TypeScript-Funktionen verknüpft sind.Die einzelnen Zeilen pro verbundener oder virtueller Hardware sind jeweils in einem <div>-Element gekapselt; diese sind im Flex-Layout als Zeilen untereinander dargestellt. ­Eine for-Schleife arbeitet sie nacheinander ab, um alle Verbindungsobjekte, die bei einem Verbindungsaufbau erstellt werden, zu durchlaufen. Auf diese Weise werden die einzelnen Einträge pro verbundener Hardware erzeugt und in der Oberfläche dargestellt.Das ist bereits die ganze Magie hinter der gezeigten Oberfläche. Diese gilt es nun nach .NET MAUI oder einer anderen Technologie zu überführen, um mehr Plattformen zu unterstützen. Bei .NET MAUI gestaltet sich das über XAML recht einfach. Das Fenster lässt sich ebenfalls über einige Optionen ohne Titelbalken anzeigen, sodass die volle Kontrolle über die Gestaltung des Rahmens und des oberen Bereichs erhalten bleibt. Damit können Sie den Header und die darin befindlichen Steuerelemente zur Kontrolle des Fensters selbst erstellen und optisch anpassen.Auch das Menü auf der linken Seite lässt sich einbinden und anzeigen. Die restliche Oberfläche kann dann über eine Kombination von Layouts, Panels und den gängigen Steuerelementen in XAML erstellt und den Anforderungen entsprechend optisch angepasst werden. Für die Liste aus verbundenen Hardware-Komponenten bietet sich eine CollectionView mit passendem ItemTemplate und DataTemplate an. Diese Kombination sollte es in der Praxis erlauben, die Liste mit verbundenen Hardware-Komponenten und den darin enthaltenen Daten anzuzeigen.Im praktischen Einsatz wird die Liste nur wenige Einträge enthalten. Es ist anzunehmen, dass selbst bei umfangreicher Nutzung selten mehr als fünf und nur in sehr seltenen Fällen bis zu zehn Hardware-Sets verbunden sind. Daher ist das CollectionView-Objekt dafür leistungsfähig genug, auch dann, wenn in der Liste die empfangenen Daten der verbundenen Hardware-Sets in Form einer TextBox angezeigt werden. Das ist im Zweifel bei der Migration durch einen Prototyp zu testen und zu bewerten. Aufgrund der wenigen aktiven Verbindungen zur Hardware ist allerdings anzunehmen, dass das problemlos funktioniert.Die Datenanbindung zwischen Backend und Frontend ist bei .NET MAUI entweder direkt im Code-behind möglich oder über Muster wie Model-View-ViewModel (MVVM) oder Model-View-Update (MVU). Somit ist die Datenbindung und die Reaktivität, die durch Vue gegeben ist, ebenfalls kein Problem.

Analyse einer Backend-Migration

Das Backend des aktuellen Monitoring-Tools ist ebenfalls recht weit vom neuen Technologie-Stack entfernt. Die Implementierung basiert auf TypeScript, das zu einem Teil in den Vue-Dateien eingebunden ist. Listing 1 zeigt dazu ein sehr vereinfachtes Schema. Diese Vue-Komponenten realisieren durch das Template die Oberfläche, durch die Styles das Design und durch die Komponenten sozusagen den Code-behind. Dazu gehört beispielsweise die Implementierung von Eventhandlern für Schaltflächen, die Methoden mit dem Code, der beim Initialisieren der Komponente ausgeführt wird, und dergleichen.

Durch den Einsatz von TypeScript kommen schon jetzt verschiedene Klassen und Interfaces zum Einsatz. Listing 2 zeigt einen Ausschnitt aus der Hardware-Klasse, die als abstrakte Klasse für die konkreten Hardware-Implementierungen für den Calliope mini und andere dient. Diese abstrakte Klasse implementiert ein Interface, das die Schnittstelle für die Hardware definiert. Durch dieses Design und die objektorientierte Implementierung ist eine Migration zu einer anderen Programmiersprache, beispielsweise C# bei .NET MAUI, kein großes Problem. Aber auch eine Migration zu einer nicht objektorientierten oder einer funktionalen Sprache wäre prinzipiell machbar. Auf diese Weise verursacht der Schritt von einer OOP-Sprache zu einer weiteren OOP-Sprache aber wahrscheinlich den geringsten Aufwand.

Die weiteren Merkmale der aktuellen Anwendung müssen ebenfalls über die Backend-Migration umgesetzt werden, beispielsweise der Zugriff auf die serielle Schnittstelle über USB oder die in Zukunft geplante Bluetooth-Schnittstelle. Das ist wichtig und glücklicherweise in .NET möglich. Andere geplante Funktionen, wie der Zugriff auf eine Cloud, um Daten abzulegen, zu teilen und mit anderen zu arbeiten, sind auch in .NET und in C# Standardprobleme und damit lösbar.Bei der Verknüpfung von Frontend und Backend bieten
.NET MAUI als Plattform und C# als Programmiersprache viele Möglichkeiten, etwa die genannten MVVM- und MVU-Muster. Und wenn das zu komplex erscheint, lässt sich die aktuelle Geschäftslogik in die Code-behind-Dateien der XAML-Oberflächen aufnehmen. Selbst dieser Weg ist hier bei der geringen Gesamtkomplexität der Anwendung möglich. Eine zweite Phase der Migration könnte diese Implementierung dann in Richtung eines der genannten Muster verschieben, damit der Code auch in Zukunft wartbar bleibt.

Eine technologische Einschätzung

Die Einschätzung einer Migration auf .NET MAUI, aus rein technologischer Sicht, ist nach der Analyse äußerst gut. Sowohl Frontend wie auch Backend lassen sich mit der Technologie umsetzen, und auch den in Zukunft geplanten Merkmalen steht nichts im Wege. .NET MAUI scheint eine gute Wahl zu sein, um deutlich mehr Plattformen zu unterstützen und die gesamte Anwendung auf eine moderne Basis zu stellen.Die finale Entscheidung für eine Migration der Beispielanwendung in Richtung .NET MAUI ist allerdings noch nicht getroffen. Dazu laufen beim Autor momentan die ersten technischen Versuche und die Einarbeitung auf Basis von XAML. Umsetzung und Migration werden dann, wenn die Entscheidung für .NET MAUI endgültig gefallen ist, in weiteren Artikeln an konkreten Beispielen und detaillierter vorgestellt.Was bei der Analyse als klares Ergebnis herausgekommen ist, ist die Tatsache, dass eine zunächst geplante Migration auf reine Webtechnologien nicht ansteht. Die Idee war, die Electron-Anwendung komplett zu entfernen und die in Quasar und Vue.js implementierte Anwendung im Browser laufen zu lassen. Das ist dank des Web Serial API und des Web USB API mittlerweile kein Problem mehr. Browser können, nach einer notwendigen Nutzerinteraktion, direkt auf an den Rechner angeschlossene Hardware über USB oder Bluetooth zugreifen. Diese Erweiterungen sind noch immer als experimentell gekennzeichnet und leider nicht in allen Browsern verfügbar [17]. Das führt dazu, dass notwendige Plattformen, wie beispielsweise Tablets, nicht gut oder nur durch Modifikationen unterstützt werden. Da die Unterstützung dieser Plattformen ein zentrales Ziel ist, funktioniert dieser technische Weg nicht. Spannend wäre so eine Migration schon, da weniger Aufwand zu erwarten ist und Browser ebenfalls praktisch überall funktionieren.Die konkrete Entscheidung zu einer Migration wird Ende 2022 fallen. Dann ist die zukünftige Planung abgeschlossen und die Migration startet, dann auch dazu mehr an dieser Stelle. Die Migration soll bis Mitte März abgeschlossen sein und Windows, macOS und iPads als erste Systeme unterstützen. Die restlichen folgen dann, da diese zwar wichtig sind, die drei genannten Plattformen aber Vorrang haben.

Fazit

.NET MAUI ist eine vielversprechende Möglichkeit, um mit .NET und C# zahlreiche Systeme zu unterstützen. Es ist mächtig, und die Möglichkeiten sind zahlreich. Eine Mi­gration von einer anderen Technologie, wie in diesem Fall Electron und dem Web-Stack, ist daher keine allzu weit weg liegende Idee. Wenn sich .NET MAUI etabliert hat, wird sich diese Frage sicherlich in zahlreichen Teams und Unternehmen stellen.Aber auch andere Wege sind möglich. Auch Flutter ist ein gutes Beispiel, das zahlreiche Plattformen unterstützt. Genau betrachtet bietet Flutter sogar eine noch umfangreichere Abdeckung an Plattformen, die .NET MAUI nicht adressiert. Daher hängt es am Ende auch immer davon ab, was genau umgesetzt werden muss, welcher Technologie-Stack gerade vorliegt und was das Ziel ist. Die Erfahrungen im Team sind ebenfalls zu berücksichtigen. Eine neue Technologie nutzen zu wollen, die noch keiner beherrscht, ist durchaus riskant.Im Fall des Monitoring-Tools wird Abstand genommen von der Zwischenmigration in den Browser. Geplant ist, die Electron-Anwendung durch .NET MAUI abzulösen, um weitere Systeme anzusprechen, insbesondere Smartphones und Tablets, da diese in Schulen und Bildungseinrichtungen sehr häufig im Einsatz sind. Zudem ist C# im Team bekannt und in XAML ist eine Einarbeitung möglich.Sobald es weitere Informationen und einen Fortschritt bei der Migration gibt, wird dotnetpro dies in weiteren Artikeln vorstellen. Bis dahin ist etwas Geduld gefragt.

Fussnoten

1. Fabian Deitelhoff, Was lange währt, Plattformüber­geifende Anwendungen, dotnetpro 2/2023, Seite 8 ff., http://www.dotnetpro.de/A2302MAUI
2. Migrating from Xamarin.Forms to .NET MAUI, http://www.dotnetpro.de/SL2302MAUIMigration1
3. Wikipedia, Educational Technology, http://www.dotnetpro.de/SL2302MAUIMigration
4. Calliope mini, https://calliope.cc
5. BBC micro:bit, https://microbit.org
6. Arduino, http://www.arduino.cc
7. Raspberry Pi, http://www.raspberrypi.com
8. Microsoft MakeCode for Calliope mini, https://makecode.calliope.cc
9. Quasar, https://quasar.dev
10. Vue.js, https://vuejs.or
11. Intro.js, https://introjs.com
12. Node SerialPort, https://serialport.io
13. Strongly Typed Events, http://www.dotnetpro.de/SL2302MAUIMigration3
14. USB Library for Node.JS, http://www.dotnetpro.de/SL2302MAUIMigration4
15. V-Hotkey, http://www.dotnetpro.de/SL2302MAUIMigration5
16. Electron, Browserfenster, http://www.dotnetpro.de/SL2302MAUIMigration6
17. Web Serialport API, http://www.dotnetpro.de/SL2302MAUIMigration7