WP7 DatePicker Control ohne Eingabefeld verwenden

Im Silverlight Toolkit für Windows Phone 7 gibt es ein recht hübsches Control für die Eingabe eines Datums, das DatePicker Control. Es besteht aus der Kombination einer Textbox, welche das aktuell gültige bzw. gewählte Datum anzeigt, und einer eigenen vollen Seite, auf der man das Datum „touch-gerecht“ eingeben kann; man errreicht diese Eingabeseite, in dem man die Textbox antippt. Einen Überblick über die Verwendung des Controls in einem Programm gibt es z.B. hier.

Ich wollte das Control etwas anders verwenden, ohne Textbox als Eingabefeld: Die Eingabeseite sollte auf ein Menukommando hin erscheinen, und das gewählte Datum zum Text in einer Textbox hinzugefügt werden.

Ein solches Anwendungsszenario ist von den Machern des Controls nicht vorgesehen, aber mit ein bisschen Tricksen geht es doch:

Um das Control programmatisch auszulösen und auf die Eingabeseite zu gelangen, muss man das Antippen der Textbox simulieren. Das geht, indem man eine eigene Klasse von DatePicker ableitet, damit man an einen Button herankommt, der ein Kind der Textbox ist, und diesen Button per Code „drückt“:

  public class CustomDatePicker : DatePicker {
    public void ClickTemplateButton() {
      Button button = (GetTemplateChild("DateTimeButton") as Button);
      ButtonAutomationPeer peer = new ButtonAutomationPeer(button);
      IInvokeProvider provider = (peer.GetPattern(PatternInterface.Invoke) as IInvokeProvider);
      provider.Invoke();
    }
  } 

Gefunden hatte ich diesen Trick auf einer Website namens wp7-developer.com, aber diese ist offenbar einem Besitzerwechsel zum Opfer gefallen. Interessanterweise behaupten die Antworten zu dieser Frage auf Stack Overflow, es gäbe keine solche Möglichkeit.

Beim API-Minimalismus, der allgemein bei WP7 herrscht, habe ich mich übrigens gewundert, dass es eine Klasse wie ButtonAutomationPeer überhaupt gibt. Vielleicht hat ja bei der Implementation von Silverlight für WP7 nur jemand vergessen, diese Klasse zu löschen…

Auf der Eingabeseite gibt es 2 Buttons, einen, um das Datum zu akzeptieren, und einen, um die Wahl zu verwerfen. Normalerweise führt das Control selbständig seine Value-Property nach oder eben nicht, je nach dem, wie der Benutzer die Eingabeseite verlässt, und man muss im Programm nichts davon wissen.

In meinem Nicht-Standard-Anwendungsfall sieht das allerdings etwas anders aus: Bei Eingabe akzeptiert soll der Datumstext eingefügt werden, bei Eingabe verworfen nicht. Wie kriegt man das hin? Eine erste Suche nach einer Property, welche direkt aussagt, wie die Eingabe endete, war erfolglos.

Das DatePicker-Control bietet den üblichen ValueChanged-Event an, an den man sich hängen kann, um mitzubekommen, wenn der Wert ändert. Das Problem: Wenn der Wert nicht ändert, dann auch kein ValueChanged, selbst wenn der Benutzer die Eingabe bestätigt. Der Effekt bei Verwendung dieses Events ist darum, dass eine Eingabe des voreingestellten Datums nicht möglich ist.

Es gibt allerdings eine ganz einfache Lösung: DatePicker.Value ist nullable. Setzt man die Property auf null vor Aufruf des Controls, ist hinterher die Property gesetzt, wenn der Anwender bestätigte, und immer noch null, wenn er die Eingabe abbrach.

Die Implementation des Controls als eigene Seite mit einem Verhalten, das einem Popup entspricht, hat übrigens einige ganz interessante Aspekte, welche hier näher erläutert werden.

Advertisements
Veröffentlicht in Allgemein. Schlagwörter: , . 5 Comments »

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 »

Schweizer TechDays 2010

1 Jahr nach diesem Eintrag ist es Zeit, über die TechDays 2010 zu berichten.

