Jemand zu Hause im Windows Store?

Ich habe lange keinen Beitrag mehr geschrieben für diesen Blog, aber jetzt ist etwas fällig: Tut mir leid, ich muss mich über etwas beklagen und einen „Rant“ vom Stapel lassen.

Im Prinzip finde ich es gut von Microsoft, mit der Kachel-Oberfläche und den Modern Apps einen kompletten Neuanfang zu wagen. An sich würde ich es gerne sehen, dass dieser mutige Neuanfang mit Erfolg belohnt würde. Die Chancen auf Erfolg stehen und fallen mit dem Windows Store und den Apps, die er enthält.

Und wie schaut es da so aus? Bisher zappenduster, ist mein Schluss. Beim Windows Store als einem der wichtigsten Projekte von Microsoft der letzten Jahre habe ich den Eindruck, es sei niemand zu Hause, der auch nur ein wenig nach dem Rechten schaut.

Resultat einer Suche nach Flappy Bird im Windows Store, heute durchgeführt: 282 Apps, wovon geschätzt etwa 100 in meinen Augen eklatante und offensichtliche Verletzungen des Copyrights des Autors des Original-Spiels darstellen, nicht nur wegen den App-Namen, sondern vor allem wegen den Icons, bei denen eins-zu-eins vom Original abgekupfert wurde.

Ich als Programmierer und Autor einer eigenen App finde das gar nicht lustig.

Immerhin hat Microsoft auch gemerkt, dass das nicht so toll ist, und hat kürzlich gewisse Richtlinien verschärft, wie man im Windows Blog hier nachlesen kann. Aber: Keine Mail von Microsoft an mich als Developer in dieser Sache, kein Eintrag bei den News im Dev Center.

Und, was gibt es denn so im Windows Store? 231 (!) Tic-Tac-Toe-Apps. Die meisten davon implementieren das Standard-Spiel auf einem 3×3-Feld, bei dem schon jedes Kind weiss, dass der gewinnt, der mit seinem ersten Zug die Mitte besetzt. Aber gut, wenn den Programmierern nichts besseres einfällt, wie soll Microsoft sie aufhalten? Es macht trotzdem keinen guten Eindruck.

Bis vor kurzem gab es eine App namens WhatsApp Messenger, genau so benannt, mit dem bekannten grünen Icon, kostenpflichtig, bei der man erst beim Lesen der Bewertungen wütender Anwender darauf kam, dass es sich nicht um das allseits bekannte WhatsApp handelt, ja nicht einmal um ein Chat-Programm, sondern nur um eine Dussel-App mit ein paar Tipps zu WhatsApp. Klare Irreführung, und einer der Anstösse für mich, diesen Blog-Eintrag hier zu schreiben.

Die App scheint zwar unterdessen whatsapp tips n tricks zu heissen, wohl als Folge der verschärften Richtlinien, die ich erwähnt habe, hat aber immer noch ein vom Original geklautes grünes Icon. Und ein WhatsApp PC, ein WhatsApp for PC und ein WhatsApp for Windows als weitere solche Fakes machen nach wie vor den Store unsicher. Wie sagt man auf Neudeutsch: Facepalm.

Was ist eine gute und attraktive Anwendung von Tablets, zudem noch eine, bei der sogar die eher schwachbrüstigen Surface-Tablets mit ARM-Prozessoren eine gute Figur machen? Lesegerät für eBooks. Und wer ist ganz gross im Geschäft mit eBooks? Natürlich Amazon. Und es gibt die Kindle App denn auch für Windows 8. Nur leider hat sie Dutzende schlechter Bewertungen, wo die Leute von Bugs bei den elementarsten Funktionen wie z.B. Umblättern berichten.

Ist es bei einer solchen „Flagschiff-App“ zuviel verlangt von Microsoft, dass man bei Amazon vorstellig wird und den Programmierern da mal ein bisschen Feuer unter dem Hintern macht? Man könnte ja auch Teile des sicher nicht knapp bemessenen Werbebudgets für Windows 8 einsetzen, um solche Fälle von klarer Negativwerbung aus der Welt zu schaffen. Alles, nur nicht so etwas monatelang im Store rumhängen lassen.

