Was die Offenheit des Systems angeht, orientiert sich Microsoft eher an Apples iPhone als an Googles Android. Hardwarehersteller können den Startbildschirm nicht durch eine eigene Oberfläche ersetzen. So kann etwa HTC seine bei vielen Nutzern beliebte Sense-Oberfläche nicht implementieren. Auch Startbildschirme für spezielle Einsatzgebiete, etwa in einer Autohalterung, lassen sich nicht realisieren.
Android erlaubt einen Austausch des Startbildschirms. So kann etwa HTC seine Sense-Oberfläche implementieren. Ebenso ist es möglich, vorübergehend einen „Launcher“ zu wählen, der unter bestimmten Bedingungen praktisch ist, beispielsweise im Auto.
Speicherkarten sind ebenfalls nicht zugelassen. Handyhersteller müssen mindestens 8 GByte Flashspeicher bereitstellen. Anwendungen gibt es nur über Microsofts eigenen Marketplace. Die Installation von anderen Quellen ist nicht möglich. Das Multitasking ist stark eingeschränkt und für ISVs kaum nutzbar. Wie liberal Microsoft die Aufnahme von Anwendungen in den Marketplace handhaben wird, muss sich erst zeigen. Apple weist etwa 20 Prozent der eingereichten Anwendungen für das iPhone zurück.
Für die Zukunft ist ein sogenanntes „Sideloading“ geplant. Es ermöglicht Firmen, selbst entwickelte Anwendungen für Firmentelefone auf einem Windows Phone 7 zu installieren. Wie das funktionieren soll, konnte Greg Sullivan gestern noch nicht sagen. Man darf aber davon ausgehen, dass es sich um eine Art geschlossene Benutzergruppe im Marketplace handeln wird.
Anwendungen dürfen Dritthersteller nur auf Basis von Silverlight und XNA mit Managed Code entwickeln. Native Applikationen sind nicht möglich. Für die meisten Apps ist eine Implementierung in Managed Code sinnvoll. Der Großteil aller Apps holt Informationen aus dem Internet und formatiert sie passend für die kleinen Bildschirme von Mobiltelefonen. Oft werden die Informationen für den Offline-Betrieb zwischengespeichert.
Es gibt aber Anwendungen, die nativ implementiert werden sollten. Dazu zählen beispielsweise Adobe Flash oder ein alternativer Browser wie Opera Mobile. Letzteres will Microsoft allerdings ohnehin nicht erlauben. Eventuell werden Wettbewerbshüter diese Pläne jedoch durchkreuzen. Auch ein Navigationsprogramm für Autofahrer, wie es Google für Android-Handys kostenlos bereitstellt, dürfte als native Anwendung besser performen. Adobe hat offensichtlich eine Ausnahmegenehmigung erhalten, um Flash für Windows Phone 7 zu entwickeln. Bereits heute ist bekannt, dass Flash zum Marktstart noch nicht verfügbar sein wird.
Neueste Kommentare
6 Kommentare zu Windows Phone 7: schnell wie Android, proprietärer als iOS
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
falsches Konzept
Ich habe win mobile schon benutzt als es noch "CE" hieß.
Aber das jetzige Konzept empfinde ich als unzumutbar.
Keine veränderbare Oberfläche. Keine nativen Programme. Keine Speicherkartenslots. Nur der Marketplace. Bechränktes Multitasking
Das sind alles Unverschämtheiten. Und diese Hub-Oberfläche ist mir extrem unsympatisch.
Mein nächstes Smartphone wird definitiv Android sein.
Microsoft wird im Smartphone-Sektor untergehen.
Telefon
Klasse das neue SmartPhone.
kann man damit auch telefonieren ;) – wurde nicht gezeigt?
Wie sieht es aus mit (selbst erstellten) Checklisten?
Was ist mit Zeitmanagement – Outlooksync – Termine anlegen einfach kopieren, etc..Spracheingabe für eMails?
Der ganze WebCram ist zwar schön, aber privat unbezahlbar – es sein denn man schmeißt sein Telefon und DSL-Anschluss zu Hause weg und macht nur noch alles mit dem Handy + Flatrate. Bei dem Tarif-Dschungel werde ich nie ein Handy online nutzen (es sei denn ich bräuchte es mal geschäftlich).
iOS nutzt kein Java
iOS verwendet als einzige und alleinige Programmiersprachen C, C++, JavaScript und Objective-C, wobei letztere die "Hauptspache" ist und sich drastisch von Java, C# und C++ unterscheidet. Es ist ja (je nach Lesart der Lizenzbedingungen) noch nicht mal erlaubt, ein etwa in Java geschriebenes Programm für iOS zu cross-compilieren, was das Übersetzen von oder nach Android enorm erschwert.
Managed Code ist gut
Ich verstehe die Abneigung gegenüber Managed Code nicht. Managed Code erhöht drastisch die Sicherheit, weil per Design alles in einer Sandbox läuft und Buffer-Overflows kaum möglich sind. Auch in Sachen Performance stehen Java/C# den nativen Applikationen kaum nach, zu mal man Managed Code ja auch nativ kompiliert laufen lassen kann.
Aus meiner Sicht wird Managed Code deutlich wichtiger in der Zukunft.
AW: Managed Code ist gut
Da gebe ich Ihnen völlig recht. Es gibt überhaupt keinen Grund, Abneigung gegen Managed Code zu haben. Mal abgesehen von der faktischen Unmöglichkeit, versehentlich Memory-Leaks oder Sicherheitslücken durch Buffer-Overflows zu erzeugen, lassen sich mit Managed Code Anwendungen sehr viel schneller erstellen (geringe Entwicklungszeit) , als das etwa in C oder C++ der Fall ist.
Sollten wenige Performance-Bottlenecks auftreten, dann kann man einige kleine Routinen immer noch in C oder gar Assembler entwicklen.
Problematisch ist aber, nur Managed-Code-Programme zu erlauben, da existierende native Anwendungen nur schwer portiert werden können. So hat Mozilla sein Fennec (=Firefox für Smartphone) für Windows Phone 7 wieder eingestellt, weil die Mozilla Codebase als nativer C-Code vorliegt.
Ein Verbot für native Anwendungen kommt viel zu früh, da
1) existierende Native-Code-Software (Flash, Fennec, Opera Mobile, SQLite, MySQL, etc.) nur schwer portiert werden kann.
2) Mit Java und .NET zwei unterschiedliche Managed-Code-Modelle vorliegen. MS sollte Visual J# wieder aufnehmen, um Java-Source in .NET-Bytecode zu übersetzen. Das würde Portierungen erleichtern.
Android macht mit Dalvik übrigens auch keinen Java-Bytecode. Es übersetzt zwar erst Java-Source-Code in Java-Bytecode. Der wird anschließend mit dem Assembler dx in Dalvik-Bytecode übersetzt, der wie native Prozessorbefehlssätze registerbasiert und nicht LIFO-Stack-basiert (Kellerautomat) ist wie Java-Bytecode. So ergibt sich eine schnellere Ausführungsgeschwindigkeit.
AW: AW: Managed Code ist gut
Eins der größten Probleme von Windows ist die Verpflichtung alles an Legacy mitzunehmen. Ohne diese Backward-Compatibility wäre das Betriebsystem heute schon sehr viel weiter als es ist.
Jetzt entscheided sich MS ein klaren Schnitt im Telefonbereich zu machen und wieder soll das nicht gut sein? Übergänge tun weh, ja. Aber diese Entscheidung ist richtig.