Erste Eindrücke und Schlüsse aus dem geleakten Windows Phone 8 SDK

Ich habe jetzt mal das kürzlich geleakte Windows Phone 8 SDK in der Developer Preview installiert. Nachdem ich auf meiner Entwicklungsmaschine momentan in einer virtuellen Maschine ausführe kann ich den Emulator des SDK nicht nutzen (dieser benötigt Hyper-V und das geht nicht innerhalb einer anderen VM).

Eines der ersten Dinge die mir auffielen war, dass abgesehen von den optischen Änderungen durch die Nutzung von Visual Studio 2012 statt Visual Studio 2010 die Änderungen nicht wirklich ins Auge springen.

Im UI-Designer fällt dann zumindest mal auf, dass sich beim Display alle verfügbaren Auflösungen auswählen lassen, damit man gleich mal ausprobieren kann ob das Layout sich auch vernünftig anpasst.

Am Code der Demo-Anwendung sieht man aber nicht wirklich Unterschiede zum bisherigen 7.1 SDK. Was liegt also näher als einfach mal ein bestehendes Windows Phone 7 Projekt zu öffnen und zu schauen was passiert? Also ConnectivityShortcuts 2.0 geöffnet, kompiliert - alles läuft fehlerfrei durch. Kein Wunder, denn das neue SDK unterstützt weiterhin auch das Erstellen von Anwendungen für Windows Phone 7.5. Was allerdings rausgefallen ist, ist die Möglichkeit Anwendungen für Geräte zu erstellen die Mango (Windows Phone 7.5) noch nicht installiert haben - ist aber verschmerzbar, nachdem diese ja inzwischen aus dem Marketplace ausgesperrt wurden.

In den Einstellungen des Projekts lässt sich dann die Anwendung so umstellen, dass sie zur Windows Phone 8 App wird. Nach einem Dialog, dass man diese Änderung nicht rückgängig machen kann ist Connectivity Shortcuts dann auch schon eine Windows Phone 8 App. Beim kompilieren taucht nun jedoch ein Fehler auf. An einer Stelle werden hier XNA-Funktionalitäten genutzt und das geht bei WP8-Apps nicht mehr. Nachdem die betreffende Codezeile geändert wurde läuft wieder alles problemlos. Vergleiche des Codes nach der Umwandlung auf WP8 zeigen kaum Unterschiede.

Vergleicht man das ganze jetzt mit eine Windows 8 App kommen bei letzterer hingegen ganz andere UI-Klassen zum Einsatz. Die meisten Zugriffe auf Platformfunktionalitäten finden sich bei Windows Phone im Namespace Microsoft.Phone, bei Windows 8 hingegen gibt es diesen Namespace nicht. Während Windows Phone ein paar neue Tasks mitbringt um Interaktionen mit z.B. dem Kalender zu ermöglichen setzt Windows 8 hier voll auf das Konzept des Share-Charms.

Kurz gesagt: die APIs von Windows Phone 8 entsprechen mit einigen Erweiterungen denen von Windows Phone 7.5. Die Ähnlichkeiten mit denen von Windows 8 ergeben sich hauptsächlich aus der .Net Basisbibliothek die beide Systeme nutzen. Damit haben WP7 und WP8 Apps deutlich mehr gemeinsam als WP8 Apps mit Windows 8 Apps.

Auch von der Möglichkeit Anwendungen mit HTML und JavaScript zu erstellen, wie dies in Windows 8 der Fall ist, ist im Preview SDK von WP8 nichts zu sehen.

Nachdem ja bisher davon ausgegangen wurde, dass die WinRT als Laufzeitumgebung auch auf WP8 Einzug halten würde finde zumindest ich das alles doch recht überraschend. Auf den ersten Blick wären mir auch keine großen Features aufgefallen die nicht bereits angekündigt wurden, jedoch habe ich bisher auch nur relativ oberflächlich gestöbert.

Edit: Gerade bin ich noch auf die Zugriffsmöglichkeiten auf den ExternalStorage - also die SD-Karte - gestossen. So wie es aussieht steht diese als ganzes dem Zugriff durch Apps offen, jedoch soweit ich das bisher sehe nur lesend. D.h. Apps können dort keine Daten hinschreiben.

Interessante Infos, Danke!

