Karsten Samaschke: Los jetzt!

Das Slidedeck von meiner Session auf der VS One zum Thema “WP7 Jumpstart” kann jetzt heruntergeladen werden.

Danke an alle Teilnehmer für die Aufmerksamkeit und die interessanten Fragen.

Hier gibt es den Download.

Äußerst spannende Zeiten, in denen wir gerade leben: Nokia wirft alle seine Pläne über den Haufen und bildet mit Microsoft eine strategische Partnerschaft. Wir haben das gestern und in den Tagen davor schon diskutiert, aber jetzt, wo es offiziell ist, kann ich eigentlich nur sagen: Wow.

Hier die wichtigsten Punkte aus dem offiziellen Announcement:

• Windows Phone wird Nokias primäre Smartphone-Plattform
• Bing wird die offizielle Suche auf allen Nokia-Geräten
• Microsoft adCenter wird der offizielle Werbevermarkter auf allen Nokia-Geräten
• Nokia Maps und Bing Maps werden integriert (Vermutung: Kostenlose Navigation auf allen Nokia-Geräten)
• Nokia und Microsoft kollaborieren bei der Abrechnung über Telekommunikationsprovider für Käufe im Marketplace (d.h.: Nicht nur Abrechnung per Kreditkarte)
• Software für Nokia-Windows Phone-Geräte wird mit Visual Studio entwickelt (klaro, #WP7-Entwicklung findet mit dem Visual Studio statt)
• Nokias Store wird mit dem Marketplace integriert (ich vermute: Analog zum HTC-Store und den anderen herstellerspezifischen Stores im Marketplace, nur wird der Umfang wohl deutlich größer sein)

Was bedeutet das jetzt für den Endanwender? Ganz einfach: Windows Phone wird das Betriebssystem der allermeisten Nokia Smartphones werden. Einfacher hat man ein Nokia-Gerät noch nie bedient. Die Synchronisation läuft über Zune, alle wesentlichen Daten sind in der Cloud gespeichert und damit immer und überall verfügbar.

Nokia erschließt sich mit Zune und den Diensten von Microsoft ein komplettes Ökosystem, während Microsoft Windows Phone mit einem Schlag als eine der größten Plattformen im Smartphone-Bereich etablieren kann (vielleicht noch nicht heute, aber mittelfristig). Dazu kommt, dass die Entwicklung für Windows Phone um ein vielfaches einfacher ist, als für Symbian. Applikationen landen schneller im Marketplace, es gibt viel, viel mehr Entwickler, die Software schreiben können und wollen.

Das sind letztlich absolut rosige Aussichten für beide Seiten. Und natürlich auch für mich, allein schon, weil ich auf der #WP7-Plattform entwickle und Windows Phone-Schulungen gebe.

Ich bin begeistert.

Der Kollege Erle hat auf der WorldOfPPC ein sehr wohlwollendes Review zu g.news veröffentlicht – und wer ihn kennt, der weiß, dass der Kollege Erle um ein klares und deutliches Wort nie verlegen ist.

Ein paar Worte aus dem Inhalt:

Für Windows Phone 7 existiert mit g.news eine der komfortabelsten Lösungen aller Plattformen…

g.news ist extrem performant, vom Laden über das Aufrufen von Artikeln, das Navigieren in der Web-Ansicht, alles ist so butterweich wie die Windows Phone 7-Oberfläche selbst.

Aber er wünscht sich auch noch mehr für die Zukunft:

Wünschenswert wäre noch – wie bei vielen Applikationen – die Unterstützung von Live-Tiles und damit die Anzeige der Zahl der neuen Beiträge direkt auf dem Startbildschirm von Windows Phone 7

Dazu sei gesagt: Ja, doch, ich arbeite dran.

Das komplette Review findet man hier, g.news selbst kann man hier herunterladen und installieren.

Windows Phone 7-Applikationen werden über den Marketplace vertrieben, alternativ kann man das XAP-Archiv anderen Leuten direkt schicken und diese können es auf ihr Entwickler-Gerät selbst aufspielen. Hat jemand das XAP-Archiv erhalten, lauert eine böse Falle: Der Code im XAP-Archiv kann mit gängigen Dekompilierungstools wieder in eine lesbare Form überführt werden. Dies kann man als Entwickler verhindern, wenn man einen Obfuskator einsetzt.

Obfuskatoren haben die Aufgabe, den Code voll ausführbar zu belassen, ihn aber in seiner Struktur so zu verändern, dass ein Dekompilierungstool scheitert oder zumindest unverständlichen und unlesbaren Quellcode zurück übersetzt. Microsoft hat bereits im November ein Angebot mit der Firma Preemptive aufgelegt, dass es WP7-Entwicklern erlaubt, einen Obfuskator zumindest bis Ende März 2011 kostenlos und anschließend zu einem sehr geringen monatlichen Satz – im Gespräch sind maximal 10,00$ / Monat – zu nutzen.

Um diesen Obfuskator verwenden zu können, muss man sich auf der Preemptive-Webseite unter der Adresse http://www.preemptive.com/windowsphone7.html für den Download des Dotfuscators für Windows Phone 7 registrieren.

Anschließend bekommt man eine E-Mail mit allen benötigten Informationen für Download und Lizensierung des Produkts zugesandt.

Nach der Installation kann der Dotfuscator entweder über das Tools-Menü im Visual Studio oder als alleinstehende Applikation über Start > PreEmptive Solutions > Dotfuscator Windows Phone Edition > Dotfuscator gestartet werden. Beim ersten Start gilt es, die Lizenzbedingungen anzunehmen.

Anschließend startet eine sehr aufgeräumte Oberfläche, in der man alle wesentlichen Einstellungen vornehmen kann. Es empfiehlt sich, zunächst im Reiter Settings das Ausgabeverzeichnis für das bearbeitete XAP-Archiv festzulegen.

Nun kann im Reiter Input das zu verschlüsselnde XAP-Archiv ausgewählt werden.

Dies geschieht, indem man auf das Öffnen-Symbol im Bereich Input Files klickt und im sich öffnenden Dialog das gewünschte XAP-Archiv auswählt.

Damit sind alle Einstellungen komplett und die Verschlüsselung kann vorgenommen werden. Zu diesem Zweck muss lediglich auf das kleine grüne Pfeil-Symbol in der oberen Toolbar geklickt werden, der Rest erfolgt komplett automatisch. Sobald der Build-Prozess abgeschlossen ist, befinden sich die obfuskierten Dateien im Ordner, der in den Einstellungen festgelegt worden ist.

Zuletzt sei noch erwähnt, dass man die Einstellungen für das aktuelle Projekt speichern kann – Dotfuscator ist dann in der Lage, diese beim nächsten Lauf wieder zu verwenden.

Also: Dotfuscator verwenden, Code verschlüsseln, beruhigt schlafen.

Gestern abend habe ich ab 20.30 Uhr einen Live-Webcast für die Online UG gehalten. Hat Spaß gemacht, war viel, aber ich mache das sehr gerne wieder.

Die Codes und Slides können hier heruntergeladen werden.

Einer der Gründe, warum es im letzten halben Jahr hier so still war (neben Familie, Arbeitsstress, Büchern, etc.), ist, dass ich seit Anfang Oktober für Microsoft die Windows Phone 7 Code Camps und Windows Phone 7 ISV-Workshops durchgeführt habe.

Erstmal: Es hat unwahrscheinlich Spaß gemacht – die Teilnehmer waren wahnsinnig interessiert, sehr kritisch und gleichzeitig sehr offen und konstruktiv. Wir haben alle zusammen – so denke ich – viel gelernt und viel Spaß gehabt. Von meiner Seite aus kann es da gerne eine Fortsetzung geben…

Die Slides und Folien der beiden Veranstaltungen habe ich zum Download bereit gestellt – wo genau, diese Information gibt es auf der wpzone, einem weiteren Grund, warum es so still war. Die wpzone ist ein Communityprojekt rund um Windows Phone 7 und möchte Ein- und Umsteigern Tipps, Hinweise und Ratschläge geben. Zu diesem Zweck gibt es ein Forum, einen Feed-Aggregator, einen Twitter-Aggregator und viele gute Menschen hinter dem Projekt.

Hier geht es zur wpzone, hier findet man auch das Announcement für die Folien. Und hier, hier geht es dann ab sofort auch immer mal wieder weiter.

Ich weiß: Multitasking / Backgrounding ist für viele Smartphone-User DAS Feature schlechthin. Aber irgendwie bin ich mir nicht sicher: Muss eine Nicht-Musikplayer/Nicht-Foto-Upload-Applikation echt im Hintergrund weiterlaufen? Oder reichen nicht auch die verschiedenen Push-Notification-Mechanismen für 95% aller Applikationen völlig aus?

Ich sehe es immer wieder bei Windows Mobile und bei Android, wie die Systeme langsamer und langsamer werden, weil Applikationen eben nicht beendet werden. Diverse Faktoren (mangelnde Prozessorleistung, mangelnder Speicherplatz, komplett andere Nutzungsszenarien der mobilen Geräte im Vergleich mit dem Desktop und letztlich das nahezu überall verfügbare mobile Internet), legen doch eigentlich nahe, dass uneingeschränktes Multitasking und Backgrounding auf mobilen Gadgets für den Großteil der Benutzer und den Großteil der Applikationen unwichtiger und verzichtbarer wird.

Was ich mir vorstelle – und vielleicht kommt es ja eher so, als man denkt – wäre ein intelligenterer, zweigeteilter Ansatz bezogen auf Backgrounding- / Multitasking-Szenarien:

1. Die normalen Wald-Feld-und-Wiesen-Applikationen, die kein Multitasking benötigen, bekommen auch keines. Dies sollte das Standardverhalten eines mobilen Systems sein und kann ja mit Hilfe von Push-Notifications und/oder der Auslagerung von aufwändigen Prozessen auf einen Server auch umgangen werden.
2. Applikationen, die unbedingt auf echtes Multitasking angewiesen sind, bekommen diese Funktionalität auch zugewiesen und können somit im Background weiterlaufen – etwa Musikplayer, Browser, Upload-Tools. Im Gegenzug behält sich jedoch der Gatekeeper eine wesentlich gründlichere Überprüfung des Laufverhaltens dieser Applikationen vor – um eben die befürchteten Probleme hinsichtlich Akkuverbrauch, Performance und Skalierbarkeit der kleinen Gadgets in Grenzen zu halten.

Damit ließen sich dann eigentlich alle Probleme auf einen Schlag ausschalten – Multitasking / Backgrounding wird für Applikationen, die es benötigen, möglich und alle anderen Applikationen laufen genau so weiter (auch hinsichtlich limitierender Faktoren), wie es vom Gatekeeper, dem Benutzer und dem Entwickler erwartet wird.