Am Puls von Microsoft

Entwicklertagebuch MyLife #6: Das Leben wird mobil dank .NET MAUI

Entwicklertagebuch MyLife #6:  Das Leben wird mobil dank .NET MAUI

Das Leben als auch MyLife.NET findet heutzutage nicht nur im Web und in der Cloud statt, sondern natürlich auch mobile – oder sogar hauptsächlich dort. Mit .NET MAUI gibt es die passende Lösung für Entwickler dieses Ökosystems gleichzeitig für Apple-, Android- und Windows-Systemen Apps zu entwickeln.

Für alle, denen diese Artikelreihe noch unbekannt ist – das habt ihr bislang verpasst, könnt euch aber natürlich nachträglich einlesen:

Community ftw!

Auch wenn ich mich in meinen Beiträgen wiederhole: Für mich ist ein lehrreiches Community-Ökosystem zu einer Sache, mit der ich mich beschäftigen möchte, das A und O, um wirklich meine freie Zeit darin zu investieren. Angefangen bei der tollen Gemeinschaft rund um Dr. Windows, weiter zu Programmiersprache, 3D-Druck und anderen spannenden Dingen, mit denen man seinen Feierabend verbringen kann.

Bei .NET MAUI ist dies nicht so ausgeprägt wie bei Mainstream-Frameworks wie React Native, dennoch möchte ich mit voller Überzeugung zwei Discord-Communities empfehlen.

MAUI Community ToolKit Community

Diese kleine, aber feine englischsprachige Community ist der Treffpunkt der Menschen hinter dem mächtigen MAUI Community Toolkit, kurz MCT, NuGet-Paket. Dennoch werden hier auch mit wirklichen Fachwissen Fragen auch von Anfängern rund um MAUI beantwortet. Auch Ökosystem-Größen wie Gerald J sind dort online und unterhalten sich mit jedem, egal ob Maintainer, Profi oder Anfänger. Eine echt entspannte Umgebung.

C# Discord Server

Dieser ist, wie der Name schon erwarten lässt, breiter aufgestellt und behandelt dieser Server in separaten Kanälen nahezu alles, was man mit C# aber auch .NET bewerkstelligen kann. Der Channel “mobile” wiederum betrifft explizit die Entwicklung mobiler Apps, ist allerdings nicht nur auf MAUI beschränkt, sondern behandelt von Zeit zurzeit auch andere Frameworks wie Uno oder Avalonia.

Mein Fehler, MAUI-Fehler oder wer ist schuld?

Das ist für mich nicht immer leicht zu sagen. Während meiner Entwicklung für den aktuellen App-Stand hatte ich öfters das Gefühl, dass ich gegen Wände laufe und nicht vor oder zurück weiß, da irgendeine Funktion oder Feature nicht so funktionierte, wie es in meinem Kopf skizziert war. Auch wenn die besagten Communities mir oft weiterhelfen konnten oder Links zu Github Issues von .NET MAUI weiterleiteten, war und bin ich dennoch oft nicht sicher, ob der Fehler nun wirklich bei MAUI liegt oder doch eher an meiner Unerfahrenheit, weil es oft so “das muss doch ohne Probleme gehen”-Dinge waren.

Ein Beispiel hierfür ist das Setzen einer Rahmenfarbe in XAML durch ein Binding. Im Folgenden Use-case möchte ich die Farbe programmatisch setzen.

Das Binding für den Radius funktionierte ohne Probleme und direkt, als ich es geschrieben habe. Das Binding darunter bezüglich der Rahmenfarbe nicht. In meinen Gedanken spielte ich viel mit Control-Hierarchie und Co durch, in was XAML manchmal sehr komplex werden kann.

Auf GitHub findet man nun das Issue “TemplateBinding with CornerRadius on Border does not work anymore #21747”, wo nach längerem Hin und Her nun klar wurde, dass es sich um ein .NET MAUI-Problem handelte und mit einer neuen Version des Frameworks nun behoben ist.

sss

So oder so – es ist dennoch schön, das Feature von alternierenden Rahmenfarben endlich funktionieren zu sehen.

TIL: XAML Converter vs. Wrapped Model

Hinter dieser eventuell kryptisch wirkenden Frage versteckt sich ein Punkt, den ich bisher noch nie in meinem XAML-Leben bedacht habe. Wann sollte man einen Converter (Microsoft Learn) in XAML verwenden und wann in einer eigens definierten Komponente das Datenmodel nochmal in ein anderen Datenmodel packen, was zusätzlich noch beispielsweise Styling Parameter wie im Beispiel von oben den Radius und die Farbe des Rahmens enthält?

