Entwickeln für WP7 – wie ist das denn so?

Die erste Megos-App für Windows Phone 7 ist fertig und kann hier im Marketplace weltweit heruntergeladen werden. Eine umfangreichere Beschreibung findet man auf Englisch hier.

Bei dieser kostenlosen und werbefreien App namens NickWrite habe ich versucht, eine Art Text-Editor für WP7 zu bauen. Sie bietet Funktionen wie etwa Undo/Redo, die heute in praktisch keiner Desktop-Applikation mehr fehlen dürfen, die mit dem Schreiben von Text zu tun hat, die aber seltsamerweise auf Smartphones bislang nicht zu finden sind.

Hier mein Bericht, wie es mir ergangen ist beim Entwickeln für WP7:

Die Werkzeuge, also Visual Studio 2010, Expression Blend 4 und der WP7-Emulator sowie C# und Silverlight in der WP7-Variante funktionieren bestens: stabil, ausgereift, gut verständlich. Man kann sich im wesentlichen auf das Entwickeln konzentrieren und merkt oft kaum, dass man nicht für einen PC, sondern etwas ganz Anderes programmiert.

Das Remote Debugging auf dem Smartphone funktioniert bestens und hat zeitweise fast etwas Magisches an sich.

Mit der Geschwindigkeit der Code-Ausführung und der grafischen Ausgabe auf dem Smartphone hatte ich so gut wie keine Probleme. Auch beim Einsatz von Speicher brauchte ich nicht zu knausern.

Natürlich ergeben sich für einen Neuling wie mich trotzdem jede Menge Fragen, aber die lassen sich mit Hilfe von Google meistens schnell beantworten: Dafür, dass WP7 noch so jung ist und die Verkäufe von WP7-Smartphones zumindest bis jetzt noch niemanden vom Hocker reissen, gibt es bereits eine erstaunliche Menge von Material zu WP7 im Internet, etwa auf Stack Overflow oder in Blogs zum Thema.

So weit, so gut.

Auf der Negativ-Seite ist zu erwähnen, dass ich fast andauernd mit dem WP7 API und seinen Limiten zusammenstiess. Ich habe mich schon in früheren Blog-Einträgen darüber ausgelassen: Man darf einfach gar nichts. Das ist für einen App-Entwickler, der etwas ambitioniertere Ideen umsetzen will, die reinste Spielverderberei.

Viele der Limiten sind durchaus sinnvoll, was man erkennt, wenn man die Seite wechselt und den Blickwinkel des Smartphone-Benutzers einnimmt, der vor unangenehmen Überraschungen sicher sein will. Aber viel Funktionalität, die betreffend Sicherheit völlig unproblematisch wäre, fehlt schlicht und einfach. Man kann etwa nur mit Tricks feststellen, wie viele Pixel breit ein bestimmter String wird, wenn man ihn auf dem Bildschirm darstellt – und das bei einer GUI!

Der Marketplace ist mittelprächtig. Ich habe festgestellt, dass dessen Suche die Beschreibung einer App vollkommen zu ignorieren scheint; nur wenn jemand nach den bei der App hinterlegten Stichworten sucht, wird man gefunden. Und selbst da gibt es ein Problem: Bei einem sehr häufig gesetzten Stichwort wie SMS oder Text kommen nicht alle Apps, sondern nur etwa 200 oder so, der Rest wird einem ohne den geringsten Hinweis einfach vorenthalten.

Dass man bei einem Screenshot immer noch nicht angeben kann, ob er hoch oder quer ist, muss man meiner Meinung nach einfach nur als Witz bezeichnen: Soll man den Monitor kippen, um sich Landscape Screenshots anzusehen?

Wieder auf der Positiv-Seite kann ich vermelden, dass meine App nach dem Einreichen sehr schnell zertifiziert und im Marketplace veröffentlicht wurde. Man hört zwar je nach Entwickler auch andere Geschichten, aber ich hatte keine Probleme.

