Inzwischen ist die MIX-Konferenz bereits wieder Geschichte, aus meiner Sicht jedoch sehr interessante Geschichte. Ich habe enorm viel gelernt und den einen oder anderen sehr interessanten Menschen kennen gelernt.

Hier nun die letzten Fakten zu Windows Phone 7 Series, die ich – wie die letzten Male auch – direkt wieder aus meiner Twitter-Timeline klaue:

• Performance beginnt schon beim Designer. Nicht erst beim Entwickler.
• Fixed Width / Fixed Height bei Listen ist derzeit optimal. Data Virtualization (lade nur das, was Du brauchst).
• 30 Frames / Sekunde für Animationen / Video / etc.
• Application.Current.Host.Settings.EnableFrameRateCounter – kann genutzt werden, um Performance zu messen.
• Application.Current.Host.Settings.EnableRedrawRegions – Feststellen, was wann wie wo neu gezeichnet werden muss.
• BitmapCache einschalten steigert Performance.
• Gerade die Animationen können extrem performancehungrig werden. Sollte man sich tatsächlich mal in Ruhe irgendwo anschauen.
• CacheModes sollten nicht gemischt werden – CacheMode="None" innerhalb von CacheMode="BitmapCache"-Elementen ist extrem unperformant.
• Media mit geringstmöglicher Framerate codieren – sehr aufwändig zu rendern.
• Auch bei MediaElement: CacheMode="BitmapCache" setzen.
• Media-Decoding + PNG-Handling stets hardwarebasiert, JPG-Handling KANN hardwarebasiert stattfinden.
• Hardware-Beschleunigung nur für Elemente bis max 2.048×2.048 Pixeln. Alles, was größer ist, muss per Software "beschleunigt" werden.
• Wichtig: Applikationen laufen nur mit gültiger License
• Code ist signiert
• Applikationen können nur Ressourcen ansprechen, für die sie freigegeben sind, wird zur Laufzeit überprüft.
• Klare Aussage: "Echte Programme" (C++) wird es nicht auf der Plattform geben.
• Push-Notification-Tokens bleiben auch beim Pausieren gültig. App muss sich also noch dem Pausieren nicht neu registrieren.
• Keine DLLs übers Netz nachladbar. Nur signierter Code wird ausgeführt. Signierter Code kommt nur über den Marketplace.
• Find & Wipe-Remote-Service existiert.
• MyPhone-Service setzt Find & Wipe-Remote-Service um
• Updates für das Gerät werden von MS bereitgestellt, es wird aber keine Patch-Tuesdays geben. Also eher analog zu #iPhone.
• Marketplace kann mehr, als bisher bekannt – es wird wohl Szenarios rund um geschlossene Benutzergruppen o.ä. geben.
• Featured-App kontrolliert den Hintergrund des Marketplaces.
• Suche funktioniert natürlich auch im Marketplace.
• Apps in der Regel innerhalb von 5 Tagen verfügbar, klare Aussagen über Timelines, Dokus ab Mai für Windows Phone aktualisiert.
• Applikation wird von Microsoft auf benötigte Schnittstellen geprüft und mit einem Manifest versehen.
• Applikationen / Käufe sind an die Live-ID gebunden, bis zu fünf Geräte parallel mit einer ID einsetzbar.
• Kein Nexus von Microsoft geplant. MS verkauft weiterhin keine Entwickler-Phones.
• Kein Buy once – Play everywhere (XBox-Spiel kaufen und auf WP7S spielen) derzeit, vielleicht zukünftig.
• XNA ist C#-only, Managed Code only.
• Silverlight: Wenn Vektorgrafiken, XNA: Wenn 3D-Grafiken. Mal ganz pauschal gesagt.
• Konfigurierbare Standardeffekte, keine Custom Shaders. #XNA
• Zugriff auf Audio, Video und Photos via #XNA-Framework. Nicht nur Chooser notwendig, wenn ich das richtig verstanden habe.
• Zwei Profile bei #XNA: Reach (möglichst kompatibel für alle Plattformen) oder HiDef (spezifisch nur für eine Plattform).
• Derzeit nur Entwicklung mit C#. VB kommt (vielleicht) später nach. #MIX10
• Allgemein: class statt struct, struct nur für Dinge, die kleiner 16 Bytes sind
• GC ist teuer. Zwei Strategien: Seltener laufen lassen (Objekte < 1MB). Oder: Schnell fertig werden lassen (ValueTypes verwenden).
• GC: Weniger Referenzen. Nur Objekte, wo notwendig. Weniger Listen, mehr Arrays.
• GC manuell aufrufen: GC.Collect() – bitte nicht so oft. Teuer. Idealerweise nur nach dem Load oder in Pausen.
• Boxing vermeiden. StringBuilder statt String. GC per WeakReference-Klasse überprüfen. CLR-Profiler verwenden (#XNA). .NET Reflektor.
• foreach-Statement ist okay, darauf achten, dass der Enumerator ein primitiver Typ ist.
• yield-Statement verwenden – wird zu einem Zustandsautomaten kompiliert.
• Best practices für mobiles Web: Weniger Farben und Schriften, weniger JS, keine Backgrounds, Content an Screengröße anpassen. Kleine Bilder.
• Best practices für mobiles Web (II): So wenig als möglich Input, sinnvolle Vorgaben, Cookies für Eingaben verwenden.
• Entwicklung für mobiles Web: Standards verwenden (XHTML, HTML 4.01, XHTML-MP), CSS 2.1, DOM 1, ECMAScript3. DOCTYPE setzen.
• Entwicklung für mobiles Web: Standard-Medientypen (JPEG, GIF, PNG, 3GP, AVI, WMV, MP4) verwenden. Keine Frames!
• Entwicklung für mobiles Web: Keine Table-Layouts, keine nested Tables, keine Image-Maps, kein Flash.
• Entwicklung für mobiles Web: Mobile-META-Tags verwenden: HandheldFriendly, MobileOptimized, Viewport.
• Standard-Viewport für #WP7S: 1024px.
• Entwicklung für mobiles Web: JS im Client für Fähigkeiten verwenden, UserAgent auf dem Server nutzen
• Entwicklung für mobiles Web: Bei Codeplex mal nach #MBDF schauen – UserAgents und deren Fähigkeiten auswerten. BrowsCap 2.0?
• IE7 + Features: getElementsByClassName, .querySelector, .querySelectorAll, Viewport, XHTML-Handling.
• Viewport-Settings: width, height, user-scalable implementiert, minimum-scale, maximum-scale und initial-scale nicht implementiert.
• CSS-Props: -ms-text-size-adjust, -webkit-text-size-adjust implementiert. Fixed positioning: Hängt am Dok., nicht am Window.

So, das waren dann alle Informationen, die ich auf der MIX gesammelt und für bloggenswert befunden habe.