Erfahrungen mit der Entwicklung von Windows-Phone-Apps Phone, Schweiß und Tränen

Transkript

1 Erfahrungen mit der Entwicklung von Windows-Phone-Apps Phone, Schweiß und Tränen Die Möglichkeiten der Windows-Phone-Plattform sind schlichtweg begeisternd, aber damit WP-Apps gut nutzbar sind und ihre Entwicklung kein Zeitfresser wird, gilt es einiges zu beachten und üble Fallen zu umgehen. Auf einen Blick Dipl.-Inf. (FH) Peter Meinl ( ist IT- Berater, Trainer und passionierter Querdenker. Er entwirft und realisiert seit mehr als 25 Jahren datenbankorientierte und verteilte Anwendungen. Sein fachlicher Schwerpunkt ist der Entwurf kundenspezifischer Lösungen für die Fertigungs industrie. Inhalt Hilfreiche Entwicklungswerkzeuge. Mit Traces verstehen, wie eine Phone-App tickt. Beispiel-App: Währungsrechner. Fallen bei der Realisierung von Background Agents. Serie 1. Phone, Schweiß und Tränen 2. Aus App-Gründen ans Licht dnpcode A1209AppErfahrung E in Währungsrechner sollte sie sein, meine erste Windows-Phone-App: Ich wollte ein Gefühl für die Entwicklung von Anwendungen für die neuen Smartphones bekommen. Bei häufigen Fernreisen nutzte ich verschiedenste Währungsrechner wie die Oanda-Website, das Standard-Windows-7-Gadget und Windows-Mobile-Apps. Beim Ausprobieren einiger Windows-Phone-Apps gefiel mir keine wirklich. Mit der Entwicklung eines Währungsrechners kann man viele der häufig in Apps benötigten Features ausprobieren, zum Beispiel die Reaktion auf Nutzereingaben, das Nutzen von Daten aus dem Web, den Offline-Modus, die App/Agent-Synchronisation und die Location Services. Die Entwicklung der Currencies-App [1] hat dann viel mehr Wochenenden gekostet als erwartet. WPF und Silverlight für sich allein sind ja schon extreme Zeitfresser, aber die Entwicklung für Windows Phone setzt noch einen drauf. Diese zweiteilige Artikelserie vermittelt wesentliche Erfahrungen aus der Entwicklung der Currencies-App und stellt anhand einer abgespeckten Beispielanwendung (siehe Code zum Artikel auf der Heft-DVD) einen Rahmen zur effizienten Entwicklung von Windows-Phone- Apps bereit. Die Zukunft der Plattform mag derzeit noch unklar sein (siehe Is Time Running Out for Windows Phone? [2]), aber vieles des hier Gelernten ist auch für WPF und Silverlight im Allgemeinen sowie für Metro-Style-Apps unter Windows 8 nützlich. Übrigens starteten Microsoft und Nokia Ende Mai 2012 ein mit 18 Millionen Euro dotiertes Programm zum Anschieben mobiler Start-ups [3]. Der erste Eindruck zählt Der erste Eindruck, den der Nutzer von einer Phone-App hat, ist entscheidend: Die Darstellung im Marketplace muss attraktiv und übersichtlich sein auf dem Phone und im Web, über Zune gibt es ja seit kurzem keine Apps mehr. Probleme beim Installieren beziehungsweise Updaten oder beim ersten Start dürfen nicht auftreten. Der Nutzer muss so schnell wie möglich etwas Attraktives zu sehen bekommen. Beachtet man einen dieser Punkte nicht, wendet sich der potenzielle Käufer ab oder empfiehlt die App nicht weiter. Deshalb lohnt es sich, diese Punkte von Anfang an bewusst zu gestalten und während der Entwicklung zu überarbeiten und sie nicht erst am Ende der Entwicklung, womöglich gar unter Zeitdruck, anzugehen. Den Eindruck bei der Installation einer Phone- App kann der Entwickler nicht beeinflussen, aber er sollte die Einsatzmöglichkeiten der App auf ein Mindestmaß beschränken. Capabilities wie Location und Phone Identity werden auf dem Marketplace angezeigt. Der Nutzung mancher Services (zum Beispiel Location) muss der Anwender beim Installieren explizit zustimmen. Die aktuell von einer App gemeldeten Capabilities lassen sich mit der Capabilities-Validation des VS Marketplace Test Kit ermitteln. Unnötiges Melden von Capabilities kann durch Entfernen nicht verwendeter DLL-Referenzen vermieden werden. Fälschlicherweise gemeldete Capabilities kann man eventuell bei der App-Übergabe durch eine Notiz an den Test-Ingenieur löschen lassen. Launch- und Resume-Dauer einer App sollten so kurz wie möglich sein. Dies sollte man bei der Entwicklung von Anfang an beachten. Bei der Currencies-App wurden diese Teile erst im Nachhinein optimiert und die Zeiten sind deshalb leider grenzwertig lang. Für eine geeignete Grundhaltung (Mindset) zur Entwicklung von Apps sei das E-Book Getting Real von 37signals empfohlen [4]. Freie Werkzeuge Neben der kostenlosen Version des Standard- Microsoft-Werkzeugsatzes Visual Studio 2010 (VS) mit Expression Blend 4 (Visual Studio 11 Beta 1 unterstützt noch keine Phone-Projekte) haben sich folgende Werkzeuge als hilfreich für die App-Entwicklung erwiesen: Notify Property Weaver [5], Expression Design 4, Windows Phone Power Tools [6], MetroGridHelper Tool [7], Balsamiq Mockups [8], Silverlight for Windows Phone Toolkit [9], Coding4Fun Toolkit for Windows Phone [10], Phoney Tools [11], Templarian Phone Icons [12], VS Windows Phone Performance Analysis Tool,

2 Your Last About Dialog [13], MS Bing Maps SDK [14], Phone7.Fx BindableApplicationBar [15], VS Marketplace Test Kit, Convert.NET C#/VB-Converter [16]. Der Notify Property Weaver erspart das lästige und die Übersichtlichkeit des Codes störende Implementieren von INoti fy PropertyChanged, indem er für alle Klassen, die INotifyPropertyChanged implementieren, den Notification-Code via IL-Injection einfügt. Man installiert das Tool über NuGet. Via Projekt Notify Property Weaver lässt es sich für ein Projekt einschalten und konfigurieren. Ein weiteres interessantes Feature ist die Möglichkeit, Notification Interceptors zu implementieren, zum Beispiel zum Tracen oder um Benachrichtigungen in bestimmten Situationen zu unterdrücken. Der Einsatz von Werkzeugen, die IL-Injection verwenden, ist anfangs etwas beängstigend, aber man gewöhnt sich mit der Zeit daran. Notify Property [Abb. 1] Isolated- Storage-Dateien mit den Windows Phone Power Tools ansehen und manipulieren. Weaver macht einen sehr professionellen Eindruck. Mit Expression Design lassen sich die vier benötigten App-Icon-Größen recht einfach erstellen Unerfahrene können sich dabei an die Anleitung [17] halten. Allerdings sollte man dem Punkt 10 Opacity auf 0 setzen nicht folgen, weil damit das Quadrat, in dem man sein Icon entwirft, nicht mehr sichtbar ist. Nach einer Möglichkeit, einen Layer zu löschen, kann man lange suchen: Es gibt leider keinen Menüpunkt dazu, sondern man muss die [Entf]-Taste auf der Tastatur verwenden. Zum Ändern der Größe, ohne die Proportionen zu verändern, ist die [Shift]-Taste gedrückt zu halten. Mit den Windows Phone Power Tools lassen sich unter anderem die Dateien im Isolated Storage von Emulator und Phone ansehen und manipulieren, siehe Abbildung 1. Das ist hilfreich zum Prüfen von Trace-Dateien und zum Synchronisieren von Dateien zwischen App und Background Agent, sowie beim Testen von Updates. Das Tool MetroGridHelper hilft beim Ausrichten der UI-Controls nach dem 12px-Raster (mehr dazu weiter unten). Im Silverlight for Windows Phone Toolkit finden sich unter anderem das unverzichtbare ListPicker-Control und der LongListSelector. Das Coding4Fun Toolkit for Windows Phone bietet beispielsweise die Controls ToastPrompt, InputPrompt und das ProgressOverlay, womit Sie dem Nutzer mittels durchlaufender Punkte signalisieren können, dass die App gerade etwas für ihn tut. Das VS Windows Phone Performance Analysis Tool hilft beim Lösen von Performance-Problemen. Es hinterlässt recht große Dateien im Unterordner PerformanceLogs des Solution-Verzeichnisses, die Sie löschen können, um Ihre Backups nicht unnötig aufzublähen. Mit dem Bing Maps SDK kann man sich, auf Basis der Geo-Location-Infos, Karteninformationen vom Location Service des Phones holen. Die Currencies-App nutzt das Maps SDK, um aus den Latitude- und Longitude-Angaben des Location Service die Währung am aktuellen Ort zu ermitteln. Mit dem Marketplace Test Kit (zu erreichen mithilfe eines Rechtsklicks auf das Projekt) lässt sich grob prüfen, ob die App den Anforderungen der Zertifizierung durch Microsoft genügt. Kommerzielle Werkzeuge Folgende kommerzielle Produkte könnten hilfreich sein (wurden aber vom Autor noch nicht verwendet): bugsense Bug Tracking [18], Gibraltar App Monitoring [19], Telerik RadControls Controls Suite [20], PreEmptive App Analytics und Monitoring [21], EQATEC App Analytics und Profiling [22]. [Abb. 2] Balsamiq- UI-Skizze neben einem Screenshot der fertigen App

3 Erfahrungen mit der Entwicklung von Windows-Phone-Apps [Abb. 3] Architektur der Beispiel-App. User Experience Bei einer Phone-App steht der Entwurf der User Experience (UX) am Anfang, denn für den Nutzer einer App ist das User Interface (UI) die Anwendung. Bei Geschäftsanwendungen ist es dagegen meist sinnvoller, zuerst die Logik und die Einbettung in die Anwendungslandschaft zu entwerfen. Apps sollten folgende Standard-Features bieten: Application Bar, About Page, Back Tile, Secondary Tiles, Unexpected Error Dialogue, Support Request, Feature Request, Please Rate this App, Help Page, Trial Mode, Buy Full Version, Ads. Microsoft empfiehlt, Tiles einzusetzen, um die Attraktivität zu steigern. Tiles haben erst dann einen Sinn, wenn sich darauf etwas ändert, und dazu kann man Background Agents einsetzen. Zum Skizzieren von UIs eignet sich das Werkzeug Balsamiq Mockups [8]. Es ist handlicher als Expression Blend SketchFlow. So kann man zum Beispiel einfach durch Ziehen eines Objekts mit der Maus bei gedrückter [ALT]-Taste das ausgewählte Objekt klonen. SketchFlow bietet dieses zum schnellen Skizzieren wichtige Feature offenbar nicht und es findet sich nicht einmal ein Undo-Button. Beide Tools verwenden eine skizzenhafte Darstellung mit gekrakelten Linien, damit man sich beim Diskutieren des Entwurfs nicht in Kleinigkeiten verliert. Zwar kann auch Balsamiq seine Skizzen mit Aktionen verbinden (Click-through Prototyping), mit Sketch- Flow kann man die Skizze aber so real machen, wie man möchte, oder gar schrittweise in das Produkt übergehen lassen. Abbildung 2 zeigt die erste UI-Skizze der Currencies-App neben einem Screenshot der veröffentlichten App. Beispiel-App: Währungsrechner Die Beispiel-App namens CurrencyConverterDemo (siehe Code zum Artikel auf der Heft-DVD) implementiert exemplarisch folgende Features: Eingabe des von der App umzurechnenden Betrags, Umrechnung in Zielwährungen, gleichzeitige Anzeige mehrerer Umrechnungen, Holen von aktuellen Umrechnungskursen von der EZB-Website, Offline-Modus, Anzeige einer Umrechnung auf der Back Tile, Background Agent, About Page, Settings Page, Optimierung der Launch Time. Dabei erfolgt das Holen von aktuellen Umrechnungskursen manuell über einen Application-Bar-Button, automatisch über einen Timer in der App und im Hintergrund mittels eines Background-Task. Architektur Abbildung 3 zeigt die Architektur der Beispiel-App. Sie besteht aus der App selbst, die unter anderem das User Interface realisiert, und einem PeriodicTask, der im Hintergrund aktuelle Umrechnungskurse aus dem Web holt. App und Agent kommunizieren über Isolated-Storage-Dateien. Die Zugriffe auf diese Dateien sind mittels Mutexen synchronisiert. Der Background-Task holt periodisch neue Umrechnungskurse von der EZB- Website und speichert den Zeitpunkt der Aktualisierung und die neuen Kurse in Isolated-Storage-Dateien. Die App kommuniziert mit dem Nutzer über eine Page, gibt Meldungen, die bestätigt werden müssen, über MessageBoxes aus, gibt Meldungen, die nach einem Timeout von selbst verschwinden, über Toasts aus, aktualisiert die Back Tile der App, pollt den Agent-Status nach neuen Umrechnungskursen und zeigt automatisch Umrechnungen auf Basis der aktualisierten Kurse an. Implementierung Die Beispiel-App verwendet kein MVVM- Pattern (siehe Kasten Kein MVVM), sondern eine sehr einfache Architektur mit Code-behind und Datenbindung bis ins Modell. Das Verwenden von MVVM beim Entwickeln der Currencies-App führte zu sinnlosen Aufwänden und erschwerte die

4 Für Einsteiger Inkl. kostenlosem E-Book! [Abb. 4] Trace der Beispiel-App. Wiederaufnahme der Entwicklung nach längeren Pausen. Für die Beispiel-App sind Unit-Tests der Views oder des Modells nicht vorgesehen. Die Beispiel-App implementiert ihr Kern- UI, die Seiten Convert und Favourites über eine Pivot-Page. About und Settings sind als eigene Pages realisiert und können vom Nutzer über die ApplicationBar erreicht werden. PivotItems implementiert die Beispiel-App einfach direkt in der ConversionPivotPage. Phone-Pages sind im Allgemeinen so einfach, dass es nicht lohnt, sie in UserControls zu kapseln. Im Unterschied zu PanoramaItems, die beim Laden des Panoramas alle gerendert werden, rendert die Phone-Runtime bei Pivot Items immer nur die benachbarten Items mit. Trotzdem kann man zur Optimierung der Pivot-Performance die Pivot- Items in UserControls kapseln und diese erst im Event LoadingPivotItem dem jeweiligen PivotItem-Content zuweisen. Die Beispiel-App verwendet Your Last About Dialog [13] für die About-Seite, um den Aufwand zu minimieren. Als Programmiersprache wird VB.NET verwendet. Der Autor hatte die erste Version der Currencies-App in C# realisiert, musste aber erneut feststellen, mit Visual Basic deutlich produktiver zu sein, und wechselte wieder zu VB über. Modell und Views Die Beispiel-App verwendet das Modell CurrencyConverter mit datenbindungsfähigen Properties, welche über den Codebehind der Pages zur Verfügung gestellt werden. Der Code-behind dient dabei als DataContext, siehe Abbildung 4. Zentrale Eigenschaft des CurrencyConverter-Modells ist eine List(of Conversions). Der Code-behind der Conversion PivotPage mappt diese auf eine ObservableCollection (of SelectableConversion). Die PivotItems der ConversionPivotPage binden an diese über CollectionViewSources, mit denen sie die SelectableConversions sortieren und filtern. Die TextBox _amountfield ist via Zweiwegebindung (TwoWay) an die Eigenschaft Amount einer Conversion gebunden. Der CurrencyConverter berechnet bei Änderungen am Amount einer Conversion automatisch alle anderen Conver sions neu. Zum Lauschen auf Änderungen am Amount werden die Reactive Extensions [23] verwendet, siehe Listing 1. Dabei wird über Observable.Merge bei der ersten Änderung an einem Amount die Methode ConvertAll mittels eines Lambda-Ausdrucks aufgerufen. Die Reactive Extensions (Rx) sind eine Bibliothek zum Konstruieren von asynchronen und Event-basierten Program- Daniel Koch Magento Schritt für Schritt zum eigenen Online-Shop 320 Seiten; Flexibler Einband; 24,90; erscheint August 2012 ISBN: Mit durchgängigem Beispielprojekt Wie Sie mit Magento Ihren Shop aufbauen und optimieren Mit passenden Lösungen für einen nachhaltigen Erfolg Ihres Shops Jetzt direkt bestellen! Carl Hanser Verlag & Co. KG

5 Erfahrungen mit der Entwicklung von Windows-Phone-Apps Kein MVVM Vom Pattern Model-View-ViewModel (MVVM) verspricht man sich unter anderem folgende Vorteile: Separation of Concerns, lose Kopplung, Unterstützung von Datenbindung, bessere Zusammenarbeit von Designer und Developer, Wiederverwendbarkeit, Clean Code, konsistenten, wartbaren und skalierbaren Code, Unterstützung von Design-Time Data, Möglichkeit automatischer View-Tests, Möglichkeit mehrerer Views über derselben View-Logik. Viele dieser Vorteile resultieren eher aus sauberer Modularisierung im Allgemeinen oder aus dem Streben nach Clean Code. Bei genauerer Betrachtung bleiben von den unterstellten Vorteilen nur zwei übrig: die Möglichkeit automatischer View-Tests und die Unterstützung von Design-Time Data (siehe MVVM Backlash [26]). Bei Lösungen mit dem View-Code im Code-behind, statt in ViewModels, lässt sich dieser nicht automatisch mit Unit-Tests testen die restliche Funktionalität aber schon! Einerseits sind Unit-Tests natürlich immer nice to have, und ohne Unit-Tests wird eigentlich nötiges Refactoring von Code und Architektur meist unterlassen, sobald eine Anwendung produktiv läuft, weil man richtigerweise das Risiko unbedachter Seiteneffekte vermeiden möchte. Andererseits ist für jedes Projekt abzuwägen, ob der zusätzliche Aufwand für Unit-Tests zu rechtfertigen ist. Nach Erfahrung des Autors finden manuelle Tests durch Experten mehr Fehler als Unit-Tests, insbesondere kritische Fehler aus dem Zusammenspiel verschiedener Status und Anwendungsfälle, die Unit-Tests meist nicht aufdecken. Design-Time Data ist beim Gestalten der Benutzeroberfläche sehr hilfreich. Unterstützung von Design-Time Data bezieht sich im Kontext von MVVM darauf, dass die Designer in Visual Studio und Blend Code-behind nicht ausführen und dieser damit nicht als Quelle von Design-Time Data dienen kann. Auf diese Datenquelle kann man aber leicht verzichten, denn es gibt andere und bessere Quellen für Design-Time Data, mehr dazu unter Stolpersteine im kommenden zweiten Teil dieser Serie. Wer das MVVM-Pattern für eine Phone-App einsetzen möchte, dem sei empfohlen, sich auch das Ultra Light MVVM Framework von Jeremy Likness [27] und das von PRISM abgespeckte Calcium SDK [28] von Daniel Vaughan, dem Autor des Buches Windows Phone 7.5 Unleashed [29] anzusehen. Die Frameworks von Jeremy Likness sind insbesondere interessant, weil sie sich pragmatisch auf das Nötige beschränken und Vorhandenes nutzen, zum Beispiel verwendet er das zum Standard-.NET-Framework gehörende Managed Extensibility Framework (MEF) für Dependency Injection und Inversion of Control. Damit Sie vor lauter Framework-Spezifika nicht vergessen, worum es eigentlich geht, können Sie ein bisschen bei Rockford Lhotka zum Thema MVVM und zu Geschäftsobjekten nachlesen. Lhotka verwendet Rich Business Objects, die Geschäfts-, Validierungs- und Autorisierungslogik kapseln und Datenbindung unterstützen, im Unterschied zu sogenannten Anemic Objects. Listing 1 Lauschen auf Änderungen mit den Reactive Extensions (Rx). Observable.Merge(Conversions.Select(Function(c) Observable.FromEvent( Of PropertyChangedEventArgs)(c, "PropertyChanged"))).Where(Function(c) c.eventargs.propertyname = "Amount").Take(1).Subscribe( Sub(c) Dim changedconversion = CType(c.Sender, Conversion) FromCurrencyCode = changedconversion.currencycode FromAmount = changedconversion.amount ConvertAll() End Sub) men mittels ObservableCollections und LINQ-Abfrage-Operatoren. Mit Rx ergeben sich ungeahnte Möglichkeiten. Jedem.NET-Entwickler sei empfohlen, sich Rx einmal in Ruhe anzuschauen. Der Einsatz von Rx in der Beispiel-App mag etwas übertrieben sein der Autor wollte einfach einmal damit spielen und den Leser auf Rx aufmerksam machen. Alternativ zu Rx könnte man einen Eventhandler für alle Conversions registrieren, ein _isconverting-flag verwenden und im Notification Interceptor des PropertyWeaver Änderungen an Amounts während des Berechnens der Umrechnungen ignorieren. Oder man könnte anstelle der Zweiwege-Datenbindung im TextChanged-Event des _amount Field explizit die Umrechnung im CurrencyConverter anstoßen. Aber Vorsicht! Text Changed feuert wegen eines Bugs doppelt. Background Agents Background Agents ermöglichen es, Code auszuführen, während die App nicht läuft aber auch während sie läuft. Agents werden auf den kommenden Geräten mit geringerem Arbeitsspeicher (Low-Memory Devices) nicht unterstützt. Einen Agent erzeugt man am einfachsten, indem man in VS zu einer Solution ein Agent-Projekt hinzufügt und es referenziert. VS sorgt dabei automatisch für die richtigen Einträge in der Datei WMApp Tracing Ein Problem bei der Entwicklung mit Silverlight ist, dass Reihenfolge und Häufigkeit des Auftretens von Ereignissen kaum vorhersehbar sind wohl aber meist erklärbar, wenn auch erst im Nachhinein. Deshalb ist es, besonders am Anfang des Entwickelns, wichtig, zu tracen. Die Currencies-App verwendet Traces sogar für die Fehlerberichte auf dem Phone des Nutzers allerdings mit einem Tracer, der die Größe der Trace- Dateien begrenzt. Die Beispiel-App setzt eine abgespeckte Version dieses Tracers ein. Dabei ergänzt sie automatisch einen Zeitstempel, die Aufrufinformationen sowie die verstrichenen Millisekunden seit dem vorherigen Trace. Zum Ermitteln der Aufrufinformationen verwendet sie den Call Stack. Abbildung 4 zeigt einen Trace der Beispiel-App. Man sieht die Reihenfolge der Aktionen, wie lange sie gedauert haben und dass einige Events mehrfach ausgelöst wurden. Übrigens wird der.net-4.5-compiler endlich Aufrufinformationen wie MemberName und SourceLineNumber als optionale Parameter einschleusen, was eigene Trace-Komponenten einfacher und verbreitete Logger wie NLog und log4net deutlich schneller machen wird. Für gut lesbare Traces und Crash-Reports sollte man auf lange anonyme Methoden und Lambda-Expressions verzichten und stattdessen besser Methoden mit gut verständlichen Namen aufrufen was sich ja im Sinne von Clean Code sowieso empfiehlt

6 [Abb. 5] Zusammenspiel und Datenbindung von View und Modell. [Abb. 6] Trace mit Ressourcenverbrauch des Background-Task. Manifest.xml. Unter VB hat die dabei automatisch erzeugte Klasse Scheduled Agent leider einen Fehler: Der Konstruktor heißt Sub ScheduledAgent(), muss aber Sub New() heißen. Falls man das nicht korrigiert, hat es die fatale Folge, dass der Handler nicht für unbehandelte Ausnahmen registriert wird, was leicht dazu führen kann, dass das Phone OS den Agent deaktiviert, ohne dass der Entwickler dies je bemerkt. Background Agents unterstützen zwei Arten von scheduled Tasks: PeriodicTask und ResourceIntensiveTask. Diese unterliegen einigen Einschränkungen. PeriodicTasks haben folgende Restriktionen: sechs Megabyte Speicher-Limit, API-Einschränkungen, 25 Sekunden maximale Laufzeit. PeriodicTasks dürfen maximal sechs Megabyte Speicher beanspruchen. Deshalb sollten sie ihren Speicherbedarf minimieren. Überschreitet ein Task sein Limit, wird er vom Phone OS beendet und beim zweiten Verstoß gänzlich deaktiviert. Unter dem Debugger sind die Prüfungen des Speicherlimits und der maximalen Laufzeit ausgeschaltet. Die tatsächliche Speichernutzung eines Task kann man über DeviceStatus.ApplicationPeakMemoryUsage abfragen. Aber hier lauert eine schlecht dokumentierte, üble Falle: Unter dem Debugger zählt der Debugger selbst zum Memory Usage des Task. Mit Debugger verbraucht ein leerer Task bereits rund 3,5 Megabyte, ohne Debugger aber nur etwa 1,8 Megabyte. Unter dem Debugger scheint der Speicherbedarf eines Task bei nur einem Webrequest bereits grenzwertig zu sein, in Wahrheit hat man aber genügend Platz. Erschwerend kommt hinzu, dass sich der Speicherbedarf ohne Debugger schlecht ansehen lässt. Die Beispiel-App schreibt dazu eine Trace-Datei in den Isolated Storage. Alternativ kann man via Tile.Update in die Tile schreiben oder einen Toast anzeigen

7 Erfahrungen mit der Entwicklung von Windows-Phone-Apps Das Trace in Abbildung 6 zeigt den Ressourcenverbrauch des PeriodicTask der Beispiel-App (remaining=2,5 KB, elapsed=1074 ms). Viele Entwickler, leider auch der Autor selbst, haben stundenlang unnötigerweise versucht, ein Phantom- Problem zu lösen, weil sie meinten, ihr Task überschreite das Limit. PeriodicTasks dürfen pro Aufruf maximal 25 Sekunden laufen. Das ist eigentlich recht lange, wird aber bei Webaufrufen leicht eng, weil diese einen nicht dokumentierten Default-Timeout von etwa 20 Sekunden zu haben scheinen. Leider muss man einen einstellbaren Timeout selbst implementieren, siehe Webrequests im zweiten Artikel dieser Serie. Die Verwendung einiger APIs ist in Agents nicht erlaubt, darunter sind offensichtliche Funktionen wie Phone.Shell und weniger offensichtliche wie Phone. Scheduler. Ihr Aufruf führt entweder zu Laufzeitfehlern oder zur Ablehnung der App-Zertifizierung. Will man zum Beispiel zur Separation of Concerns auch die Registrierung eines Task via Phone.Sheduler in der Agent-DLL selbst realisieren, führt das zur Ablehnung der Zertifizierung, selbst wenn der Task das API nicht wirklich von sich aus nutzt, sondern nur referenziert. Ob ein Task verbotene APIs referenziert, kann man mit dem Marketplace Test Kit prüfen. Um solche Probleme zu vermeiden und damit der Task möglichst wenige Ressourcen braucht, muss man die Solution-Struktur entsprechend anpassen. Abbildung 7 zeigt die Struktur der Beispiel-App. Zur Veranschaulichung der Referenzhierarchie sind die Projekte nummeriert. Ein häufiger Anfängerfehler beim Codieren von Tasks ist es, NotifyComplete im synchronen Beginn einer Aktion zum Beispiel eines Webrequests aufzurufen statt am Ende der asynchronen Verarbeitung. Da Registrierungen von Tasks nach maximal 14 Tagen verfallen, empfiehlt es sich, diese bei jedem App-Start neu zu registrieren. Beim Registrieren können viele dokumentierte Fehler auftreten, die man explizit ignorieren muss. App/Agent-Synchronisation Falls App und Agent miteinander kommunizieren sollen, ist Vorsicht geboten! Microsofts Empfehlungen hierzu sind sehr strikt: For one-direction communication where the foreground application writes and the agent only reads, we recommend using an isolated storage file with a Mutex.... We recommend that you do not use IsolatedStorageSettings to communicate bet Listing 2 Synchronisation von App/Agent-Zugriffen auf Isolated-Storage- Dateien via Mutex. [Abb. 7] Für Background Agents optimierte Solutions-Struktur. Public Class IsolatedStorageFile Public Shared SerializationFormatter As SerializationFormatter = SerializationFormatter.Binary 'Beware! XmlSerializer cannot serialize TimeSpan 'Public Shared SerializationFormatter As SerializationFormatter = Threading '.SerializationFormatter.DataContract Private Const _timouttopreventblocking As Integer = 5 * 1000 Public Shared Sub WriteSynchronized(filePath As String, filecontent As Object) filepath = SetFileNameExtension(filePath) Dim mutex As New Mutex(False, filepath) Try If mutex.waitone(_timouttopreventblocking) Then Using isofile = IO.IsolatedStorage.IsolatedStorageFile.GetUserStoreForApplication(), isostream = isofile.openfile(filepath, FileMode.Create) Select Case SerializationFormatter Case SerializationFormatter.Binary SilverlightSerializer.Serialize(fileContent, isostream) Case SerializationFormatter.XML Dim serializer = New XmlSerializer(fileContent.GetType) serializer.serialize(isostream, filecontent) Case SerializationFormatter.DataContract Dim serializer = New DataContractSerializer(fileContent.GetType) serializer.writeobject(isostream, filecontent) End Select End Using Else 'This should never happen. The phone runtime even releases mutexes for aborted 'processes. But better safe than sorry! Dim ex As New ThreadStateException("Unable to acquire mutex for app/agent sync") Trace.Error(ex.Message) Throw ex End If Finally mutex.releasemutex() End Try End Sub Public Shared Function ReadSynchronized(Of contenttype)(filepath As String) As contenttype... End Function End Class

8 Unternehmensanwendungen Wie steht es eigentlich um Windows-Phone-Apps für Line-of-Business- Anwendungen (LOB)? Da Windows Phone stark auf Konsumenten ausgerichtet wurde, geriet der Aspekt der Nutzung in Unternehmen etwas in den Hintergrund der allgemeinen Aufmerksamkeit. Bezüglich Windows Phones in Unternehmen gilt es unter anderem die folgenden Punkte zu betrachten: Integration in die Standard-Office-Anwendungen, Business-Features der Phone-Hardware, Mobile Device Management, App-Verteilung. Windows-Phone-Geräte bieten eine gute Office-Suite mit Word, Excel, PowerPoint und insbesondere OneNote (siehe Microsofts Anti-BlackBerry- Werbevideo [30]). Die Integration mit Exchange und SharePoint funktioniert. Profithemen wie Mobile Device Management, VPN-Access et cetera überschreiten den Rahmen dieses Artikels. Wie sich die Integration von Windows 8 in Windows Phone [31] auf diese Themen auswirken wird, bleibt abzuwarten. Es könnte sein, dass Windows Phone gemeinsam mit Mobilgeräten anderer Plattformen wie ios und Android unter der Überschrift Bring your own Device behandelt wird. Es gibt Gerüchte zu Windows Phones mit Unternehmens-Features wie Keyboards à la BlackBerry. Für das Phone lässt sich prinzipiell jede LOB-App realisieren, die man sich nur vorstellen kann. Das Ausrollen von Unternehmensanwendungen erfolgt über den Marketplace mittels Targeted Distribution. Unternehmensspezifische App-Repositorien oder andere Wege, Apps auf die Phones eines Unternehmens zu bringen, gibt es derzeit nicht. Bei der Targeted Distribution durchlaufen Apps den üblichen MS-Zertifizierungsprozess, werden aber nicht auf dem Marketplace veröffentlicht. Die Nutzer können die Apps nur über Deep Links installieren, welche nur vom Phone aus verwendet werden können. Diese Links kann der Ersteller der App den Nutzern zum Beispiel via schicken. Apps müssen sich selbst vor unbefugter Nutzung schützen, weil jeder sie installieren kann, der ihren Deep Link kennt. ween processes because it is possible for the data to become corrupt. [24] In der Beispiel-App kommunizieren App und Agent über Isolated-Storage- Dateien: Die App konfiguriert den Agent über die Datei AgentSettings.bin. App und Agent speichern die aktuellen Umrechnungskurse in der Datei WebConversions. bin und den Zeitpunkt der Ermittlung in AgentState.bin. Die App pollt AgentState. bin, um neue Kurse zu entdecken. Ein Long Polling der App auf einen vom Agent blockierten Mutex lässt sich leider nicht implementieren, weil der Agent nur während seiner zyklischen Aufrufe lebt. Zur Synchronisation des Zugriffs auf die Dateien werden Mutexe verwendet, siehe Listing 2 und Abbildung 3. Für die Optimierung der Zugriffe auf die Dateien und des Speicherbedarfs wird statt des Standard-XML-Serializers der binäre Silverlight Serializer von Mike Talbot verwendet [25]. Außer zum Debuggen gibt es keinen Grund, das aufgeblähte XML- Format im Isolated Storage zu verwenden, nur weil es vom Menschen lesbar ist. Bei den recht kleinen Dateien der Beispiel- App unterscheiden sich die Schreib- und Lesezeiten zwischen XML- und Binär- Daten kaum, aber der Speicherbedarf ist binär deutlich kleiner: Für 90 Umrechnungskurse werden mit XML 14 Kilobyte belegt, binär lediglich ein Kilobyte. Fazit Alles in allem war die Entwicklung für das Windows Phone eher frustrierend: Alles dauerte viel länger als erwartet, trotz fundierter Erfahrung in.net und Grundwissen in WPF. Oft fühlte es sich eher an wie Rätselraten statt wie Geradeausprogrammieren. Aber dennoch bleibt als Resümee: Das Windows Phone OS ist super, die Entwicklungsumgebung sehr mächtig, und was.net und Silverlight auf so einem kleinen Gerät ermöglichen, ist schlichtweg begeisternd. Machen Sie doch mal einen Versuch! Im zweiten Teil dieser Artikelserie geht es weiter mit schnellem App-Start und App-Resume, asynchronen (Web-)Aufrufen, guter Fehlerbehandlung, vielen Stolpersteinen und dem Veröffentlichen von Windows-Phone-Apps. [bl] [1] Peter Meinl, Currencies App, [2] Paul Thurrott, Is Time Running Out for Windows Phone?, SL1209AppErfahrung2 [3] Aalto App Campus, [4] 37signals, Getting Real, [5] Simon Cropp, Notify Property Weaver, [6] CodePlex, Windows Phone Power Tools, [7] Jeff Wilcox, MetroGridHelper, [8] Balsamiq Mockups, UI Sketching Tool, [9] Silverlight for Windows Phone Toolkit, [10] Coding4Fun Toolkit for Windows Phone, [11] Phoney Tools, [12] Templarian, Icons, SL1209AppErfahrung6 [13] Peter Kuhn, Your Last About Dialog, [14] Microsoft, Bing Maps SDK, [15] Phone7.Fx BindableApplicationBar, [16] C#/VB Converter, [17] Microsoft, Creating Windows Phone 7 Application and Marketplace Icons, [18] bugsense, Bug Tracking, [19] Gibraltar, Monitoring, [20] Telerik, RadControls for Windows Phone, [21] PreEmptive, Analytics für App Analytics und Monitoring, [22] EQATEC, Analytics für App Profiling, [23] Microsoft, Reactive Extensions (Rx), [24] MSDN, Background Agent Best Practices for Windows Phone, SL1209AppErfahrung12 [25] Mike Talbot, Binary Silverlight Serializer, [26] Ward Bell, MVVM Backlash, [27] Jeremy Likness, Ultra Light MVVM for Windows Phone 7, [28] Daniel Vaughn, Calcium SDK, [29] D. Vaughn, Windows Phone 7.5 Unleashed, [30] Microsoft, How to use Windows Phone to do business on the road, SL1209AppErfahrung14 [31] techradar, Windows Phone 8: what you need to know, SL1209AppErfahrung