Gerade bekomme eine Mail von Cyberport in der für 375 Euro das HTC Touch 3G beworben wird. Mich jucken WinMobile Lösungen eigentlich nicht sonderlich, aber das sieht doch alles schon recht interessant von der Aufmachung aus.

Hat einer hier Erfahrungen mit dem Ding? Oder ist das nur Mist in einer schönen Verpackung? Und bitte neutrale und faire Beurteilungen. Nicht nur: "Schrott! iPhone rules."


Hier der Link zur HTC Seite:

eh net. iPhone is halt von Apple und die Leute wollen Apple und keine "no name" Marke

also das hört sich alles sehr dubios an... 10-15x schneller... komsich das in keinem test safari schlecht abschneidet... normalerweise, die test die ich gesehen habe, ist safari immer am schnellsten, es gab nur einmal ein pat... ich erinnere aber nicht mehr welcher browser und welches smartphone das war, aber es war ein seriöser test...

man kann viel erzählen, aber beweise sind nunmal trumpf...

ich habe gerade mal auf youtbe geschaut, da gibt es schon 1:1 vergleiche, iphone safari gegen opera auf HTC touch, und safari ist nicht langsamer...! also hat 0wunder "wunder"bares angepriesen...

Das HTC Touch ist mit Bestimmtheit ein iPhone-Killer.

Man muss nur das iPhone auf den Boden legen, den HTC aus ca. 8 Meter höhe exakt mit der Kante aufs iPhone Display fallen lassen ..... killaaaaaarrr.

Die offenen APIs für Windows Mobile haben noch nicht zu Malware geführt. Dieses Argument zieht nicht.
Für mich sind die offenen APIs der einzige echte Vorteil gegenüber dem iPhone OS. Mit offenen APIs meine ich auch die Sandboxen - das ist nun wirklich der allergrößte Schwachsinn im iPhone OS - dass die Applikationen keine Informationen untereinander austauschen können, nicht mal per Klemmbrett.

Aber die Vorteile überwiegen für mich, darum nutze ich kein Windows Mobile mehr.

silvio Schwachsinn ist doch höchstens was Du nach 1 Jahr vom iPhone SDK erwartest.

Gib Apple mal Zeit, meinst Du denen ist nicht klar das Clipboard, gemeinsamer Anwendungsbereich, etc. auf Dauer notwendig sind?

Was konnten denn Windows CE 2.0 oder die ersten S60 SDKs?

@Garp2000 - auch wenn Du da durchaus Recht hast, der Vergleich hinkt dennoch.

Als es Windows CE2 gab und die ersten PocketPC kamen, da gab es im Grunde nichts anderes in dieser Richtung. Es war etwas neues - ein neuer Ansatz einen "ganzen" PC in die Jackentasche zu stecken. (Ich weiß - jetzt wird jemand in den Geschichtsbüchern wühlen und schon ältere Ansätze finden - aber ich hoffe, es wird klar was ich meine)

Apple kommt mit dem iPhone auf einen Markt, der sich über viele Jahre entwickelt hat. Bestimmte Dinge werden Heute einfach voraus gesetzt und schmerzlich vermisst, wenn sie nicht vorhanden sind.

Es ist dennoch erstaunlich mit welcher Zielstrebigkeit Apple mit dem iPhone an den Start gegangen ist. Quasi mit der ersten Version einen wirklich benutzbaren (mehr als das) Treffer gelandet. Das hat kaum jemand vorher so kompromisslos geschafft.

Man muss auch sagen, dass die Entwicklungsumgebung (die ja dann doch recht schnell kam) schon komfortabler ist als das, was bei den ersten WindowsCE-Geräten so möglich war. Hier ist es zwar inzwischen mit .Net CompactFramework nochmal deutlich simpler als beim iPhone mit XCode/Cocoa aber zu welchem Preis?

Ja - normale Business-Anwendungen lassen sich mit .NetCF verdammt einfach und extrem schnell schreiben. Sie sehen allerdings immer wie kleine Desktop-Anwendungen aus und lassen sich auch genau so bedienen. Das ist zwar für viele Nicht-Computer-Freaks ein Vorteil - macht die Bedienung aber auch extrem schwierig (kleine scrollbars, Buttons mit Finger teils schwer zu bedienen etc.). Der Grund ist die Philosophie dahinter:

