Das Projekt RK GPXviewer ist ein Modulith in Form einer Desktop Applikation. Das heißt, dass das Programm in mehrere lose gekoppelte Module aufgeteilt ist. Jedes Modul hat hierbei eine öffentliche Schnittstelle und eine nur innerhalb des Moduls sichtbare Logik. Diese Trennung zwischen öffentlicher Schnittstelle und privaten Logikklassen ist hierbei eine strenge Regel. Sie soll sicherstellen, dass das Geflecht an Modulen auch in Zukunft sauber wartbar und erweiterbar bleibt. Nur wie lässt sich die Einhaltung einer solchen Regel am besten sicherstellen? Alle Module befinden sich in der gleichen Projektmappe, eine Regelverletzung wirkt geradezu einladend. Ist eine notwendige Methode oder Eigenschaft gerade nicht in der Schnittstelle enthalten, ist es relativ einfach, ohne Umwege direkt auf die Logik-Klassen zuzugreifen. Man muss lediglich etwas von privat auf öffentlich umstellen – merkt schon keiner. Oder einen Verweis hinzufügen, merkt auch keiner… Damit das nicht passiert, lassen sich für solche Regeln Roslyn Analyzer schreiben. Diese prüfen den Code während des Compile-Vorgangs und geben nach Wahl direkt Fehler oder Warnungen aus. In diesem Artikel möchte ich auf den Roslyn Analyzer eingehen, welchen ich für RK GPXviewer zur Einhaltung obiger Regel umgesetzt habe.
OpenSource
Worklog SeeingSharp 2: Unterstützung für WinUI 3 Desktop
Im März 2021 wurde die erste stabile Version von WinUI 3 zusammen mit Project Reunion 0.5 veröffentlicht. Vorher gab es bereits mehrere Preview-Releases von WinUI 3, welche einen ersten Blick auf das Framework ermöglicht haben. Nun aber durch das erste stabile Release ist ein guter Zeitpunkt zur Umsetzung der WinUI 3 Desktop Unterstützung in SeeingSharp 2 erreicht. Mit WinUI allgemein beschäftige ich mich schon länger, so basiert die Beispielapplikation von SeeingSharp 2 für die Universal Windows Plattform (UWP) bereits auf Komponenten von WinUI 2 [1]. WinUI 2 ist allerdings noch auf die UWP beschränkt, mit WinUI 3 entfällt diese Abhängigkeit. Mit der neuen Version des Frameworks ist es nun möglich, WinUI Komponenten direkt in einer Desktop-Applikation zu verwenden.
Prism als Basis von modern strukturierten Applikationen
Auf Prism wurde ich zum ersten Mal bei einem Vortrag bei der .Net Usergroup Regensburg aufmerksam – vor locker 10 Jahren. Zunächst wusste ich gar nicht, um was es sich genau handelt. Nach dem Vortrag und weiterer Recherche hat Prism aber die Art und Weise, wie ich Desktop- und Mobile-Applikationen strukturiert habe, maßgeblich beeinflusst. Ein wichtiger Punkt für mich damals war die Aufteilung einer großen Applikation in mehrere, lose miteinander gekoppelte Module und die dafür bereitgestellten Best Practices. Prism folgt dabei den Grundsätzen des MVVM-Patterns und erweitert dieses um weitere Werkzeuge wie CompositeCommand, dem bereitgestellten EventAggregator oder eben Basisklassen für Module. Zusätzlich wird ein DI-Container integriert. Für die Desktop-Applikation RK GPXviewer [1], welche ich gerade für die Planungen meiner Wander- und Fahrrad-Touren im Sommer baue, verwende ich die aktuelle Version von Prism und möchte hier in diesem Artikel einige Erfahrungen damit teilen.
Worklog SeeingSharp 2: Neuer Anstrich mit WinUI
Die Beispielapplikation von Seeing# 2 für UWP Apps habe ich jetzt schon länger nicht mehr angerührt. Vorher habe ich die App sehr ähnlich der Beispielapplikation für WPF gestaltet. Hat an sich gut funktioniert, hat aber auch nicht viel mit UWP zu tun. Um die App etwas moderner wirken zu lassen, habe ich einige Controls aus dem WinUI 2 Projekt integriert und auch einige Elemente des FluentDesigns mit aufgenommen. Allem Voran das NavigationView Element, wie man es im Screenshot schon sieht. Insgesamt sind die neuen Funktionen recht leicht anzuwenden, einige blöde Fallen gibt es aber leider…
Worklog SeeingSharp 2: Styling für ModelViewer
Dieses Wochenende ist für mich der ModelViewer von Seeing# wieder in den Fokus gerückt. Grund war ursprünglich, dass ich mehrere Detailinformationen zum geladenen 3D-Modell anzeigen wollte (z. B. Anzahl Polygone). Da ich dazu ein neues Fenster gemacht habe, habe ich bei der Gelegenheit auch das Styling des ModelViewers etwas überarbeitet. Für mich zunächst leichtes Neuland, da ich sonst eines der großen kommerziellen UI-Frameworks für WPF gewohnt bin. Nach etwas Recherche in der OpenSource-Welt und ein paar kleinen Testprojekten bin ich aber sehr positiv überrascht, wie gut und schnell man hier auch mit OpenSource-Komponenten zum Ziel kommt.
Worklog SeeingSharp 2: Memory Management
In den letzten zwei Monaten habe ich mich intensiver mit Speicher-Management in .Net beschäftigt. Auslöser dafür war das Buch Pro .Net Memory Management von Konrad Kokosa [1]. Anhand der Erkenntnisse daraus habe ich verschiedene Stellen von Seeing# dahingehend angepasst, dass während der zyklischen Rendering- und Update-Logik insgesamt sorgsamer mit der Erzeugung von Objekten umgegangen wird. Grundsätzlich habe ich das Thema zwar schon immer beachtet, allerdings etwas unterschätzt – vor meinen Änderungen wurden im Kern von Seeing# pro Schleifendurchlauf locker 50-100 Objekte erzeugt, was bei ca. 60 Frames pro Sekunde 3.000 bis 6.000 Objekte bedeutet, um die sich der Garbage Collector kümmern muss. Und das auch ohne, dass der User irgendetwas macht (z. B. 3D-Kamera bewegen o. Ä.). Hier im Artikel stelle ich einige Anpassungen vor, die ich in den letzten Monaten gemacht habe.