Keine sehr ermutigenden Info´s

Es sieht m.M.n doch recht gut aus

Mit der kostenlosen PocketPC.ch App von meinem Lumia 800 aus geschrieben.

Im Sinne einer Diskussion wäre jetzt ja meine Frage was ihr konkret positiv oder negativ daran seht?

Positiv: aufgrund der Ähnlichkeit der Anwendungen gibt es für bisherige Nutzer wohl recht gute Chancen dass Apps die die neuen Features nicht nutzen eben weiterhin auf WP7.5 abzielen werden. Nimmt man mal Spiele aus die auf Basis C++/Direct 3D entwickelt werden oder die einzelne C++ Funktionsblöcke aus Performancegründen nutzen.

Negativ: Der Portierungsaufwand zwischen WP8 und Windows 8 ist ähnlich groß wie der zwischen WP7 und Windows 8. Laut Microsoft bedeutet das bis zu 90% identen Code, jedoch sind die API Aufrufe anzupassen (bei manchen Apps die quasi nur ein neues UI für verschiedene APIs darstellen ist also relativ viel Code zu ändern). Hier wird wohl wieder mal gelten: wer seinen Code nach MVVM und schön modular aufgebaut hat wird relativ schnell portieren können, wer API Aufrufe mit dem UI Code vermischt hat, hat wohl hier jetzt Mehraufwand.

Wenn ich das jetzt richtig verstanden habe besteht ein Unterschied zwischen den Apps für WP und denen für Windows8 Da gerade im Tablet und Windows 8 Bereich die Chance auf eine erhöhte App Anzahl aufgrund der größeren Verbreitung besteht stellt sich mir die Frage ob die Entwickler dann die Apps auch für WP8 herausbringen wenn ein zusätzlicher Aufwand besteht die dafür zu portieren (oder liege ich jetzt falsch?)

Na ja, aus meiner Sicht macht es ohnehin keinen Sinn Tablet-Apps unverändert auf ein Smartphone zu bringen oder am Tablet einfach aufgeblasene Versionen der Smartphone-Apps anzubieten. Das ist ja meinem Verständnis nach auch eines der großen Handicaps die Android Tablets gegenüber dem iPad haben. Für letzteres steht eine sehr große Anzahl an angepassten Anwendungen bereit, die auf das größere Display ausgelegt sind. Ansonsten hängt es wie gesagt daran wie die Funktionalität der App selbst aussieht. Datenhandling, etc. wenn es richtig strukturiert ist sollte identisch nutzbar sein. Der Aufwand etwas von Windows 8 auf WP8 zu bringen ist in den meisten Fällen (Ausnahme HTML-Apps) jedenfalls deutlich geringer als der diese auf irgendein anderes System zu portieren. Apps die jedoch relativ stark auf den Share-Contracts aufbauen für ihre Funktionalität dürften es aus momentaner Sicht schwierig haben auf WP8.

Bzgl. Direct3D Spielen sieht die Sache anders aus, da hier ja mit C++ und Direct3D eben das neue Framework auf WP8 Einzug hält und wohl ziemlich ident sein dürfte (was zumindest die Spieler freuen dürfte).

Sorry StevieBallz, bin nicht so bewandert, aber heisst das (also die nur geringen Unterschiede zu WP7.5) nun, dass (als Beispiel) z.B. DropBox weiterhin aussen vor bleibt bezüglich Funktionalität, d.h. nur lesen und nicht schreiben? D.h. die Apps bleiben weiterhin "beschnitten" aufgrund fehlender API's oder was auch immer? Auch im Vergleich zum IPhone (bei Android geht ja fast alles...)?

Das mit dem nur Lesen und nicht schreiben bezieht sich jetzt zunächst mal nur auf die SD-Karte (External Storage). Bisher wäre ich aber auch noch über keine Möglichkeit gestolpert mit der es möglich wäre die Daten der eigenen App einer anderen App zu übergeben, abgesehen von fix definierten Interaktionspunkten (Klingelton hinzufügen, Bild in Bildergalerie speichern, Kontakt ins Telefonbuch aufnehmen, Neuen Kalendertermin erstellen).

