Im letzten Blogartikel habe ich Protobuf als Serialisierungsformat vorgestellt [1]. In diesem Artikel möchte ich mich mit einem Thema beschäftigen, auf das man im Laufe eines Projekts früher oder später kommt: Wie erweitere ich eine Protobuf Nachricht so, dass die Änderung kompatibel zur vorherigen Version der Nachricht bleibt? Diese Frage taucht typischerweise dann auf, wenn eine zu ändernde Nachricht zwischen zwei oder mehr Services ausgetauscht wird, diese Services bei einem Update aber nicht gleichzeitig aktualisiert werden (können). Nehmen wir ein einfaches Beispiel: Ich möchte in neues Feld in einem Nachrichtentyp hinzufügen. Zunächst mache ich das am Service, welcher die Nachricht sendet und etwas später mache ich das bei den empfangenden Services. Geht das einfach so? Diese und weitere ähnliche Fragen möchte ich mit diesem Artikel beantworten. Ich beziehe mich bei den Beispielen ausschließlich auf C# und die Protobuf Implementierung im Paket Google.Protobuf.
Technologien
Protobuf in C# serialisieren und deserialisieren
Es gibt eine lange Liste von Formaten, welche für die Serialisierung und Deserialisierung von .NET Objekten verwendet werden kann. Xml und Json sind dabei lediglich die populärsten Vertreter. In diesem Artikel möchte ich mich mit Protobuf (oder ausgeschrieben „Protocol Buffers“) beschäftigen. Protobuf ist ein Format von Google. Es ist auf Performance und möglichst wenig Platzverbrauch ausgelegt. Zudem gibt es Unterstützung für viele verschiedene Programmiersprachen – C# ist nur eine davon. Protobuf lässt sich mit den Bibliotheken von Google in Java, Python, Objective-C, C++, Kotlin, Dart, Go, Ruby, PHP und natürlich C# verwenden. Es findet auch im Protokoll gRPC Verwendung. Letzteres ist einer der Gründe, warum ich mich mit Protobuf mehr in der Tiefe beschäftigt habe. Schließlich interessiert mich nicht nur die Serialisierung selbst oder Sachen wie die Performance, sondern auch wie mit Kompatibilitätsthemen (neue Felder, umbenannte Felder, etc.) umgegangen wird. In diesem Artikel schauen wir uns diese Themen anhand zweier alternativer Bibliotheken an. Diese sind Google.Protobuf von Google und protobuf-net von Marc Gravell.
Testautomatisierung mit Avalonia
Testautomatisierung auf UI Ebene ist häufig nicht so einfach zu erreichen. Grund dafür können technische Fragestellungen sein. So gilt es, auf irgendeine Art das Rendering des UI-Frameworks abzubilden. Ebenso gilt es, mögliche Usereingaben zu emulieren oder Eingabeelemente an der UI zu identifizieren. Auch zeitliche Aspekte spielen mit rein, so ist ein „Warte eine Sekunde…“ in einem automatisierten Test i. d. R. eine eher schlechte Idee. Doch es gibt auch Herausforderungen, die aus den Testfällen selbst entstehen. Versucht man etwa, ein Drag-Drop Verhalten automatisiert zu testen, beißt man sich dabei schon mal gerne die Zähne aus. Ich persönlich versuche UI Tests daher auf einem niedrigen Level zu halten, setze sie also primär für einfach zu überblickende Geradeausfälle ein. Mit Avalonia habe ich UI Tests zuletzt bei meinem Nuget-Paket RolandK.AvaloniaExtensions [1] eingesetzt. Hier ging es mir darum, dass die dort definierten Basisklassen und Features wie die Dependency Injection einwandfrei in einer Avalonia Applikation funktionieren.
Avalonia FluentTheme zur Laufzeit wechseln
Viele moderne Applikationen bieten neben einer ansprechenden UI auch den Wechsel zwischen verschiedenen Themes an. Für gewöhnlich wird zumindest zwischen Hell und Dunkel unterschieden. Gleiches gilt für das Betriebssystem selbst – Windows und macOS bieten dem User jeweils die Wahl zwischen Hell und Dunkel. Auch Avalonia bietet mit dem FluentTheme seit Version 0.10 einen sehr einfachen Weg an, zwischen hellen und dunklen Modus zu unterscheiden. Typischerweise wird das FluentTheme in der App.xaml angegeben und bekommt als Mode entweder „Light“ oder „Dark“. In diesem Artikel wollen wir uns damit beschäftigen, wie diese Einstellung zur Laufzeit der Applikation verändert werden kann. Weiterhin schauen wir uns an, wie man unter Windows den aktuell konfigurierten Theme herausbekommt und sogar auf Änderung des aktuellen Theme reagieren kann.
Avalonia Applikationen übersetzen
In den letzten Monaten habe ich vermehrt Artikel über das Cross-Platform Framework Avalonia geschrieben. Für mich persönlich hat sich das Framework mittlerweile zum Standard für Desktop-Applikationen entwickelt. Es kann fast alles, was man braucht und läuft auf allen gängigen Desktop Plattformen (Windows, macOS, Linux) stabil. In diesem Artikel möchte ich mich mit einem Thema beschäftigen, auf das die meisten Softwareentwickler bei UIs irgendwann stoßen: Applikationen in andere Sprachen übersetzen. Auch wenn man nicht den akuten Bedarf hat, so sollte man UIs möglichst von vorne herein darauf vorbereiten, dass sie übersetzbar sind. Übersetzung im Nachhinein einzubauen kann häufig sehr schwierig sein. Insbesondere, wenn Daten von außen bereits behaftet mit einer bestimmten Sprache in der eigenen Applikation ankommen.
Das DataGrid von Avalonia
Das auf .Net basierende Cross-Plattform UI Framework Avalonia verfügt über eine große Palette an Standard-Controls. Es ist vieles dabei, was man als Entwickler typischerweise braucht. So gibt es etwa diverse Eingabeboxen, Controls für Auflistungen und welche, über die das Layout beeinflusst werden kann. Wenn ich auf Business-Applikationen schaue, fällt mir zudem noch ein sehr wichtiges ein, welches Avalonia mitbringt: Das DataGrid. Die Aufgabe eines DataGrids besteht grundsätzlich darin, eine mehr oder weniger lange Liste von Objekten in tabellarischer Form darzustellen. Jede Zeile ist ein solches Objekt, jede Spalte bezieht sich auf eine Eigenschaft. Daneben gibt es typischerweise Anforderungen wie zum Beispiel Sortierung, Filterung oder Gruppierung. Das DataGrid in Avalonia liefert diese Features entweder direkt oder bringt sie über den kleinen Umweg einer CollectionView im ViewModel mit. In diesem Artikel möchte ich mich mit den Features beschäftigen, welche das DataGrid in Avalonia im Standard mitbringt und wie man diese verwendet.
Json-Daten in SQL-Server per Entity Framework Core 5
Update vom 16.10.2022: Dieser Artikel bezieht sich auf EF Core 5. Ab EF Core 7 ist das Speichern von Json-Dokumenten im SQL-Server im Standard-Lieferumfang dabei. Im .Net Blog unter [1] wird beschrieben, wie das Feature funktioniert. In diesem Artikel möchte ich mich mit einem doch recht speziellen Thema beschäftigen, welches mir neulich bei einem Projekt begegnet ist. Die Anforderung, Json-Daten in einem SQL-Server zu speichern, klingt zunächst sehr ungewöhnlich bis falsch. SQL-Server ist sicher nicht die erste Wahl dazu, da die Datenbank auf strukturierte Daten ausgelegt ist, welche sich auf Tabellen und Beziehungen zwischen den Tabellen abbilden lassen. Unstrukturierte Json-Dokumente passen hier nicht wirklich ins Konzept, dokumentenorientierte Datenbanken sind dagegen auf solche Daten spezialisiert. Wie kommt man nun auf die Idee, SQL-Server dafür zu verwenden? Ganz einfach, es geht u. A. um den Betrieb. Man muss es sich schon überlegen, ob man wegen einer einzelnen neuen Anforderung direkt eine komplett neue Technologie betreiben möchte. Der SQL-Server und das Wissen darüber dagegen steht im Projekt und im Betrieb schon zur Verfügung. Nach einer kurzen Recherche stellte sich für mich zudem heraus, dass es durchaus nicht einmal so ungewöhnlich ist, SQL-Server zum Speichern von Json-Dokumenten zu verwenden. Es gilt lediglich, einige Punkte zu beachten.
Markdown-Dokumente mit Avalonia rendern
Markdown ist eine sehr einfache und leicht erlernbare Auszeichnungssprache, welche heute von vielen Produkten unterstützt wird. Häufig dient Markdown dazu, Html-Dokumente zu generieren. Der große Vorteil für mich gegenüber Html oder andere Auszeichnungssprachen ist, dass das Markdown-Dokument selbst bereits gut durch einen Menschen lesbar und der Funktionsumfang auf das notwendige beschränkt ist. Der Einstieg ist entsprechend schnell und selbst ohne vorher die Syntax zu kennen, kann diese leicht verstanden werden. Unter [1] sind weitere Detailinfos über Markdown zu finden. Ein sehr gutes Beispiel zur Verwendung von Markdown ist GitHub. Markdown-Dokumente im Repository erscheinen im Browser direkt als daraus generierte Html-Seiten. In diesem Artikel beschreibe ich etwas ähnliches mithilfe des Cross-Plattform Frameworks Avalonia. Auch hiermit ist es möglich, ein Dokument in der Markdown-Syntax zu schreiben und in der Anwendung anzuzeigen. Sinnvoll ist das etwa bei der Anzeige von in der Anwendung integrierten Hilfeseiten. Der Entwickler schreibt damit innerhalb seiner Entwicklungsumgebung in der Markdown-Syntax und in der Oberfläche erscheint es als sauber formatierte Seite.
Custom Window Chrome mit Avalonia
Moderne Desktop-Applikationen bringen auch ihren eigenen Fenster-Rahmen mit. Das gehört zum guten Ton und lässt sich bei zahlreichen Beispielen beobachten. In den meisten GUI-Frameworks gibt es einen Weg, genau das zu erreichen. So kann bei WPF oder Windows.Forms der Standard-Rahmen komplett ausgeblendet und damit durch das eigene Programm selbst gerendert werden. Ähnliches gilt auch für Avalonia. Aufgrund des plattformübergreifenden Ansatzes von Avalonia müssen aber einige Kleinigkeiten beachtet werden. So wird hier nicht garantiert, dass es auf jeder Plattform funktioniert. Auch die Standard-Buttons für Maximieren, Minimieren etc. sind je nach Plattform wo anders (rechts bei Windows, links bei macOS). In diesem Artikel möchte ich mich somit genauer mit diesem Thema beschäftigen und zeigen, wie ich es dann bei der App MessageCommunicator gelöst habe.
Eingabevalidierung in Avalonia mit INotifyDataErrorInfo
In den letzten Wochen habe ich mich wieder stärker mit der GUI im Projekt MessageCommunicator [1] beschäftigt. Diese ist hier komplett in Avalonia implementiert und damit ist die Anwendung für Windows, Linux und MacOS verfügbar. Neben einigen Styling-Anpassungen (Wechsel Light/Dark-Theme) habe ich auch eine Datenvalidierung mithilfe der auch in WPF beliebten INotifyDataErrorInfo Schnittstelle integriert. Diese Schnittstelle arbeitet ähnlich wie INotifyPropertyChanged und ermöglicht, asynchron je gebundener Eigenschaft Fehler an die GUI zu melden.