MS hat entschieden, für die Kompakten Geräte ein möglichst identisches Set an Controls zur Verfügung zu stellen. Der Quellcode soll im Grunde austauschbar sein, die Bedienung soll sich so wenig wie möglich unterscheiden.
Apple hat entschieden, dass man Software an einem kleinen Bildschirm ganz anders bedienen möchte wie an einem Großen. Es wurde also ein Satz mit komplett neuen Controls geschaffen. Man hat sogar an das Mausrad gedacht: Einfach irgendwo in eine Liste hinein patschen und den Finger bewegen. Das wird bei WindowsCE im .NetCF so bald nicht möglich sein - Prinzip bedingt. Man nimmt dabei bei Apple in Kauf, dass ein Quellcode nicht so sehr austauschbar ist weil diese neuen Controls etwas anders mit Daten gefüttert werden möchten und als IBOutlet auch etwas anders deklariert werden müssen. Es gibt eben z.B. ein UILabel und ein UITextField - am Desktop nutzt man u.U. für beide Fälle ein TextField das aber NSTextField heißt und viel mehr kann (z.B. einfach Objekte entgegen Nehmen um deren Display-Inhalt zu zeigen und andere Späße).

.NetCF hingegen zeigt wieder wie MS tickt. Man hat also ein WindowsCE (ein abgespecktes Windows) welches in C/C++ programmiert werden kann. Nun packt man oben drauf, wie beim Desktop, ein Framework. Das besteht u.a. aus einem Control-Set, einem compiler etc. Es ist nicht direkt eine RunTime wie früher mit VisualBasic - aber vom Grundverständnis her vergleichbar - nur komplizierter. Die Runtime war eine(!) DLL - das .Net(CF) sind zig Dateien. Dieses Framework soll es ermöglichen, einfacher und schneller zu entwickeln und auch mit verschiedenen Programmiersprachen arbeiten zu können etc.

Der Haken:
- Jedes .Net Programm wird beim ersten Ausführen erst einmal "interpretiert" und es wird ein binärcode für den aktuellen Prozessor erstellt - im Speicher. Es gibt Wege um dies vorweg zu nehmen am Desktop aber IMHO nicht beim CompactFramework. Durch diese Umwege (das .Net muss ja auch erst geladen werden) sind die .Net-Programme fast immer verdammt träge. .Net(CF) kann verdammt schnell sein - es kann schnell rechnen, Daten sortieren etc. Aber alles was mit GUI zu tun hat.... Du meine Güte. Am PocketPC eine Anwendung mit mehreren Formularen starten? Formulare auf denen mal ein paar mehr Eingabefelder und Buttons drauf sind? Da muss man schon ziemlich tricksen.

Interessanterweise wird beim iPhone auch getrickst Da werden Screenshots der Anwendung beim starten angezeigt obwohl das Programm noch gar nicht fertig geladen ist etc. Dennoch scheint es der sauberere Ansatz zu sein ein Binärfile für das Zielsystem zu erzeugen - ohne sich noch Gedanken um ein "Runtime" machen zu müssen.


Ach übrigens: MS hatte mit .Net(CF) auch propagiert, dass nun endlich Schluss wäre mit Plattformabhängigkeit und Versionsabhängigkeit. Ein .Net(CF) Programm sollte auf jeder Plattform laufen können (wenn sie .Net(CF) unterstützt) und alte Programme auch auf neuen System laufen können etc.
Pustekuchen
Plattformunabhängig bedeutet bei MS: Windows2000/XP/Vista in den div. Spielarten. Toll - das ging mit EXE-Dateien auch schon.
Und zumindest am PocketPC gilt: Alte .NetCF Programme (mit .NetCF 1.x entwickelt) laufen u.U. nicht mehr auf neuen WM-Geräten auf denen .NetCF 2.x installiert ist. Man kann (wenn man es noch findet für das Gerät) ein altes .NetCF 1.x dazu installieren man hat ja auch immer genug Platz auf diesen Geräten...


Dennoch ist WindowsMobile für Software-Firmen interessanter. Ich habe mich jetzt als iPhone-Entwickler registriert - mein lieber Scholli. Und "mal eben" einen Entwicklungsstand auf einem anderen Gerät zeigen? Geht so erstmal nicht. Ginge vielleicht besser mit dem 250,-/Jahr Programm für Firmen aber auch da gibt es strenge Regeln einzuhalten damit es dann möglich wird die Software an eigene Kunden zu verteilen ohne über den AppleStore gehen zu müssen. Das alles schreckt (noch) ab was ich gut verstehen kann.
Kommt noch hinzu, dass viele eben Windows-Software entwickeln und es deutlich einfacher ist eine WindowsMobile-Anwendung zu erstellen wenn man mit Windows schon vertraut ist. In XCode/Cocoa für das iPhone anzufangen und zu glauben, dass man mal eben mit seiner Windows-Anwendung Daten tauschen könnte ist ein irrglaube. Dass Multitasking nicht läuft ist ein weiteres Hindernis für einige Anwendungsbereiche, eine richtige Datenbank für das iPhone die man offiziell nutzen kann suche auch noch und und und.