Bei iOS ist es scheinbar (da hab ich keine praktische Erfahrung damit) so, dass eine App halt über URIs angeben kann was für einer anderen App sie Daten übergeben möchte. Das kann dann von einer beliebigen App implementiert sein. So kann dann z.B. die DropBox App Office Dokumente öffnen (auch wenn sie selbst diese nicht darstellen kann). Ob das in WP8 weiterhin nicht möglich sein wird oder ich da einfach nur noch nicht drübergestolpert bin (oder das einfach nur in dem geleakten SDK fehlt, weiß ja keiner wie alt das genau ist) kann ich jetzt nicht abschließend sagen.

Android sieht insofern anders aus, als dass dort ja ein ganz normales Dateisystem existiert und Apps dort relativ frei entscheiden können wo sie was hinschreiben (solange es nicht besonders geschützte Systemordner sind).

In einem Doku-File des SDK steht, dass es eine Möglichkeit gibt wie Apps Daten einander übergeben können, die der ähnelt die in iOS verwendet wird. Im Detail habe ich das noch nicht gesehen - Apps wie DropBox sollten damit aber eigentlich machbar sein.

Sind jetzt Apps wie TeamViewer möglich?
Und könnten Apps wie Facebook o.ä. theoretisch durch die neuen Möglichkeiten schneller werden?

Und das wichtigste : Gibt es Zugriff auf die API für eine Taschenlampen App ohne den bisherigen Umweg?

Wie meinst du das mit Teamviewer? Ob man das Handy fernsteuern kann oder ob man vom Handy aus fernsteuern kann? Rein prinzipiell gibt es schon einige Apps die RemoteDesktop Funktionalität in WP7.5 bereitstellen - das mit dem PC vom Handy via Teamviewer fernsteuern scheitert nur daran, dass die Jungs von Teamviewer keine App bauen (gehen würde es heute schon).

Wenns schneller wird dann wohl hauptsächlich durch die schnelleren neuen Geräte und durch Verbesserungen am Unterbau der Apps. Da soll ja jetzt angeblich das große .Net Framework drunter stecken - kann ich nicht verifizieren.

Zur Taschenlampe wäre mir momentan nichts aufgefallen, in die Richtung hab ich aber auch nicht wirklich nachgesehen.

Achso. Hatte das so im Kopf, das es heute noch nicht möglich wäre
Noch ne Sache die ich nicht ganz verstanden habe: Welche Vorteile bringt der Native Code?
"Nur" Geschwindigkeit?

Geschwindigkeit & einfachere Portierung von anderen Plattformen
Mit der kostenlosen PocketPC.ch App von meinem 7 Pro T7576 aus geschrieben.

Zitat von yeah

Welche Vorteile bringt der Native Code? "Nur" Geschwindigkeit?

1. Geschwindigkeit (insbesondere bei Spielen)
2. Einfachere Portierbarkeit von Spielen, Engines und sonstigen Apps, deren Code in C++ vorliegt

1. Geschwindigkeit (insbesondere bei Spielen)
2. Einfachere Portierbarkeit von Spielen, Engines und sonstigen Apps, deren Code in C++ vorliegt

Nicht zu vergessen, es wird bei gleicher Leistung weniger Strom verbraucht.

Hey wo kann ich denn das SDK downloaden? Das PW zum Microsoft Server funktioniert nicht

Mit der kostenlosen PocketPC.ch App von meinem Lumia 800 aus geschrieben.

Da gibts verschiedene Wege bei den XDAs: http://forum.xda-developers.com/show....php?t=1797700

Von dort habe ich schonmal über Torrent geladen, die geladenen Dateien waren aber irgendwie nicht verwendbar. Die installation unter Win8 in VMWare brach immer ab mit der Meldung, er würde Dateien für den Installer nicht finden.

In dem Paket sind mehrere Installer enthalten. Man muss den aus dem DVD-Ordner nehmen, sonst probiert er es von einem Netzwerkshare zu holen, den du in deinem Netzwerk dann natürlich nicht hast.

Weiters haben manche Leute Probleme beim entpacken, mit 7-Zip gehts jedenfalls problemlos.

Und das Thema Windows 8 in der VM ist beim SDK auch ein Problem, zumindest wenn man nicht einen entsprechend neuen Prozessor hat, denn der Emulator von WP8 benötigt Hyper-V und das geht als Virtualisierungsumgebung innerhalb einer anderen VM halt üblicherweise nicht.