DrWindows
Redaktion
Kommentar: Microsoft und seine Tutorials zum Flüchten
von Tobias Scholze
Ich liebe es zu lernen. Ich liebe es, mich im beruflichen als auch privaten weiterzuentwickeln und neue Dinge kennenzulernen und einiges davon auch auszuprobieren. Hiermit meine ich nicht nur die Kunst des Brotbacken,s was manche von uns sich in den letzten Jahren angeeignet haben, sondern auch Experimente im Digitalen wie etwa mit den neuen Windows 11 Widgets. Doch dies kann schnell steinig werden und demotivierend sein.
Viele der erwähnten Punkte können oder müssen nicht ein Fehler, Versäumnis oder gar Ignoranz von Microsoft sein. Viele der Punkte können für erfahrene Entwickler aus diesem Ökosystem selbsterklärend und einleuchtender beschrieben sein, als wie ich es erfahren habe. Dieser Beitrag ist soll weder Hass erzeugen, noch ein „Auslachen“ sein, sondern ein konstruktiver Beitrag, um Windows 11 Widgets für Entwickler zugänglich zu machen.
Als Windows 11 vor nicht allzu langer Zeit gestartet wurde, war die Widgetleiste einer der Punkte, bei der wir bei Dr. Windows dachten, dass dies ideal sei, um unsere Leser bequem und auch noch hübsch dargestellt über neue Artikel von uns zu informieren. Eine solche Leiste gab es zwar schon bei Vista und Co., so richtig durchgesetzt hat es sich damals aber wohl nicht.
Außerdem, so war meine Vermutung, hat Microsoft sicherlich Interesse daran, dieses neue Windows 11-Feature zu bewerben und allen interessierten Entwicklern schmackhaft zu machen.
Bis vor wenigen Tagen war es nicht möglich, eigene Widgets zu entwerfen, doch mit der Veröffentlichung des Windows App SDK in Version 1.2 Preview 2 öffnete Microsoft (Dr. Windows berichtete) nun die Scheunentore, um die Horde an Entwicklern hereinzulassen! Oder waren doch nur wallende Strohballen zu hören?
Ich möchte euch meine persönlichen Stolpersteine aufzeigen und erklären, wieso sie für mich im Endeffekt zum Scheitern dieser Bastelei geführt haben. Falls ihr Tipps und Tricks habt, wie man diese Steine aus dem Weg schaffen kann, bitte ich euch, diese in den Kommentaren zu vermerken.
Das Tutorial zählt auf, welche exakten Versionen, wobei dies wohl eher Mindestversionen sind, interessierte Entwickler von Windows 11 (Dev Channel) und des Widget Boards (521.20060.1205.0) installieren müssen. Microsoft erwähnt explizit, dass all das Erklärte als auch eventuell die Beispielsquelltexte mit einem Update kaputt gehen können, da es sich noch alles um Software und Bibliotheken im Beta- oder Alpha-Stadium handelt.
Some information relates to pre-released product, which may be substantially modified before it’s commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Ist es also noch zu früh, um sich mit dieser Thematik überhaupt zu beschäftigen? Falls ja, liegt die „Schuld“ als bei mir selbst.
Da das Thema „Widget“ unter „Windows App Development“ auf learn.microsoft.com aufgeführt ist, hat es sich auch dort an die starre Sektionsstruktur zu halten. Sprich: Es gibt beispielsweise die Reiter „Getting Started“, „Design“, „Development“ und „Deploy“. Auf das Feature der Plattform, Beiträge auf Deutsch zu lesen, verzichte ich absichtlich, da diese automatische Übersetzung noch mehr zur Verwirrung beiträgt.
Leider ist im ersten und vielleicht auch wichtigsten Kapitel „Getting Started“ nichts von Widgets zu lesen, auch unter Design/Windows 11 ist davon keine Rede, sondern haben dort ihre eigene Gruppe „Windows Widgets“, auch wenn es diese nur unter Windows 11 gibt. Wobei hier der Beitrag erst mit einem „Getting started“ zu Widgets anfängt, welcher eigentlich zum großen „Getting started“ Reiter passen würde.
Das Ganze ist wenig verwirrend, wenn man die Struktur einmal begriffen hat. Etwas anderes ist es, wenn man sich einen ersten Überblick über das Windows 11-Feature verschaffen will und erst einmal wie der Ochse vor dem Berg steht, weil man den Anfang vom roten Faden nicht findet.
Für einen Einsteigerkurs in die ganze Thematik geht es bei diesen Beiträgen auch zu sehr in technische Details, welche mich zu diesem Zeitpunkt des Lernprozesses erst einmal eher abgeschreckt als motiviert haben. So blieb mir beispielsweise bis zum Schluss verborgen, was nun der Unterschied zwischen Widgets und den von Microsoft longierten Adaptive Cards sind.
Microsoft verwendet gerne den generischen Begriff eines „Widgets“. Es gibt sie in Teams, im Bot Framework, bei Cortana (RIP) und unter anderem auch in Microsoft Viva. Hier nun bei Suchen im Netz aber auch bei Beispielen die gewollten Informationen zu finden, kann ermüdend sein.
Ein Schritt in der Erstellung eines Windows 11 Widgets ist die Gestaltung der Oberfläche. Hierzu wird das gleiche Format benutzt wie auch für andere „Adaptive Cards“, und Microsoft hat hierfür die Webapp „Adaptive Cards Designer“ ins Leben gerufen.
Da der Designer alle erwähnten Arten von Widgets aka (?) Adaptive Cards unterstützt, sollte man doppelt prüfen, ob man auch das richtige Target Framework ausgewählt hat, bevor man mit der Gestaltung beginnt – da zu mindestens bei mir ein späteres Wechseln des Targets zu einem Einfrieren des Designers führte.
Des Weiteren hat bei mir der vom Designer erzeugte Code im Designer selbst zu einer Fehlermeldung während der Validierung gesorgt. Ob dies mit dem vorher erwähnten Schluckauf zusammenhängt oder ob es ein realer Fehler, ist kann ich hier nicht sagen.
Nachdem das Widget, also die Oberfläche, entworfen ist, muss die dazugehörige Logik entwickelt werden, in unserem Falle für Windows 11 ein so genannter „Widget Provider“. Dies ist eine Applikation, welche das Widget mit Leben und Daten befüllt. Bisher werden hier nur „Win32“-Konsolenprogramme unterstützt.
Von dem „damaligen“ Ausspruch, dass PWAs ein First-Citizen sind, hat sich Microsoft scheinbar wieder verabschiedet – muss ja nicht verkehrt sein. Diese Möglichkeit, die Logik zu gestalten, soll später nachgereicht werden.
Was mich mehr abschreckte, war, dass das offizielle Beispiel nicht, wie sonst von Microsoft üblich und im .NET-Ökosystem mittlerweile Usus, in C# vorliegt, sondern in C++. Da viele UWP- und App-Entwickler eher einen C#- oder auch mittlerweile TypeScript-Hintergrund haben, irritiert mich diese Wahl der Programmiersprache doch etwas.
Die Anleitung führt gut strukturiert durch den Prozess und dessen Life Cycles, eines eigenen Widget Provider zu entwickeln, aber durch die Verwendung von C++ lässt sich nicht alles gleich übertragen und auch noch verstehen, was eigentlich gerade passiert – vor allem im Sinne von Header Files.
Ein Link zum Beispiel auf GitHub scheint ebenso zu fehlen, so dass man auch keine „Vorlage“ hat, um zu mindestens einen Garant für ein lauffähiges Projekt zu haben.
Persönlich bin ich nicht so weit gekommen, aber für alle fähigeren Menschen stellt sich nach der Entwicklung die Frage, wie man nun das erstelle Widget deployed – also veröffentlicht. Diese Information gibt es nicht unter dem Reiter „Deploy“, sondern ist Teil der „Develop“-Sektion. Wohl deswegen, weil es aller anscheinen nach noch kein „Hit run and build“-Button in Visual Studio für Widgets gibt.
Dass es hier zum Deployen noch sehr viel Handarbeit in der Form von zu aktualisierenden *.wapproj und *.appxmanifest Dateien gibt, schiebe ich dem aktuellen Beta- beziehungsweise Alpha-Status zu und hoffe, dass bis zum produktiven Release dies alles in Visual Studio möglich sein wird.
Ich als Entwickler, welcher wieder zurück zu seinen Windows-Ökosystemwurzeln möchte, hätte erwartet, dass es einen einfach zu folgenden Leitfaden gibt, wo Schritt für Schritt erklärt wird, was man zum jeweiligen Zeitpunkt wo, wie und warum machen muss, um am Ende ein fertiges Widget zu haben. Dies in C# und etwaig auch in allen anderen Sprachen mit welchen win32-Anwendungen erzeugt werden können.
Dies, gepaart mit Beispielen auf GitHub aus der echten Welt wie eben einem RSS-Reader, hätten mich eventuell nicht so schnell die Flinte in das Korn werfen lassen. Dass so etwas möglich ist, zeigt Google an etlichen Stellen mit den Android-Beispielen.
Wie erwähnt, hat Microsoft bis zum produktiven Release der Widgets noch etwas Zeit. So kann es gut sein, dass nicht nur das SDK im Alpha-Status ist, sondern auch das ganze dazugehörige Lernmaterial. Es schadet also nicht, in regelmäßigen Abständen auf learn.microsoft.com vorbei zu schauen, denn, die Hoffnung auf gute Anleitungen seitens Microsoft stirbt bekanntlich zuletzt!
Auch wenn unser Fallbeispiel klassisch auf Microsoft abzielte, ist der Softwaregigant aus Redmond mitnichten allein. Im vergangenen Monat beschäftigte ich mich ausgiebig mit JetBrains Space App Extensions, um an deren App Contest teilzunehmen. Die hierfür vorhandenen Tutorials, welche mir als Einsteiger an die Hand gelegt wurden, sorgten nicht nur einmal dafür, dass ich diese Bastelei an den Nagel gehängt hätte, und entfernten und frustrierten mich von der ganzen Idee, JetBrains Space, eine Mischung aus Azure Dev Ops und Teams, eine Chance zu geben.
Auch Apple, Salesforce und Co. können nicht immer mit ihren Anleitungen brillieren – somit ist dies wohl eher ein Branchenproblem, statt ein Nur-Microsoft-Problem.
Hinweis: Der Artikel wird möglicherweise nicht vollständig angezeigt, eingebettete Medien sind in dieser Vorschau beispielsweise nicht zu sehen.
Artikel im Blog lesen
von Tobias Scholze
Ich liebe es zu lernen. Ich liebe es, mich im beruflichen als auch privaten weiterzuentwickeln und neue Dinge kennenzulernen und einiges davon auch auszuprobieren. Hiermit meine ich nicht nur die Kunst des Brotbacken,s was manche von uns sich in den letzten Jahren angeeignet haben, sondern auch Experimente im Digitalen wie etwa mit den neuen Windows 11 Widgets. Doch dies kann schnell steinig werden und demotivierend sein.
Klarstellung
Viele der erwähnten Punkte können oder müssen nicht ein Fehler, Versäumnis oder gar Ignoranz von Microsoft sein. Viele der Punkte können für erfahrene Entwickler aus diesem Ökosystem selbsterklärend und einleuchtender beschrieben sein, als wie ich es erfahren habe. Dieser Beitrag ist soll weder Hass erzeugen, noch ein „Auslachen“ sein, sondern ein konstruktiver Beitrag, um Windows 11 Widgets für Entwickler zugänglich zu machen.
Fallbeispiel: Windows 11 Widgets
Als Windows 11 vor nicht allzu langer Zeit gestartet wurde, war die Widgetleiste einer der Punkte, bei der wir bei Dr. Windows dachten, dass dies ideal sei, um unsere Leser bequem und auch noch hübsch dargestellt über neue Artikel von uns zu informieren. Eine solche Leiste gab es zwar schon bei Vista und Co., so richtig durchgesetzt hat es sich damals aber wohl nicht.
Außerdem, so war meine Vermutung, hat Microsoft sicherlich Interesse daran, dieses neue Windows 11-Feature zu bewerben und allen interessierten Entwicklern schmackhaft zu machen.
Bis vor wenigen Tagen war es nicht möglich, eigene Widgets zu entwerfen, doch mit der Veröffentlichung des Windows App SDK in Version 1.2 Preview 2 öffnete Microsoft (Dr. Windows berichtete) nun die Scheunentore, um die Horde an Entwicklern hereinzulassen! Oder waren doch nur wallende Strohballen zu hören?
Meine Stolpersteine
Ich möchte euch meine persönlichen Stolpersteine aufzeigen und erklären, wieso sie für mich im Endeffekt zum Scheitern dieser Bastelei geführt haben. Falls ihr Tipps und Tricks habt, wie man diese Steine aus dem Weg schaffen kann, bitte ich euch, diese in den Kommentaren zu vermerken.
Alles noch in der Mache
Das Tutorial zählt auf, welche exakten Versionen, wobei dies wohl eher Mindestversionen sind, interessierte Entwickler von Windows 11 (Dev Channel) und des Widget Boards (521.20060.1205.0) installieren müssen. Microsoft erwähnt explizit, dass all das Erklärte als auch eventuell die Beispielsquelltexte mit einem Update kaputt gehen können, da es sich noch alles um Software und Bibliotheken im Beta- oder Alpha-Stadium handelt.
Some information relates to pre-released product, which may be substantially modified before it’s commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Ist es also noch zu früh, um sich mit dieser Thematik überhaupt zu beschäftigen? Falls ja, liegt die „Schuld“ als bei mir selbst.
Keine zusammenhängende Einführung
Da das Thema „Widget“ unter „Windows App Development“ auf learn.microsoft.com aufgeführt ist, hat es sich auch dort an die starre Sektionsstruktur zu halten. Sprich: Es gibt beispielsweise die Reiter „Getting Started“, „Design“, „Development“ und „Deploy“. Auf das Feature der Plattform, Beiträge auf Deutsch zu lesen, verzichte ich absichtlich, da diese automatische Übersetzung noch mehr zur Verwirrung beiträgt.
Leider ist im ersten und vielleicht auch wichtigsten Kapitel „Getting Started“ nichts von Widgets zu lesen, auch unter Design/Windows 11 ist davon keine Rede, sondern haben dort ihre eigene Gruppe „Windows Widgets“, auch wenn es diese nur unter Windows 11 gibt. Wobei hier der Beitrag erst mit einem „Getting started“ zu Widgets anfängt, welcher eigentlich zum großen „Getting started“ Reiter passen würde.
Das Ganze ist wenig verwirrend, wenn man die Struktur einmal begriffen hat. Etwas anderes ist es, wenn man sich einen ersten Überblick über das Windows 11-Feature verschaffen will und erst einmal wie der Ochse vor dem Berg steht, weil man den Anfang vom roten Faden nicht findet.
Für einen Einsteigerkurs in die ganze Thematik geht es bei diesen Beiträgen auch zu sehr in technische Details, welche mich zu diesem Zeitpunkt des Lernprozesses erst einmal eher abgeschreckt als motiviert haben. So blieb mir beispielsweise bis zum Schluss verborgen, was nun der Unterschied zwischen Widgets und den von Microsoft longierten Adaptive Cards sind.
Doppelt vergebene Namen-Bingo
Microsoft verwendet gerne den generischen Begriff eines „Widgets“. Es gibt sie in Teams, im Bot Framework, bei Cortana (RIP) und unter anderem auch in Microsoft Viva. Hier nun bei Suchen im Netz aber auch bei Beispielen die gewollten Informationen zu finden, kann ermüdend sein.
Adaptive Cards Designer erzeugt fehlerhaften Code
Ein Schritt in der Erstellung eines Windows 11 Widgets ist die Gestaltung der Oberfläche. Hierzu wird das gleiche Format benutzt wie auch für andere „Adaptive Cards“, und Microsoft hat hierfür die Webapp „Adaptive Cards Designer“ ins Leben gerufen.
Da der Designer alle erwähnten Arten von Widgets aka (?) Adaptive Cards unterstützt, sollte man doppelt prüfen, ob man auch das richtige Target Framework ausgewählt hat, bevor man mit der Gestaltung beginnt – da zu mindestens bei mir ein späteres Wechseln des Targets zu einem Einfrieren des Designers führte.
Des Weiteren hat bei mir der vom Designer erzeugte Code im Designer selbst zu einer Fehlermeldung während der Validierung gesorgt. Ob dies mit dem vorher erwähnten Schluckauf zusammenhängt oder ob es ein realer Fehler, ist kann ich hier nicht sagen.
Noch keine Progressive Web App-Unterbauten möglich
Nachdem das Widget, also die Oberfläche, entworfen ist, muss die dazugehörige Logik entwickelt werden, in unserem Falle für Windows 11 ein so genannter „Widget Provider“. Dies ist eine Applikation, welche das Widget mit Leben und Daten befüllt. Bisher werden hier nur „Win32“-Konsolenprogramme unterstützt.
Von dem „damaligen“ Ausspruch, dass PWAs ein First-Citizen sind, hat sich Microsoft scheinbar wieder verabschiedet – muss ja nicht verkehrt sein. Diese Möglichkeit, die Logik zu gestalten, soll später nachgereicht werden.
C++ statt C# – sorgt für Kopfschmerzen
Was mich mehr abschreckte, war, dass das offizielle Beispiel nicht, wie sonst von Microsoft üblich und im .NET-Ökosystem mittlerweile Usus, in C# vorliegt, sondern in C++. Da viele UWP- und App-Entwickler eher einen C#- oder auch mittlerweile TypeScript-Hintergrund haben, irritiert mich diese Wahl der Programmiersprache doch etwas.
Die Anleitung führt gut strukturiert durch den Prozess und dessen Life Cycles, eines eigenen Widget Provider zu entwickeln, aber durch die Verwendung von C++ lässt sich nicht alles gleich übertragen und auch noch verstehen, was eigentlich gerade passiert – vor allem im Sinne von Header Files.
Ein Link zum Beispiel auf GitHub scheint ebenso zu fehlen, so dass man auch keine „Vorlage“ hat, um zu mindestens einen Garant für ein lauffähiges Projekt zu haben.
Wer Deploy sucht, muss in Develop suchen
Persönlich bin ich nicht so weit gekommen, aber für alle fähigeren Menschen stellt sich nach der Entwicklung die Frage, wie man nun das erstelle Widget deployed – also veröffentlicht. Diese Information gibt es nicht unter dem Reiter „Deploy“, sondern ist Teil der „Develop“-Sektion. Wohl deswegen, weil es aller anscheinen nach noch kein „Hit run and build“-Button in Visual Studio für Widgets gibt.
Dass es hier zum Deployen noch sehr viel Handarbeit in der Form von zu aktualisierenden *.wapproj und *.appxmanifest Dateien gibt, schiebe ich dem aktuellen Beta- beziehungsweise Alpha-Status zu und hoffe, dass bis zum produktiven Release dies alles in Visual Studio möglich sein wird.
Was hätte ich erwartet?
Ich als Entwickler, welcher wieder zurück zu seinen Windows-Ökosystemwurzeln möchte, hätte erwartet, dass es einen einfach zu folgenden Leitfaden gibt, wo Schritt für Schritt erklärt wird, was man zum jeweiligen Zeitpunkt wo, wie und warum machen muss, um am Ende ein fertiges Widget zu haben. Dies in C# und etwaig auch in allen anderen Sprachen mit welchen win32-Anwendungen erzeugt werden können.
Dies, gepaart mit Beispielen auf GitHub aus der echten Welt wie eben einem RSS-Reader, hätten mich eventuell nicht so schnell die Flinte in das Korn werfen lassen. Dass so etwas möglich ist, zeigt Google an etlichen Stellen mit den Android-Beispielen.
Es ist noch Zeit
Wie erwähnt, hat Microsoft bis zum produktiven Release der Widgets noch etwas Zeit. So kann es gut sein, dass nicht nur das SDK im Alpha-Status ist, sondern auch das ganze dazugehörige Lernmaterial. Es schadet also nicht, in regelmäßigen Abständen auf learn.microsoft.com vorbei zu schauen, denn, die Hoffnung auf gute Anleitungen seitens Microsoft stirbt bekanntlich zuletzt!
Microsoft ist nicht allein
Auch wenn unser Fallbeispiel klassisch auf Microsoft abzielte, ist der Softwaregigant aus Redmond mitnichten allein. Im vergangenen Monat beschäftigte ich mich ausgiebig mit JetBrains Space App Extensions, um an deren App Contest teilzunehmen. Die hierfür vorhandenen Tutorials, welche mir als Einsteiger an die Hand gelegt wurden, sorgten nicht nur einmal dafür, dass ich diese Bastelei an den Nagel gehängt hätte, und entfernten und frustrierten mich von der ganzen Idee, JetBrains Space, eine Mischung aus Azure Dev Ops und Teams, eine Chance zu geben.
Auch Apple, Salesforce und Co. können nicht immer mit ihren Anleitungen brillieren – somit ist dies wohl eher ein Branchenproblem, statt ein Nur-Microsoft-Problem.
Hinweis: Der Artikel wird möglicherweise nicht vollständig angezeigt, eingebettete Medien sind in dieser Vorschau beispielsweise nicht zu sehen.
Artikel im Blog lesen