Ich bin aber mal gespannt, wie sich die Entwicklungsumgebung und die Möglichkeiten beim iPhone weiterentwickeln werden. Bei WindowsMobile ist das mehr oder weniger bekannt: Es bleibt wie es ist - vielleicht kommt etwas hinzu um ein "hübsches" Skin einbauen zu können

Ich halte Apples Weg, ein zum Desktop inkompatibles API zu verwenden, für richtig. Ich habe schon viel Software für Embedded Geräte entwickelt und nur äußerst selten war die Kompatibilität zum Desktop irgendwie relevant.
Als Navi Entwickler ist das mein Job und ich kann genau sagen, warum wir (bzw. unser Kunden) - und vermutlich auch andere Navi Hersteller niemals eine Navi für das iPhone herausbringen werden (und das gilt sicher auch für andere Branchen):

Das Geziere mit den Zertifikaten, die völlig Abschottung jedweder Distributionsform bei gleichzeitig völlig willkürlichem "Ausleseprozess" im AppStore.

Unter solchen Bedingungen können nur Spiele-Entwickler gedeihen - und auch nur deshalb, weil Apple bis heute bei Spielen noch keine Auslese vorgenommen hat. Keine Software-Firma mit Hirn würde sich freiwillig so Apple ausliefern.

So ist es nur eine Frage der Zeit, bis wirklich ein iPhone Killer kommt - es wird dann aber garantiert ein Gerät mit einem "offenen" System sein.

Danke Euch beiden mal für die Einblicke.

Ich denke mal Apple wird auch vom Handling noch nachbessern. Das iPhone ist ihr neuer Goldesel, den lassen die sich nicht mehr kaputt machen wie damals Mac OS von Microsoft. Deshalb diese Paranoia. Wird sich im Laufe der Zeit legen.

Das man vorher kein ok kriegt ob die App akzeptiert werden kann, liegt in der Natur der Sache wie der Prozess bei Apple momentan abläuft. Spricht aber ja nix dagegen zukünftig hier mit einzelnen Entwicklern Nebenabsprachen zu treffen. Eure App kommt rein, das können wir Euch garantieren, weil wir sie interessant finden. Voraussetzung ist aber, a), b), c).

Persönlich glaube ich an keinen iPhone-Killer. RIM ist auch nicht offen. Windows ist, aber was hat ihnen das gebracht? Nische. Android leistet nicht das was versprochen wurde, sprich man muss erst mal noch eine Weile warten, bis das brauchbar ist.

Tja, keine Ahnung warum bei mir der Safari im O2 Edge Netzwerk so langsam ist. Vielleicht liegt es auch an O2? Aber der Opera mini war bei gleichem Netz halt wesentlich schneller, warum auch immer und der Umbruch der Textspalten ist eindeutig besser beim Opera mini als bei Safari. Die MTN Seite mittlere Spalte kann ich zb nur im Querformat auf dem iPhone lesen weil sonst die Schrift zu klein ist, der Opera hat das einfach umgebrochen und ich konnte ne grosse Schrift einstellen.

Der Opera hat auch eine Einrastfunktion für die Textspalten, so das man nicht so leicht den Text horizontal außer Sicht schiebt, was beim Safari leicht passiert wenn man etwas quer zieht.

Shake hands ist eine schlechte Grundlage für ein Businessmodell. Da müsste schon etwas mehr Verbindlichkeit her.

Den Erfolg von Windows Mobile würde ich nicht unterschätzen - das steckt in nahezu allen PNA Navis drin, zunehmend auch in Festeinbauten und damit wird auch das Handy OS Quersubvensioniert. Kommerziell bedeutsame Anwendungen wie Spezial-Lösungen für Warenwirtschaft, Krankenhäuser, Gastronomie gibt es fast nur für diese Plattform.

OK, richtig. Die Navis die ich mir angeguckt haben waren alle WM. Ich hab das jetzt mit der Endanwender-sucht-Plattform-für-sein-nächstes-Handy-Brille gesehen.

o.wunder Opera Mini arbeitet ja mit einem Proxy und komprimiert die Seiten auf das notwendigste runter. Vieleicht ist das der Grund warum es dann auch mit o2 noch schnell ist. EDGE haben die fast nirgendwo.

@silvio: Kann Deine Aussagen nur unterstreichen.

Ich finde es aber dennoch recht traurig, dass sich WM kaum weiter entwickelt hat. Gerade teste ich wieder ein neues Navi-System und stelle mal wieder fest, dass man offenbar einfach keinen "Killer" schaffen möchte oder nicht kann.

Man ist natürlich auch iPhone verwöhnt irgendwann. Da hat man eine Routingliste oder Suchergebnis vor sich und möchte mit einem Fingerschnipp darin scrollen... geht natürlich nicht Immer schön Button rauf/runter drücken. Puh.

Wenn schon kein Multi-Touch - wann werden wohl Gesten offiziell in WM Einzug halten (also im Kern, in die API)?