Die tägliche Flut neuer WP7-Apps schwappt weiter gnadenlos über die Welt herein. Kaum ein Tag vergeht, ohne dass noch eine Tic-Tac-Toe-App mehr erscheint, ohne jede Spezialität, das ganz normale 3×3-Spiel, bei dem jedes Kind weiss, dass man in die Mitte setzt als Eröffnung und dann sicher gewinnt. Heute erschienen so sinnvolle Apps wie etwa „Meter zu Kilometer“ – da ist die App „Fuss zu Meter“, die ebenfalls erschien, schon fast eine Intelligenzbestie im Vergleich.

An sich könnte man sich ja darüber amüsieren, wenn es denn nicht zu einem handfesten Problem führen würde für jemanden, der eine sinnvolle und nützliche App schreibt: Wie wird meine App nebst all diesem Müll bemerkt? Wie finden sie die potentiellen User überhaupt?

Nun, wie ich denke jedenfalls nicht, in dem man sich rein auf den Marketplace verlässt. Man muss sich schon etwas anstrengen und über seine App schreiben, wie etwa in diesem Blog-Eintrag hier!

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

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.

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

Das Monster im WP7-Clipboard

Es ist keine besonders wichtige Geschichte, die ich heute erzähle, aber loswerden will ich sie trotzdem, denn ich finde sie einigermassen süss:

Ich wollte für meine im Bau begriffene WP7 App eine Funktion programmieren, die einen im Clipboard vorhandenen Text nimmt, ihn analysiert und dann dem Benutzer auf eine intelligente Weise zur Verfügung stellt: Die App würde eine Liste erstellen aller spezieller „Dinge“ im Text wie URLs, Mail-Adressen und Telefonnummern, und der Benutzer könnte anschliessend diese Dinge durch einfaches Antippen verwenden. Eben eine verallgemeinerte Variante der WP7-Standard-Funktionalität, die in SMS-Texten (aber nur solchen) aus Dingen antippbare Links macht.

Dabei musste ich feststellen, dass es einer WP7-Applikation nicht erlaubt ist, den Clipboard-Inhalt auszulesen. Das ist nur interaktiv durch den Benutzer ausgelöst möglich. Siehe entsprechende Info im MSDN. Es nützt überhaupt nichts, dass die entsprechende Methode Clipboard.GetText da ist und man sie ohne Probleme in seinen Code aufnehmen kann – der Versuch, sie auszuführen, ergibt knallhart stets eine SecurityException.

Gegenüber anderen Einschränkungen des WP7-API ist das ein kleiner Fisch, aber trotzdem: Was soll das mit Sicherheit zu tun haben? Was haben sich die Microsoft-Programmierer dabei gedacht, als sie diese Einschränkung einführten, gegen welches Bedrohungs-Szenario richtet sie sich?

Es kann eigentlich kaum daran liegen, dass im WP7-Clipboard irgendein Monster sitzen könnte, gegen das man Programme schützen müsste, welche den Clipboard-Inhalt auslesen. Das Clipboard kann sowieso nur Text enthalten (eine weitere Einschränkung, bei der man nicht so recht weiss, was man davon halten soll), und auch wenn man mit Hilfe von Unicode einigen Blödsinn anstellen kann, eine Bedrohung kriegt man so wohl kaum zustande.

Soll die Limitation ein Schutz sein gegen bösartige Programme, welche den Benutzer über den Inhalt des Clipboards ausspionieren? Programm wartet im Hintergrund, bis der Anwender das hochgeheime Passwort per Copy&Paste von einer App in die nächste transportiert, schnappt sich dieses, während es im Clipboard sitzt, sendet es zum Server der Verbrecher, und das Unheil nimmt seinen Lauf?

Aber sicher doch.

Vor allem, da ja in WP7 das Multitasking von Apps so toll ausgebaut ist, dass man überhaupt im Hintergrund warten könnte, bis etwas Interessantes im Clipboard auftaucht.

Meine Vermutung ist, dass die Jungs und Mädels bei Microsoft schlicht über’s Ziel hinausgeschossen sind. Gebrannt durch die lange Leidensgeschichte von Windows auf dem PC, was Sicherheit bzw. die ziemliche Abwesenheit derselben betrifft, will man wohl jetzt unter allen Umständen vermeiden, dass WP7 mit irgendeiner Sicherheitslücke Negativ-Schlagzeilen macht.

