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.

Advertisements
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 »

Keine Indices für nvarchar(MAX)

Heute habe ich an einer SQL-Datenbank, die ich via Entity Framework 4 von einer C#-Anwendung aus anspreche, „von Hand“ Kolonnen hinzugefügt, um Änderungen an meinen Entities nachzuvollziehen, ohne die Daten in den Tabellen zu verlieren. Dabei ist mir zum ersten mal richtig aufgefallen, dass alle meine textuellen Kolonnen vom Typ nvarchar(MAX) sind, bzw. dass EF4 die Kolonnen so für mich definiert hat.

MAX schien mir Overkill, aber richtig, ich hatte ja bei den Properties im EF-Designer keine Maximal-Längen-Angaben gemacht. Irgendwie verständlich, weil man schliesslich beim O/R-Mapping vom C#-Datentyp String her kommt, wo man sich keine Gedanken über Maximallängen machen muss.

Zur Sicherheit klärte ich ab, ob ich mir mit der Verwendung von nvarchar(MAX) irgendwelche Nachteile einhandle. Ich dachte da an eine mögliche Speicherverschwendung, die so zustandekommt. Eine Frage auf Stack Overflow brachte Klärung: Nein, Speicherverschwendung ist kein Problem, aber SQL Server mag keine normalen Indices bauen mit MAX-Kolonnen drin.

Es ist tatsächlich ein bisschen schwierig, einen B-Baum zu führen mit potentiell beliebig langen Schlüsseln in Seiten fixer Länge!

Neugierig geworden, forschte ich noch etwas weiter. Maximallängen setzen bei den Properties im EF4-Designer löst zwar das erwähnte Indizier-Problem, hat aber eine Schwäche: EF4 selbst überwacht die Maximallängen nicht, sondern gibt einfach alles an den SQL Server weiter, wo es dann zwar schon einen Fehler gibt, aber offenbar einen, bei dem man unter Umständen nicht versteht, wo das Problem liegt. Diese Geschichte ist hier näher beschrieben.

Weiterhin scheint es überraschend schwierig zu sein, die Maximallängen-Angaben, die man im Designer macht, zur Programmlaufzeit abzufragen, z.B. um irgendwelche Eingabe-Controls dynamisch und „generisch“ auf die betreffenden Längen einzuschränken. Nachlesen kann man das z.B. hier.

Schliesslich scheint es mit Code First in EF4.1 und/oder bei Einsatz von SQL Server Compact eine Reihe neuer Fragen rund um die Maximallänge von Text-Kolonnnen zu geben, wie man hier beschrieben findet.

Es ist schon interessant, wie sich beim Programmieren mit .NET immer mal wieder Dinge als vielschichtiger herausstellen, als man auf den ersten Blick annimmt.

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

Informationspolitik

Wenn es um Windows 8 geht in offiziellen Verlautbarungen von Microsoft, glänzen C#, .NET, WPF und Silverlight meistens durch Abwesenheit. Stattdessen wird jede Menge über HTML 5 und JavaScript für eine schöne neue Welt von modernen Windows-Applikationen erzählt.

Als das vor ein paar Monaten losging, waren verständlicherweise viele Programmierer ziemlich beunruhigt und haben auf verschiedenen Wegen Microsoft um Klärung gebeten. Die Auskunft damals war: Liebe Leute, wir verstehen Eure Sorgen, aber es tut uns leid, wir können im Moment nichts sagen. Wartet bis zur BUILD Conference in den USA im September.

Es versteht sich, das dieses Schweigen Microsofts nicht zur Beruhigung beigetragen hat, wie man ziemlich deutlich z.B. an isdotnetdead.com und Open Plea by Silverlight / WPF Devs ersehen kann.

Nun kam für mich als Schweizer gestern folgende Meldung: Für die TechDays 11 in Bern am 20. und 21. Oktober, also zeitlich eine ganze Weile nach der BUILD, wird bezüglich Windows 8 umdisponiert. An den TechDays gibt es neu keine Informationen über Windows 8; wer sich als Schweizer Programmierer dafür interessiert, wartet auf einen eigenen Informationsanlass am 9. Februar 2012. Zu lesen ist das z.B. auf der TechDays-Website oder der Website des SWISS DPE Teams.

Das monatelange Schweigen von Microsoft über die zukünftigen Stossrichtungen betreffend Programmieren für Windows 8 und jetzt die Verschiebung der Orientierung der Schweizer auf den Februar 2012 finde ich persönlich nicht gut, sehe das aber noch knapp innerhalb eines „normalen“ Rahmens.

Was ich allerdings jetzt definitiv nicht mehr verstehe und was mich über die Klippe gestossen und zu diesem Blog-Eintrag veranlasst hat: Microsoft liefert, so viel ich weiss, keine brauchbare Begründungen für all diese Wartereien und Verschiebungen, die man uns zumutet.

Wenn man schon die Leute monatelang hängenlässt, was in der heutigen Zeit eine kleine Ewigkeit bedeutet, gehört doch einfach dazu, den Leuten zu erklären, warum man das tut. Ohne Erklärung werden die Ängste nur um so grösser, und die Spekulationen umso wilder.

Ich bin Realist und weiss, wie klein die Chancen sind, dass nun genau dieser Blog-Eintrag etwas bewirkt, aber es musste mal gesagt sein.

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

using System.Web.Mvc.Html;

Es ist nur eine kleine Sache, aber es kann je nach dem dauern, bis man darauf kommt (wie bei mir heute…):

Wenn man eine neue Extension Method für HtmlHelper schreiben will, z.B. einen speziell „konfigurierte“ Variante von Html.ActionLink, sind Methoden wie eben ActionLink erst sichtbar, wenn man neben System.Web.Mvc auch System.Web.Mvc.Html importiert.

Man kommt deshalb so schlecht drauf, weil Visual Studio 2010 nicht genügend schlau ist, auf diese Tatsache hinzuweisen, wenn man im Code htmlHelper.ActionLink hinschreibt, bzw. der „using“-Assistent findet zwar heraus, dass man für einen HtmlHelper einen Import von System.Web.Mvc benötigt, versagt aber für ActionLink und ähnliche Methoden.

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