Also ich habe definitiv nicht den Eindruck, als sei beim Windows Store im Moment jemand am Werk, der weiss, was er tut und auch mit der nötigen Autorität ausgestattet ist, um das zu tun, was nötig ist. Aber was mache ich mir Sorgen, es geht ja nur um die Zukunft von Windows bei der ganzen Sache…

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

Hey, wo ist meine Exception hin?

Ich hatte kürzlich den Fall eines Programms, welches munter mit einem uninitialisierten Pointer hantierte und trotzdem keine Exception auslöste oder von Windows gestoppt wurde. Die tl;dr-Version des Resultats meiner darauf folgenden Abklärung: Wenn 32bit-Programme unter einem 64bit-Windows laufen, werden unter gewissen Umständen Fehler wie ungültige Zugriffe auf Speicher einfach verschluckt. Der Stack wird abgebaut und das Programm läuft weiter, unklar an welcher Stelle, in einem wahrscheinlich inkonsistenten Zustand. Es sieht so aus, als könne man im Moment nichts dagegen unternehmen.

Die lange Version meiner Geschichte:

In unseren „native“ d.h. C++-Programmen haben wir bei Windows mit Hilfe des WIN32-API-Aufrufs SetUnhandledExceptionFilter eine Prozedur installiert, welche sämtliche Laufzeitfehler melden und in einem Log auf Disk vermerken soll.

Beim eingangs erwähnten Fehler mit einem ungültigen Pointer wurde diese Prozedur allerdings nicht aufgerufen, und es passierte mit und ohne Debugger gleichermassen folgendes: Der Fehler wurde verschluckt und das Programm fuhr fort, jedoch an einer unklaren Stelle (Step Into und Step Over im Debugger versagten beide, so dass man nicht sah, wo), in einem ziemlich „wackeligen“ internen Zustand.

Nach einigem Googlen fand ich dann den folgenden Blog-Eintrag: The case of the disappearing OnLoad exception.

Dieser bestätigt: Wenn während der Ausführung eines 32bit-Programms auf einem 64bit-Windows die Prozeduraufrufe so geschachtelt sind, dass es „zwischendurch“ Prozeduren von Windows selbst hat, z.B. wenn man sich in einer eigenen WindowProc befindet, und dann ein Fehler passiert, wird dieser verschluckt.

Als Lösung wird beschrieben, man solle sein Programm per Manifest explizit als unterstützt Windows 7 markieren. Wie genau sich das Programm verhalten soll, wenn man das macht, wurde mir anhand der Ausführungen im Blog-Eintrag nicht ganz klar, aber auf jeden Fall werden Fehler offenbar nicht mehr einfach ignoriert.

Ok, hab‘ ich ausprobiert, eine solche Markierung ist ja nicht schwierig, wie Microsoft hier beschreibt. Resultat: Keine Änderung.

Ich vermute, der Grund dafür ist diese Geschichte: Application Manifest may be ignored in Windows 7 x64: Man kann zwar sagen, man unterstütze Windows 7, aber ein 64bit Windows 7 lässt das 32bit-Programm unter Umständen trotzdem nur als Windows Vista laufen, und da werden Fehler offenbar noch ignoriert.

Es gab zwar einmal einen Hotfix, um dieses Problem zu beheben, aber der will auf meinem Windows 7 SP1 nicht installieren, der Hotfix aus dem Jahr 2010 ist wohl nur für Windows 7 „pur“.

Mir scheint, hier verheddert man sich prächtig in einem Gestrüpp von Windows-Fehlern und -Unzulänglichkeiten; auf jeden Fall habe ich bis jetzt keine Verbesserung hingekriegt.

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

Ein Lob für das Visual-Studio-Debugger-Team

Vor einiger Zeit hatte ich eine Beta von Visual Studio 2012 ausprobiert und versucht, damit unsere C++-basierten Applikationen zu debuggen. Mit VS2005 bis VS2010 hatte das jahrelang prima geklappt. Mit VS2012 hingegen ging es hochkannt schief: Der Versuch, die Applikation zu starten, führte zu einem Total-Crash von VS2012 selbst, noch bevor die erste Zeile unseres Programm-Codes überhaupt zur Ausführung kam. Mehr oder weniger das selbe Phänomen bei einem Attach to process: Unser EXE war toxisch, bei der ersten Berührung damit fiel VS2012 tot um.