Ich denke, diese Frage lässt sich nicht einfach beantworten. Für mich habe ich herausgefunden, dass, sobald es in XAML verschiedene Hierarchie-Ebenen zu parametrisieren gibt oder die Converter auf einer Datenquelle iterieren müssen, der Weg mit einem Wrapped-Model einfacher in der Entwicklung und in der Laufzeit flotter ist, als die mittlerweile doch recht altbackenen Converter Klassen.

Was meint ihr dazu? Wie verwendet ihr Converter, wenn es mehr als nur um die Formatierung von Text geht? Lasst uns dazu gerne austauschen!

Visual Studio Code wird immer besser – dennoch meh

Microsoft arbeitet hart daran, Visual Studio Code zu einer vollwertigen Entwicklungsumgebung für .NET-Projekte zu gestalten. Dies wird auch nach meinen Erfahrungen immer besser, vor allem in Bezug auf MAUI und XAML. Somit sehe ich VSC wirklich als das Programm der Wahl in der Zukunft, wenn es darum geht, irgendwas mit C# beziehungsweise .NET zu machen – und zwar auf allen Plattformen, egal ob Windows oder, wie in meinem Fall, macOS. Die Betonung liegt hier auf “in der Zukunft”, jetzt im Moment ist es noch kein Vergleich zu einem Visual Studio oder einen JetBrains Rider.

Dieser Umstand lässt mich als Mac-Nutzer, welcher .NET als Hobby betreibt, die Wahl aus einem unbequemeren Editor oder das jährliche Abonnement für JetBrain’s Rider zu bezahlen, wenn diese nicht gerade eine kostenfreie EAP (Early Access Program) Version anbieten, welche, wie der Name schon sagt, sehr fehleranfällig sein kann.

Wie geht es weiter?

Falls ihr euch den aktuellen Stand einmal anseht, merkt ihr, dass alles noch nur Barebone ist. Wenn man auf die Kacheln der Beiträge klickt, passiert nichts und auch sonst wirkt die App leer. Diese werde ich nach und nach mit Leben füllen und evaluieren, wo man gewisse Benutzerinteraktivitäten einbauen kann. Anders habe ich mir überlegt, diesen Stand einmal in MAUI Hybrid mit Blazor nachzubauen – ach hätte man doch nur ein 5 Tage Wochenende.

Auch wenn das Projekt in Bezug auf den Entwicklungsfortschritt aus vielerlei Gründen ins Stocken geraten ist, heißt es nicht, dass ich es aufgegeben habe. Ich genieße die Freiheiten des Status als “Bastelprojekt”, um mich eben nicht stressen zu müssen, Funktionalitäten zu entwickeln, sondern mich an den Rechner zu setzen, wenn ich Lust und Laune habe, an Feature x bei MyLife.NET weiterzuarbeiten.

Ihr habt Lust mitzuwirken?

Falls ihr euch beteiligen wollt, weil ihr mir zeigen wollt, wie etwas richtig oder einfacher geht oder ihr euch zum ersten Mal an einer noch übersichtlichen .NET-Solution beteiligen wollt, seid ihr herzlich eingeladen, auf GitHub vorbeizusehen, das Repository zu forken, Issues mit Problemen oder Hinweisen zu eröffnen oder einfach zu stöbern. Wir alle sind hier, um zu lernen und, noch wichtiger, um Spaß an der Softwareentwicklung zu haben!

Persönliche Anmerkung

Dies ist mein 100. Artikel unter meinem Namen hier auf Dr. Windows. Ich möchte hiermit einfach nur “Danke!” sagen an das Team rund um Martin und Kevin als auch an euch, die Leser, die Kommentatoren, die Community-Mitglieder von Dr. Windows. Danke und auf die kommenden 100 Artikel!

Über den Autor

Tobias Scholze

Tobias Scholze

Bayrischer Open Source- und Community-Enthusiast, Verfechter des neuen Microsoft und Wandler zwischen den Betriebssystemwelten. #communityrocks Von Herzen ein Nerd mit der festen Überzeugung, dass man gemeinsam und durch den Einsatz von moderner IT die Welt für jeden ein Stückchen besser machen kann.

Anzeige