Wenn man also nicht zu 100% sicher sein kann, dass nichts aus dem Ruder läuft, wenn man den Apps Clipboard-Lese-Zugriff einräumt, lässt man lieber die Finger davon: Better safe than sorry.

Veröffentlicht in Allgemein. Schlagwörter: . 1 Comment »

Stoppt den Trivial-App-Wahnsinn

Ich verfolge seit etwa 2 Wochen systematisch und fast täglich, welche Apps neu herauskommen für Windows Phone 7.

Dabei fiel mir schon bald einmal eine Klasse von Apps auf, die ich als Trivial-Apps bezeichnen würde, weil sie einen sehr geringen Funktionsumfang haben. Einmal neugierieg geworden, habe ich mir dann einen Spass daraus gemacht, besonders triviale und besonders idiotische Apps zu finden.

Da haben wir zum Beispiel die 5Fakten xyz-Reihe von Apps, etwa 5Fakten Giraffe des Publishers JeDaAppz:

5 Fakten Giraffe

Was Sie hier auf dem Screenshot sehen, ist wirklich und wahrhaftig schon alles: 5 Fakten über die Giraffe, angezeigt nach dem Berühren eines Buttons.

Oder vielleicht interessiert Sie eine WP7-App wie Costa Cordalis, welche die komplette Diskographie des Sängers Costa Cordalis auflistet; die Sonderzeichen-Fehler müssen Sie dabei allerdings leider in Kauf nehmen:

Costa Cordalis

Einen (vielleicht nur vorläufigen) Tiefpunkt hat die Sache in meinen Augen heute erreicht, mit dem Erscheinen der App geburtsortGoethe, weil diese App nicht nur durch eine besonders triviale Funktionalität besticht (ein 1-Frage-Quiz), sondern als Zückerchen noch mit einem falschen Stadt-Namen aufwartet (bei der ersten Option kann natürlich fast nur Weimar gemeint sein):

Geburtsort Goethe

Leider habe ich keine Kontakt-Möglichkeit zu den Publishern dieser Apps gefunden, um zu fragen, was diese damit bezwecken. Wohlwollend könnte man vielleicht spekulieren, dass es sich hier um die Resultate von Teilnehmern von Programmierkursen handelt, die zum Abschluss ihre selbst geschriebene App in den Marketplace stellen dürfen.

Bei mittlerweile über 20 5Fakten-Apps über verschiedenste Tiere taugt allerdings eine solche Erklärung eher nicht. Vielleicht ist in diesem Falle der Publisher ein Teilnehmer einer jener Wettbewerbe, bei dem derjenige z.B. ein Gratis-WP7-Smartphone gewinnt, der bis zu einer bestimmten Deadline die meisten Apps im Marketplace veröffentlicht hat. Ja, solche Wettbewerbe gibt es tatsächlich, in verschiedenen Ländern, mit verschiedenen Sponsoren (z.B. hier), und wenn man einen solch fragwürdigen Anreiz setzt, muss man sich nicht wundern, wenn fragwürdige Apps dabei herauskommen.

Wäre es die Pflicht von Microsoft, als allmächtiger Wächter über den Marketplace einzuschreiten und Apps die Veröffentlichung zu verweigern, wenn sie nicht über eine bestimmte Minimal-Funktionalität verfügen? Ich glaube kaum, dass ein solches Vorgehen praktikabel wäre. Es gibt durchaus sinnvolle Apps mit sehr wenig Funktionalität, die ihre Berechtigung haben, weil sie trotzdem einen Nutzen bieten, wie z.B. eine „Taschenlampe“-App. Wer wollte hier Grenzen ziehen, ohne dass es ständig zu Querelen zwischen Microsoft und den Publishern kommt und ohne dass Microsoft der Aufwand für die Prüfung der Apps durchs Dach geht?

Veröffentlicht in Allgemein. Schlagwörter: , . 3 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 »