Popup-Menus in WP7-Apps

Teil der Benutzeroberfläche von Applikationen für Windows Phone 7 sind bekanntlich Popup-Menus: Etwas nicht nur kurz antippen, sondern lange draufhalten, um das Popup-Menu bzw. Kontext-Menu aufzurufen.

Als App-Programmierer wird man verwiesen auf ein entsprechendes Control, das Teil des Silverlight Toolkits ist, welches in einer Ausgabe für WP7 und einer für das „echte“ Silverlight existiert. Dieses Toolkit hat man nicht „einfach so“ installiert, selbst wenn man die ganzen WP7-Entwicklungs-Tools und SDKs installiert hat, aber mit NuGet ist es schnell und einfach installiert.

Informationen darüber, wie man ein ContextMenu-Control einbaut in seine Applikation, findet man z.B. hier. Bei einer ListBox ist es noch ein wenig tricky herauszufinden, für welches Item das Menu aufgerufen wurde, aber der nötige Trick findet sich z.B. hier.

Wenn Sie nur wie ich vor dem Problem stehen, ein Popup-Menu für Ihre WP7-Applikation zu bauen, können Sie jetzt getrost aufhören zu lesen – es folgt nämlich nur noch mein Kommentar zu dieser Geschichte:

Da gibt es also für ein ureigenstes Feature der WP7-Benutzeroberfläche kein „natives“ Control, welches der App-Programmierer mit aller Selbstverständlichkeit nutzen kann, sondern nur ein Control, das sich wie das eingebaute Control verhält, zumindest so, wie sich das eingebaute momentan unter Mango verhält.

Dieses Control ist zudem enthalten in einem Toolkit, dessen Status nicht so ganz klar ist: Ok, es sind Leute vom Silverlight-Team selbst unter den Programmierern, und auch ein Programmierer namens „Microsoft“ ist dabei. Aber ist das jetzt offiziell? Kann ich mich darauf verlassen, dass das weiter gepflegt wird? Was ist, wenn Microsoft in Zukunft das „eingebaute“ Popup-Menu verbessert – sieht mein Control dann plötzlich „alt“ aus?

Vielleicht bin ich einfach zu kritisch oder zu skeptisch eingestellt, aber wenn ich Dinge lese wie hier zum ToggleSwitch-Control in einem neuen Release des Silverlight Toolkits:

The ToggleSwitch is designed to match the native experience.

dann wundere ich mich doch sehr: Was ist denn mit dem „eingebauten“ Toogle-Switch los, dass man ihn nicht ganz einfach als Teil des WP7 API zur Verfügung stellt? Was ist an dem so gefährlich oder problematisch, dass man in einem Toolkit einen Nachbau anbieten und die Leute beruhigen muss, das sehe dann schon genau so aus wie „echt“?

Ich glaube, die Lösung des Rätsels ist wie folgt, auch wenn ich das nur hier und da im Internet quasi als Gerücht gefunden habe und nicht in der Lage bin, auf ein zuverlässige Quelle zu verlinken: Microsoft habe die native WP7 controls aus Gründen der Performance nicht in Silverlight, sondern direkt in C++ programmiert, und damit wohl mit APIs ausgestattet, die sich nicht für eine komplette Öffnung für alle WP7-Programmierer eignen. Es mag auch eine Rolle spielen, dass gewisse WP7-Standard-Programme, allen voran wahrscheinlich der IE, nicht in C# programmiert sind, sondern in C++, und mit Silverlight-Controls wohl ihre liebe Mühe hätten.

