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.
Blog
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.
Worklog SeeingSharp 2: Start
Für das Projekt Seeing# habe ich bereits sehr viele Stunden investiert. Begonnen mit dem 3D-Rendering ist das Framework über die Jahre sehr in die Breite gewachsen, etwa mit der Unterstützung für Video mit der Media Foundation oder einfachen Funktionen zur Wiedergabe von Musik und kurzen Sounds. Zudem habe ich öfters allgemeine Infrastruktur-Themen wie einen kleinen DI-Container, Übersetzungsfunktionen, etc. integriert. Der ursprüngliche Fokus auf 3D-Rendering ist dabei zum Teil stark verwässert. Aus diesem und anderen Gründen (siehe unten) habe ich mich dazu entschieden, einen größeren Breaking-Change zu machen und die Library grundsätzlich zu überarbeiten. Das Projekt befindet sich auf Github im Repository: https://github.com/RolandKoenig/SeeingSharp2. Bis Seeing# 2 aber die gleiche Funktionalität wie vorher Seeing# bietet, ziehen noch einige Wochen ins Land.
Automatisierte Tests mit Windows.Forms UI
Vor kurzem wurde ich auf einen kleinen aber blöden Fehler in Seeing# hingewiesen. Die Rendering-Hauptschleife ist abgebrochen, sobald man ein Windows.Forms Control von einem Parent ab und an einen anderen angehängt hat. Jetzt klingt das nach einem sehr seltenen Fall, aber auch diesen hätte ich ein paar Jahre zuvor explizit behandelt – allerdings im Rahmen eines Windows.Forms Programms. Im Laufe der Zeit ist dieser Fehler wieder in den Code gewandert, ohne dass er wirklich auffällt. Wer testet sowas auch immer wieder? Aus diesem Grund habe ich versucht, diesen Fall per Testautomatisierung zu behandeln, um so automatisch genau diesen Fall immer wieder abprüfen zu lassen.