In den letzten Tagen habe ich meinem PC und Tablet auf Windows 10 geupdated. Um mir einen gewissen Überblick aus Sicht der Softwareentwicklung zu machen, war ich letzten Donnerstag bei der .Net Usergroup Nürnberg, wo einige der neuen Möglichkeiten durch Daniel Meixner und Marco Richardson vorgestellt wurden [1]. Seit heute früh spiele ich entsprechend stärker mit Visual Studio rum und versuche, den SampleContainer von Seeing# für die neue “Universal Windows” Plattform zu erstellen. Universal Windows ist hierbei sehr ähnlich den Universal-Projekten von Windows 8 / 8.1, allerdings handelt es sich jetzt nicht mehr um mehrere C#-Projekte mit einem Shared Project, sondern nur noch um ein einziges C#-Projekt, welches dann auf allen Windows Plattformen läuft – das wären dann XBox, IoC, Phone, Tablet, PC und der Surface Hub.
Die Umstellung an sich war aus technischer Sicht relativ einfach, da ich mit dem neuen Template für Windows Universal Apps direkt auf meine bisherigen Projekte mit altem Universal Template verweisen kann. Konkret meine ich die Teilprojekte SeeingSharp, SeeingSharp.Multimedia und SeeingSharp.Samples.Base. Danach einfach die Oberflächen aus dem alten UniversalSampleContainer rüber kopiert und fertig – rein von der Funktion her lief es daher sehr schnell. Problem ist aber, dass die Oberflächen von vorher plötzlich deutlich größer angezeigt werden Warum ist das so?
Wie bei oben genannten Vortrag auch behandelt wurde, werden mit Windows 10 die “Effective Pixels” eingeführt [2]. Hierbei handelt es sich ähnlich wie schon bei den Device-Independent Pixels [3] um ein Skalieren abhängig von der Hardware. Device-Independent Pixel behandeln dabei die im Windows konfigurierte Pixeldichte (DPI), sprich: Werden alle Maße in Device Independent Pixel angegeben (was im Xaml formals Standard war), muss sich der Entwickler nicht selber um die Skalierung kümmern. Im neuen Modell werden anstelle der Device-Independent Pixel alle Maße standardmäßig in Effective Pixel angegeben. Hintergrund ist der, dass neben den DPI auch der typische Abstand des Benutzers zum Bildschirm eingerechnet wird. Eigentlich logisch, denn auf einem großen Fernseher wie dem Surface Hub muss für den Betrachter höher Skaliert werden, als am Smartphone, was relativ nah vor dem Auge des Benutzers ist.
Um die Oberfläche des SampleContainers nun etwas mehr nach dem Stil von Windows 10 zu erstellen, habe ich die Navigationsleiste oben ersetzt durch ein SplitView-Element [4]. Dieses Element wurde auch bei obigen Vortrag vorgestellt und macht grundsätzlich einen guten Job, wenn es darum geht, eine saubere Navigationsleiste auf allen Plattformen zu haben. Das Ergebnis ist am Screenshot ganz oben im Artikel zu sehen.
Im nächsten Schritt wollte ich das Programm noch in den Windows Store hochladen, hierbei habe ich aber noch ein paar kleine Probleme. Die Prüfungen des Store gehen mit Ausnahme der Prüfung auf unterstützte API aufrufen alle sauber durch (Siehe nächsten Screenshot). Mal schauen, im Moment gehe ich davon aus, dass wegen dem DirectX-Zeugs etwas Ungültiges aufgerufen wird. Kann mich erinnern, dass ich beim Start von Windows 8.1 ein Ähnliches Problem hatte. Blöd aktuell ist nur, dass die Fehlermeldungen nur wenig Rückschluss auf den eigenen Code geben, bzw. zumindest habe ich die genannten API-Aufrufe nirgends gefunden.
Davon unabhängig befindet sich der SampleContainer für Windows 10 bereits auf GitHub und kann auch von jedem geladen und ausprobiert werden [5].
Verweise
- http://www.dodnedder.de/treffen/25-windows-10-fuer-entwickler
- https://msdn.microsoft.com/en-us/library/windows/apps/dn958435.aspx
- https://msdn.microsoft.com/en-us/library/windows/desktop/ff684173(v=vs.85).aspx
- http://igrali.com/2015/04/12/getting-started-with-splitview-control-in-universal-apps/
- https://github.com/RolandKoenig/SeeingSharp