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…
Blog
PropertyGrid mit Avalonia
Leider beinhaltet Avalonia selbst kein PropertyGrid. Eine kleine, eigene Implementierung ist aber zum Glück auch nicht so aufwändig wie es zunächst klingt. In meinem OpenSource-Projekt MessageCommunicator [1] bin ich genau diesen Weg gegangen. Die umgesetzten Funktionen sind zwar stark von den Anforderungen von MessageCommunicator getrieben, sie sollten aber in Bezug auf das PropertyGrid allgemeingültig verwendbar sein. Elemente wie TextBoxen für String-Properties, Eingabevalidierung und Gruppen-Überschriften werden schließlich auch von anderen Applikationen benötigt. Gerne kann meine Implementierung des PropertyGrid auch als Vorlage für andere Projekte oder ggf. einem eigenen OpenSource-Projekt speziell für das PropertyGrid vergleichbar zu PropertyTools [2] dienen.
Cross-Plattform GUI mit C# und Avalonia
Es existieren einige Ansätze, um mit C# gleichzeitig für mehrere Plattformen eine GUI zu entwickeln. Xamarin.Forms etwa ist hier ein sehr bekanntes Beispiel. Etwas unbekannter ist das Framework Avalonia [1]. Hierbei handelt es sich ebenfalls um ein Framework, bei dem die Oberflächen mit Xaml beschrieben und mittels des MVVM-Patterns mit der C#-Logik gekoppelt werden können. Anders als Xamarin.Forms setzt Avalonia auf einen komplett eigenen Rendering-Stack und nicht auf die Standard-Steuerelemente des jeweiligen Betriebssystems. Dadurch ist Optik und Verhalten der Applikationen auf allen Plattformen maximal gleich. Ich persönlich finde diesen Ansatz schon länger sehr spannend und habe mich in den letzten Monaten mehr mit Avalonia beschäftigt. Um für das Framework ein Gefühlt zu bekommen, habe ich eine kleine Applikation zum Senden/Empfangen von TCP/IP-Nachrichten damit gebaut [2]. Das Vorschaubild dieses Artikels ist ein Screenshot dieser Applikation.
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.
Worklog SeeingSharp 2: Rolle rückwärts
Eineinhalb Jahre ist es nun her, als ich mit Seeing# 2 begonnen habe. Mit einigen Pausen-Zeiten dazwischen hat sich in der Zwischenzeit einiges verändert. Damals habe ich mir zum Ziel gesetzt, die Abhängigkeit auf SharpDX nicht mehr zu verschleiern und damit dem Nutzer von Seeing# mehr Flexibilität zu geben. Heute ist es aber leider so, dass SharpDX nicht mehr weiterentwickelt wird [1] und somit früher oder später durch eine andere Alternative ersetzt werden muss. Aus diesem Grund habe ich mich hier für einen Mittelweg entschieden.
Worklog SeeingSharp 2: Nugetpakete erstellen und veröffentlichen
Bei Seeing# ist es langsam so weit, dass ich die ersten Nuget-Pakete hochladen möchte. Früher im alten Seeing#-Projekt habe ich dazu noch eine separate VisualStudio-Erweiterung verwendet. Im neuen .csproj-Format ist nun die Möglichkeit eingeführt worden, dass man standardmäßig direkt aus dem CSharp-Projekt heraus auch die Nuget-Pakete erstellen kann. Genau dieses Features wollte ich hier auch direkt ausprobieren. Insgesamt hat das auch recht gut funktioniert, mit Ausnahme der Projekte für die Universal Windows Platform (UWP), doch näheres dazu unten im Artikel.
Mit Null umgehen
Durch den Artikel „Result-Pattern statt Exceptions“ im Windows Developer Magazin [1] bin ich auf die Library Functional Extensions for C# [2] gestoßen. Zunächst fand ich das Result-Pattern auch als sehr interessanten Weg, mit verschiedenen erwarteten Fehlern umzugehen und wollte das direkt mal ausprobieren. Die verwiesene Library macht aber einiges mehr, für mich primär interessant ist das Problem mit den Null-Referenzen.
ASP.Net Core mit OpenUI5 – DataBinding
In diesem zweiten Artikel zum Thema ASP.Net Core mit OpenUI5 gehe ich im Gegenteil zum letzten Artikel wieder einen Schritt zurück. Es geht hier erstmal um die Erstellung einer Seite mit Eingabe- und Ausgabefeldern – Im Beispiel in Form einer Konfigurationsseite. Für mich interessant an der Stelle ist das DataBinding von OpenUI5 und der Umgang mit den Datentypen von .Net. Strings und Zahlen sind ja i. d. R. kein Problem, interessanter wird es bei Enums oder Zeitstempel.
ASP.Net Core mit OpenUI5 – OData V4 Model
Es klingt schon nach einer sehr seltsamen Mischung, die aktuellste Version von ASP.Net Core mit OpenUI5 zu kombinieren. Doch genau mit dem Thema möchte ich mich momentan intensiver beschäftigen. Für diejenigen, die es nicht kennen: OpenUI5 ist die OpenSource-Variante des Frameworks SAPUI5. Es handelt sich dabei um ein JavaScript-Framework zur Erstellung von Business-Anwendungen primär für den Einsatz zusammen mit einem SAP-System. OpenUI5 enthält einen Großteil des Funktionsumfangs von SAPUI5, steht dagegen aber frei zur Verfügung.