Sie fanden dieses Mal im Congress Center Basel statt – einem Gebäude, das sich hervorragend eignet für solche Veranstaltungen. Wiederum bekam man in 2 Tagen auf einer sehr professionell organisierten Veranstaltung eine Menge Information mit auf den Weg, woran Microsoft im Moment arbeitet und wie die Firma die Prioritäten legt.

Eine ganz grosse Produkteinführung wie letztes Jahr mit Windows 7 stand dieses Jahr nicht an, aber Silverlight 4 und Visual Studio 2010 stehen vor der Tür und waren dementsprechend wichtige Themen.

Ich finde es recht eindrücklich, was Microsoft mit Silverlight in kurzer Zeit hochzieht – es jagt ja mehr oder weniger eine Version die nächste – aber meiner Meinung nach ist noch ziemlich offen, wie verbreitet es zum Einsatz kommen wird. In der freien „Wildbahn“ des Internet hat es in Flash einen starken, bewährten und auf einer unglaublichen Menge von PCs installierten Konkurrenten, und in einem Firmenumfeld, z.B. in Intranets, sehe ich nicht unbedingt den grossen Vorteil von Silverlight-Applikationen gegenüber konventionellen .NET-Applikationen, die ganz „normal“ auf den PCs laufen.

Und ja, es war wieder da, wie schon letztes Jahr, jenes absolut surreale Gefühl, wenn neue Fähigkeiten von Silverlight 4 „out of browser“ präsentiert werden: Wow, eine Silverlight-Applikation kann jetzt drucken. Ja, sogar Output auf mehrere Seiten verteilen, mit brauchbarem Seitenumbruch. Eine Silverlight-Applikation kann jetzt Rechtsklick-Kontextmenus haben. Nun ja, wenn ich richtig aufgepasst habe zwar jeweils nicht ein echtes Menu Control, sondern nur eine Listbox, die auf Rechtsklick kommt und dann in etwa aussieht wie ein Kontextmenu, aber hey, wir wollen nicht pingelig sein.

Und dann der Hammer: Man kann das Fenster einer Silverlight-Applikation jetzt stylen, wenn sie „out of browser“ läuft. Ja, wer will, kann z.B. den Titelbalken weglassen. Sogar auf die Grösse, in der das Fenster geöffnet wird, kann die Applikation jetzt Einfluss nehmen. Starkes Stück.

Windows Azure, die Microsoft’sche „Wolke“, war ebenfalls ein interessantes Thema. Ich denke, man wird das über ein paar Generationen hinweg reifen lassen müssen, und der grosse Hype in Sachen Clouds muss wohl auch noch zuerst abklingen, bevor man in Ruhe ernsthaft mit solchen Systemen arbeiten kann, aber ich habe schon den Verdacht, dass in ein paar Jahren Systeme wie Windows Azure in der IT absolut akzeptiert sein werden als eine Möglichkeit, Applikationen zu bauen und zu betreiben.

Microsoft scheint mir recht gut positioniert, um hier in Zukunft gross mitzumischen. Schliesslich stellt auch nicht jeder mal eben schnell ein paar Rechenzentren auf jeden Kontinent, eine gewisse Firmengrösse muss da schon sein.

Zum ersten Mal in der Schweiz wurde an diesen TechDays Windows Phone 7 vorgestellt. Das könnte eine ausgesprochen spannende Aufholjagd werden mit einem Mitbewerber, der buchstäblich Jahre Vorsprung hat und auch nicht gerade langsam unterwegs ist. Man munkelt, es sei nur etwas über 1 Jahr her, seit man sich bei Microsoft eingestand, dass man mit Windows Mobile 6.x auf einem toten Pferd sitzt und endlich umsatteln sollte. Was in dieser kurzen Zeit auf die Beine gestellt wurde, sieht für mich recht gut aus.

Und dann gab es noch die Frage: Do you poken?. Am Anfang der TechDays bekam jeder ein Poken, ein kleines Gerätchen für den Austausch von Kontaktinformationen zwischen Teilnehmern (Wikipedia-Artikel ist hier.) Für mich eine Lösung auf der verzweifelten Suche nach einem Problem, ein Ding wie aus den besten Hoch-Zeiten der New Economy – man glaubt förmlich die Hitze der Risiko-Kapital-Millionen zu spüren, die da abgefackelt werden.

Aber vielleicht bin ich einfach nur zu alt für solche Neuerungen…

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