Als sich das auch mit der RTM-Version von VS2012 nicht geändert hatte, und weit und breit keine gute Idee zu sehen war, was der Grund sein könnte für das Problem, wurde ich langsam nervös und rang mich dazu durch, bei Microsoft Hilfe zu suchen, obwohl ich recht skeptisch war: Würde sich ein Weltkonzern wie Microsoft interessieren für ein Problem einer kleinen IT-Bude in der Schweiz?

Ich machte also ein Posting im Forum des Visual Studio Developer Center. Das Resultat war mittelprächtig: Ein Microsoft-Mitarbeiter, der da wohl so etwas wie „Dienst tut“, schaute sich die Sache an, war aber bald mit seinem Latein am Ende, und machte schliesslich den Vorschlag, ich solle direkt einen Bug-Report erstellen, auf connect.microsoft.com.

Das tat ich auch – den Bug Report find man hier – und wartete gespannt, wie es weitergehen würde.

Das Resultat übertraf meine Erwartungen deutlich: Nach nur etwa 2 Wochen hatte jemand im Debugger-Team den Grund für die Crashes gefunden, die Sache für die nächste Version von Visual Studio korrigiert, und erst noch eine Umgehungs-Lösung geliefert, wie es auch mit dem bestehenden VS2012 klappt.

Allein diese Umgehungslösung ist sehr interessant: Offenbar hat Microsoft, ohne das an die grosse Glocke zu hängen, wesentliche Teile der „debugging engine“ für die 2012er-Version von Visual Studio überarbeitet, und es war dieser neue Code, welcher an einer Seltsamkeit in den VERSIONINFO-Daten in unserem EXE gar keine Freude hatte. Es gibt einen Trick, wie man die „legacy debug engine“ aktivieren kann, den alten Code, welcher damit klarkommt und der noch da ist: Man schaltet die Option Enable Edit and Continue in den Debugging-Options ein:

Legacy Debugger

Legacy Debugger aktivieren

Das ganze war für mich ein voller Erfolg. Auch wenn es natürlich keinerlei Garantien auf Erfolg gibt, möchte ich doch jeden ermuntern, der ein ernstes Problem hat mit Visual Studio, den Weg über einen Bug-Report auch zu versuchen. Es kann sein, dass man erhört wird.

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

Geschichten aus 1001 Plugins

Das ist die Geschichte von einem, der auszog abzuklären, wie man eine grosse konventionelle Applikation als moderne, interaktive Web-Applikation programmieren könnte, und der zwar nicht mit einer Antwort, aber doch mit einer Erleuchtung wieder nach Hause kam.

Wenn man sich Moneysoft ansieht, wird einem schnell klar, dass bei einer Realisierung als Web-Applikation ein rein Server-seitiger Ansatz mit statischem HTML ohne Einsatz von Javascript nicht genügt. Nur ein Beispiel hierzu: Man kann heute einen Anwender nicht mehr 20 Dinge eingeben lassen in einer Datenerfassungs-Maske und ihm erst nach dem Abschicken aller Daten sagen, dass alles falsch ist. Eine unzulässige Eingabe auf einem Textfeld erfordert eine sofortige Fehlermeldung, und das heisst im Browser Einsatz von Javascript in irgendeiner Form.

Ich habe darum abgeklärt, wie man heute denn so Web-Applikationen mit einem hohen Anteil an Logik im Client programmiert. Welche Javascript-Frameworks gibt es, die sich bewährt und Reife erlangt haben? Welche Programmier-Muster haben sich etabliert? Welche Regeln befolgen erfahrene Programmierer bei der Entscheidung, was Client-seitig und was Server-seitig implementiert werden soll?

Angetroffen habe ich einen Dschungel, wie ich ihn mir so nicht hätte träumen lassen: Buchstäblich Dutzende miteinander konkurrierender Javascript-Frameworks, Bibliotheken oder wie immer man das nennen mag. Sammlungen mit Hunderten von Plugins bei mindestens einem dieser Frameworks. Viele dieser Dinge mit mehreren Releases, die dazu noch oft in unglaublich schneller Folge erscheinen. Grosse verwirrende Tabellen, was in welchem Browser in welcher Version wie gut funktioniert – oder eben nicht. Und für Leute, die übermütig werden, weil sie meinen, sie hätten es geschafft, lange Abhandlungen darüber, was man alles anders machen muss, damit es auch mit Tablets und Smartphones gut klappt.