Gut denkbar natürlich, dass die fraglichen Controls in der nächsten Iteration von WP7 in die Standard-API aufgenommen werden und sich ab da Microsoft völlig unsichtbar darum kümmert, die beiden Spielarten der Controls (C++ und C#/Silverlight) synchron zu halten, womit sich dann die Sache wesentlich entschärft.

Veröffentlicht in Allgemein. Schlagwörter: , , . Leave a Comment »

API-Minimalismus

Ich verfolge schon seit geraumer Zeit, was auf dem Gebiet der Smartphone-Betriebssysteme passiert.

Eines der bemerkenswertesten Ereignisse auf diesem Gebiet in letzter Zeit ist für mich die Art, wie Microsoft Windows Phone 7 zum Laufen gekriegt hat: Während Nokia viele Jahre damit verbracht hat, einen Versuch der Symbian-Modernisierung nach dem anderen an die Wand zu fahren, hat Microsoft in der unglaublich kurzen Zeit von etwa anderthalb Jahren ein einigermassen brauchbares Smartphone-OS mit modernem und sogar stellenweise innovativem User Interface aus dem Boden gestampft.

Natürlich ist WP7 bei näherem Hinsehen nicht „neu“: Im Inneren werkelt der immer noch gleiche uralte Windows-CE-Kernel, und die Benutzeroberfläche besteht im wesentlichen aus Silverlight und XNA, beides Systeme, die bereits bestanden und zu Beginn der Arbeiten an WP7 bereits eine ordentliche Reife erlangt hatten. Es ist aber meiner Meinung nach trotzdem eine tolle Leistung, all diese Teile brauchbar zu kombinieren und in kurzer Zeit zur Marktreife zu bringen.

So weit, so gut. Seit einigen Tagen allerdings hat mein Bild von WP7 ein paar Kratzer abbekommen. Ich habe WP7 gewählt, um mich in die WPF/Silverlight/XAML-basierte Welt der .NET-Benutzeroberflächen-Programmierung für „konventionelle“ Applikationen (im Gegensatz zu Web-Applikationen) einzuarbeiten und komme doch ziemlich ernüchtert von ersten Detail-Abklärungen zurück.

Auch Microsoft konnte nicht zaubern, und um WP7 in so kurzer Zeit zu stemmen, musste wohl jemand mit eiserner Hand die Aufgabe auf ein handhabbares Mass reduzieren. Herausgekommen ist ein Smartphone-OS mit einer API, die arg schwach auf der Brust ist.

Am konkreten Beispiel: Was kann ein Programmierer, der eine WP7-App baut, punkto SMS auf dem Gerät alles anstellen?

Kann er sich in den Empfang von SMS einklinken, um z.B. eine SMS-Auto-Responder-App zu bauen? Nein, es gibt keine API hierfür. Kann er eine App bauen, die – Erlaubnis des Smartphone-Besitzers natürlich vorausgesetzt – automatisch SMS versendet, die z.B. Kollegen an nahende Termine erinnern? Nein. Kann er eine App bauen, die es möglich macht, eine früher gesendete SMS abzuändern und jemand anderem ebenfalls zu senden? Oder eine App für den Backup aller SMS? Nein, kann er nicht, die API gewährt keinen Zugriff auf den SMS-Speicher.

Ja, gibt es denn überhaupt irgendwelche Unterstützung im API betreffend SMS? Nun ja, eine WP7-App kann betreffend SMS genau eine Funktion ausführen, eine einzige: Sie kann einen SMS-Text und eine Liste von Empfängern vorbereiten und an den SMS-Erfassungs-View senden, wo dann der Benutzer bei Bedarf noch ändern und die fertige SMS schliesslich senden kann.

Kann die App dann wenigstens in Erfahrung bringen, ob der Benutzer die solchermassen vorbereitete SMS tatsächlich abgeschickt hat? Sie ahnen es wohl schon: Natürlich nicht.

Wer sich nun sagt, halb so wild, SMS ist sowieso auf dem absteigenden Ast: Ganz ähnliche Einschränkungen scheinen auch für E-Mails zu gelten.

Ich komme für mich zum Schluss: Mit einer derart limitierten API ist es extrem schwierig, wirklich interessante und innovative Apps für WP7 zu programmieren. Hier muss sich meiner Meinung nach in kurzer Zeit sehr viel tun, wenn WP7 je zu iOS und Android aufschliessen will.

Veröffentlicht in Allgemein. Schlagwörter: , , . Leave a Comment »

.NET als Nachfolger von Win32

Kürzlich kam mir Petzolds Original-„Hello World“ für Windows in C wieder mal in die Hände. Als ich so am Staunen war über die Schönheit des Win32-API in seiner unverfälschten, puren Form, erinnerte ich mich daran, dass vor nicht allzu langer Zeit ziemlich heftig darüber spekuliert worden ist. Man fragte sich, ob Microsoft .NET nicht nur baut, damit wir Applikationsprogrammierer etwas produktiver werden, sondern um mittelfristig Win32 abzulösen und damit die gesamte Windows-Programmierung auf das nächste Level zu heben: das .NET-Framework als das neue Windows, zumindest was das API angeht.

Das hat meine Neugierde geweckt, und ich habe etwas recherchiert, wie es unterdessen um diese Spekulationen steht.

Per Google findet man relativ leicht heraus, dass der Höhepunkt dieses „Memes“ so um 2003/2004 herum gewesen sein muss, als die Gerüchte ins Kraut schossen, wie wohl das neue Windows Code-Name Longhorn aussehen würde. Von grossen, in .NET implementierten Betriebssystem-Teilen war die Rede. Und in diesem Longhorn FAQ, das offenbar als seriös genommen werden will, findet man folgende Aussage: „In the technology generations leading up to Longhorn, Microsoft has been moving to a .NET-based managed code environment dubbed WinFX, and the Longhorn generation will finally mark a clean split with the Win32 APIs of the past.“

Es ist mir hingegen nicht gelungen, unter Stichworten wie future windows API interessante aktuelle Informationen zu finden. Vielleicht hat ja Microsofts lange und schmerzreiche Schwangerschaft mit Windows Vista zu einer gewissen Ernüchterung geführt, wie schnell man Win32 ablösen könnte und wie gross der Aufwand dafür wirklich wäre.

In einer Diskussion aus dem Jahre 2004 stiess ich noch auf folgendes Argument, das mir heute noch relevant scheint und das ich ganz interessant fand: Microsoft verdient bekanntermassen nur mit 2 Dingen richtig massig Geld, einerseits mit Windows selbst, und andererseits mit Office. Die Office-Programme basieren auf Win32. Wenn also Microsoft mit .NET als Win32-Ablösung wirklich ernst machen will, ohne eine der beiden „cash cows“ zu verlieren, müsste sie einen kompletten Rewrite der Office-Programme ins Auge fassen. Von einem solchen ist nichts bekannt.

Aber wie dem auch sei, ob nun Microsoft etwas zu hoch gezielt hat ursprünglich oder nicht, gedeiht das .NET-Framework prächtig, und es kommt wohl kaum mehr jemandem in den Sinn, ein normales Applikationsprogramm auf Win32 aufzusetzen.

Dass das Framework unterdessen durchaus das Zeug hätte, als Windows-Programmieroberfläche zu fungieren, sieht man übrigens an der PowerShell, die ja mit Hilfe von .NET implementiert worden ist.

Zu guter letzt noch ein paar Links: ein Artikel von Joel Spolsky aus dem Jahre 2004 (immer noch lesenswert, falls man ihn nicht schon kennt), und die Website The Old New Thing mit manchmal geradezu abenteuerlichen Geschichten über die Entstehung gewisser Dinge rund um Win32, etwa diese Story mit dem Titel What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?.

Veröffentlicht in Keine Kategorie. Schlagwörter: , , . Leave a Comment »