Blickt man auf jedes noch so kleine Problem, das sich beim Bauen von Web-Applikationen typischerweise stellt, wie z.B. ein schlauer Editor mit interaktiven Formatierungens-Funktionen als Aufsatz für Textboxen, entdeckt man nicht etwas, das sich als Standard etabliert hat, sondern einen wilden Haufen miteinander konkurrierender Lösungen verschiedenster Grösse und Qualität.

Ok, sagte ich mir, das ist wohl eben so, wenn sich etwas so stürmisch entwickelt wie das Internet, seine Standards und die Geräte, mit denen man auf Websites zugreift. Aber wie baut man da Software, die man bezahlen kann und die nicht nächstes Jahr schon völlig obsolet ist?

Ich kann mir ganz verschiedene Strategien vorstellen, wie man versuchen könnte, sich in diesem Dschungel sinnvoll zu bewegen und länger als ein paar Monate zu überleben. Man könnte die Client-Logik sorgfältig so wählen, dass mit möglichst wenig Javascript-Einsatz ein möglichst grosser Gewinn an Benutzerfreundlichkeit herausschaut: Weniger Javascript bedeutet weniger Abhängigkeiten und potentiell weniger Ärger.

Man könnte versuchen Wahrsager zu spielen und vorherzusehen, was sich in Zukunft einmal durchsetzen könnte, wenn sich die Situation dereinst einmal stabilisieren wird, und dann darauf wetten. Auf der einen Seite Pech, wenn man falsch wettet, aber aber der anderen Seite auch nicht sooo schwierig: jQuery wird auf jeden Fall unter den „Siegern“ sein, wenn Sie mich fragen.

Man könnte auch einen Satz von Open-Source-Komponenten zusammenstellen, der jetzt gut funktioniert, und diesen dann „adoptieren“, spricht selbst weiterentwickeln und an neue Browser und Standards anpassen – mindestens ein paar Jahre lang, bis man etwas Neues machen kann.

Ich hatte grosse Mühe, im Internet brauchbare Diskussionen darüber aufzutreiben, wie man die Strategie findet, die für die jeweils eigene Situation angebracht ist. Viele Leute scheinen noch nicht einmal die Notwendigkeit einer Strategie zu empfinden, und mixen frisch-fröhlich die neuesten Versionen von einem Dutzend oder mehr Plugins zu Web-Applikationen zusammen, als ob es kein Morgen gäbe.

Ich fühlte mich weit davon entfernt, eine Entscheidung darüber zu treffen, welchen Weg die Megos AG einschlagen müsste auf dem Weg zu einem Moneysoft.web, und war am Schluss ziemlich beunruhigt über die ganze Situation.

Aber dann dann kam sie, die eingangs angesprochene Erleuchtung, eines Abends kurz vor dem Einschlafen, und brachte zwar nicht die Antwort auf die Frage nach der Strategie, aber trotzdem ein Ende meiner Zweifel, ob das je etwas werden wird:

Frage: Wie ist es überhaupt möglich, dass es diese riesige Zahl an Javascript-Bibliotheken und -Plugins gibt? Antwort: Es muss einfach und nicht allzu zeitaufwendig sein, so etwas zu bauen. Und das wiederum heisst, dass es eine Obergrenze gibt, wie komplex und kompliziert diese Software überhaupt sein kann: nicht sehr.

Auf die eine oder andere Weise werden wir das darum in den Griff kriegen.

Zu guter Letzt noch ein Link: Ich habe im Zuge der beschriebenen Abklärungen gute Web-Applikationen gesucht, die von der Art der Funktionalität her mit Moneysoft vergleichbar sind (welche man breit gefasst als „Verwaltung administrativer Daten“ umschreiben könnte), und bin dabei auf smallinvoice gestossen. Funktioniert ausgezeichnet, sogar im relativ exotischen Opera-Browser, mit dem ich normalerweise unterwegs bin, was ein sehr gutes Zeichen punkto Einhaltung von Web-Standards darstellt, und wurde offenbar von einem vergleichsweise kleinen Team unter Schweizer Leitung gebaut. Geht doch!

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

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 »