Microsoft rilancia Windows Mobile 6: meglio di Google Android o iPhone

Microsoft annuncia una nuova strategia per promuovere Windows Mobile 6 in uno scenario di mercato in cui la comunicazione e l'accesso alla rete anche da dispositivi mobile assume sempre più importanza
di Fabio Boneschi pubblicata il 09 Novembre 2007, alle 11:45 nel canale SoftwareiPhoneAndroidGoogleMicrosoftWindowsApple
96 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoTutt'altra storia se avessero basato su Knoqueror o su Opera (che però è chiuso)... se Google ha fatto questo sbaglio evidentemente non è poi tanto interessata a fare le cose bene... solo a vendere.
Il WebKit è probabilmente il motore più aderente agli standard oggi disponibile. E anche il più veloce. Se alcuni siti non funzionano (ed è vero) è perchè sono stati scritti appositamente per le caratteristiche NON STANDARD o i bug di Explorer. Mozilla/Firefox è sicuramente un po' più tollerante di WebKit con i siti scritti per Explorer quindi in apparenza sembra andare un po' meglio. D'altra parte è più lento e molto più pesante di WebKit, per quello nessuno lo usa nei dispositivi mobili.
Konqueror è rimasto indietro rispetto a WebKit tanto che in KDE 4 anche loro ripartiranno da WebKit, a quanto ne so.
Konqueror è rimasto indietro rispetto a WebKit tanto che in KDE 4 anche loro ripartiranno da WebKit, a quanto ne so.
EDIT: Sono andato a ricontrollare una cosa che avevo fatto tempo fa, ma di cui mi ricordavo solo vagamente... ritiro quanto riportato sotto, in quanto il test che avevo guardato riguardava il css3 non l'acid test 2. Quindi è konqueror che lo supporta meglio, fra le tante konqueror 4 userà ancora khtml non webkit.
OLD: I browser basati su webkit "cannano" l'acid test 2 a meno che non abbiamo fatto alcune correzioni ultimamente. L'acid test è indicativo, perchè nessuno avrà mai la necessità di supportare esattamente tutti quei costrutti. Ma Opera lo passa.
Chissa perchè, ma mi sa che sto confondendo due tecnologie linux al momento... devo ridare una letta.
Ha avuto 5 anni di vantaggio per esprimere le sue "potenzialità".
Poi è arrivato l'iPhone (e il suo OS) e da zero l'ha distrutto su tutti i fronti.
Puoi dire che i dispositivi windows mobile hanno alcune funzioni in più di iPhone, e senz'altro è vero, ma è impossibile per chiunque affermare che le funzioni equivalenti siano "migliori" su WM.
L'iPhone ha lo stessa forza distruttiva del primo Mac. Semplicemente è di una categoria superiore. Gli altri si dovranno adeguare al nuovo standard, e stanno cercando già di farlo con risultati per ora discutibili (vedi HTC Touch).
Si, si... e come mai allora M$ (o i sviluppatori Linux) non sono mai riusciti a copiare quella dei Mac?
Non è una limitazione software. Ha l'EFI al posto del BIOS e alcuni files criptati. Quindi la limitazione è forzata (ma niente che degli hacker non riescano a superare).
Le ottimizzazioni ci sono per quanto riguarda la gestione dei consumi, ventole, stop (che sui PC in effetti non funzionano mai bene e sui Mac sono impeccabili) o per hardware custom come tastiere retroilluminate, sensori di movimento, wireless 802.11n, ecc.
Lasciamo stare, va. Safari come supporto agli standard web è pressochè imbattibile, infatti ora iniziano un po' tutti ad usare WebKit (anche Nokia!).
E l'implementazione in iPhone è sublime e non ha paragoni in altri dispositivi pocket.
Uff...
http://mobile.yahoo.com/iphone/mail
Vedremo
Non è la stessa cosa.
CoreData sono delle API OO per la gestione di archivi persistenti che prescindono la tecnologia d'immagazzinamento. I files possono essere archivi SQLite, ma anche files XML o TEXT, in modo trasparente. Non bisogna scrivere una riga di SQL.
Era un esempio. Evidentemente un database client-server come MySQL ha poco senso su un telefono. Ci sono tools migliori (SQLite, ad esempio, che dovrebbe essere integrato nell'OS).
La Apple ha cannato Java su iPhone, e anche su Leopard ne ha di molto sminuito l'importanza (ha deprecato il bridge con le API Cocoa a vantaggio dei liguaggi di scripting Phyton e Ruby).
Java è una tecnolgia OLD che non ha mai mantenuto le sue promesse : 1 unico pseudo-binario per tutte le piattaforme, ed è sempre rimasto pesante e graficamente inguardabile.
Mettila come ti pare, per me usare una macchina virtuale per applicazioni native è un controsenso. E se su un desktop le penalizzazioni possono essere quasi trascurabili, non è così su dispositivo mobile, dove memoria e cicli costano in tutti i sensi.
L'LLVM (già usato su iPhone e presto o tardi anche su Leopard) ha un altro approccio ad un utilizzo multilanguage, e le applicazioni restano native. E comunque è un falso problema. I programmi per una piattaforma devono essere scritti nel linguaggio delle sue API. Tutto il resto è sub-ottimale. In .NET i programmi vanno scritti in C#, in OS-X in Objective C (ora 2.0 con supporto opzionale della garbage collection).
Come detto Phyton e Ruby ora hanno un bridge con Cocoa, quindi su Leopard si possono scrivere applicazioni native in questi linguaggi (non di serie su iPhone, ma portati da sviluppatori esterni). Non dentro una macchina virtuale. Certo la parte interpretata sarà lenta, ma le routine di sistema gireranno a velocità nativa. In futuro perfino questi linguaggi potranno essere compilati JIT nella piattorma HLVM (http://hlvm.org/) che sarà inglobata nell'LLVM. Ma per questo magari se ne riparla in MacOS X 10.6.
Di uguale ha solo la V di "Virtual"
Quello che si virtualizza in quel caso è il processore, non l'ambiente.
Il sorgente viene precompilato per un "processore virtuale".
Vari linguaggi possono avere come target questo "processore virtuale".
Il back-end del compilatore LLVM poi si occupa di compilare e ottimizzare il codice intermedio (IR= Intermediate Representation) in codice nativo per i vari processori supportati. Staticamente o in JIT. Si svincola il codice oggetto dal processore, sarà sufficiente un unico IR per qualsiasi piattaforma!!
Putroppo questa cosa non sembra ancora pronta del tutto su Leopard, anche se iPhone pare utilizzi già ora l'LLVM (forse è questo uno dei motivi dei ritardi dell'SDK, la cosa sarà ancora un po' in beta).
Tutto il software che ci gira sopra è "automaticamente" ottimizzato per quell'hardware, perchè il compilatore ha già fatto il suo dovere e perchè se l'hardware richiesto mancasse non girerebbe.
Io mi riferivo a problemi più terra-terra, come fare un'interfaccia con i widget ottimizzati per uno schermo touch di 3,5" da 160dpi e una risoluzione di 428 x 240 (minimo) , piuttosto che un OS che si deve adattare alle più disparate configurazioni hardware. Anche Google con Android in pratica ha dovuto fare 2 interfacce distinte ed è dovuta scendere a compromessi. Apple no. Ha fatto un OS solo con quell'hardware di riferimento e ha potuto ottimizzare la sua interfaccia per quello.
Veramente a me risulta che Safari sia stato il primo browser non beta a passare l'Acid Test 2. E lo fa da tempo. Mozilla ancora lo toppa. ExploDer... lasciamo perdere, va!!
Edit: Ops, non avevo visto il TUO Edit. Ok. Quindi su KDE 4 hanno ricambiato idea?
Poi è arrivato l'iPhone (e il suo OS) e da zero l'ha distrutto su tutti i fronti.
certo che più grossa non la potevi sparare...
L'iPhone ha lo stessa forza distruttiva del primo Mac. Semplicemente è di una categoria superiore. Gli altri si dovranno adeguare al nuovo standard, e stanno cercando già di farlo con risultati per ora discutibili (vedi HTC Touch).
Si, si... e come mai allora M$ (o i sviluppatori Linux) non sono mai riusciti a copiare quella dei Mac?
Non è una limitazione software. Ha l'EFI al posto del BIOS e alcuni files criptati. Quindi la limitazione è forzata (ma niente che degli hacker non riescano a superare).
Le ottimizzazioni ci sono per quanto riguarda la gestione dei consumi, ventole, stop (che sui PC in effetti non funzionano mai bene e sui Mac sono impeccabili) o per hardware custom come tastiere retroilluminate, sensori di movimento, wireless 802.11n, ecc.
Lasciamo stare, va. Safari come supporto agli standard web è pressochè imbattibile, infatti ora iniziano un po' tutti ad usare WebKit (anche Nokia!).
E l'implementazione in iPhone è sublime e non ha paragoni in altri dispositivi pocket.
Uff...
http://mobile.yahoo.com/iphone/mail
Vedremo
Non è la stessa cosa.
CoreData sono delle API OO per la gestione di archivi persistenti che prescindono la tecnologia d'immagazzinamento. I files possono essere archivi SQLite, ma anche files XML o TEXT, in modo trasparente. Non bisogna scrivere una riga di SQL.
Era un esempio. Evidentemente un database client-server come MySQL ha poco senso su un telefono. Ci sono tools migliori (SQLite, ad esempio, che dovrebbe essere integrato nell'OS).
La Apple ha cannato Java su iPhone, e anche su Leopard ne ha di molto sminuito l'importanza (ha deprecato il bridge con le API Cocoa a vantaggio dei liguaggi di scripting Phyton e Ruby).
Java è una tecnolgia OLD che non ha mai mantenuto le sue promesse : 1 unico pseudo-binario per tutte le piattaforme, ed è sempre rimasto pesante e graficamente inguardabile.
Mettila come ti pare, per me usare una macchina virtuale per applicazioni native è un controsenso. E se su un desktop le penalizzazioni possono essere quasi trascurabili, non è così su dispositivo mobile, dove memoria e cicli costano in tutti i sensi.
L'LLVM (già usato su iPhone e presto o tardi anche su Leopard) ha un altro approccio ad un utilizzo multilanguage, e le applicazioni restano native. E comunque è un falso problema. I programmi per una piattaforma devono essere scritti nel linguaggio delle sue API. Tutto il resto è sub-ottimale. In .NET i programmi vanno scritti in C#, in OS-X in Objective C (ora 2.0 con supporto opzionale della garbage collection).
Come detto Phyton e Ruby ora hanno un bridge con Cocoa, quindi su Leopard si possono scrivere applicazioni native in questi linguaggi (non di serie su iPhone, ma portati da sviluppatori esterni). Non dentro una macchina virtuale. Certo la parte interpretata sarà lenta, ma le routine di sistema gireranno a velocità nativa. In futuro perfino questi linguaggi potranno essere compilati JIT nella piattorma HLVM (http://hlvm.org/) che sarà inglobata nell'LLVM. Ma per questo magari se ne riparla in MacOS X 10.6.
Di uguale ha solo la V di "Virtual"
Quello che si virtualizza in quel caso è il processore, non l'ambiente.
Il sorgente viene precompilato per un "processore virtuale".
Vari linguaggi possono avere come target questo "processore virtuale".
Il back-end del compilatore LLVM poi si occupa di compilare e ottimizzare il codice intermedio (IR= Intermediate Representation) in codice nativo per i vari processori supportati. Staticamente o in JIT. Si svincola il codice oggetto dal processore, sarà sufficiente un unico IR per qualsiasi piattaforma!!
Putroppo questa cosa non sembra ancora pronta del tutto su Leopard, anche se iPhone pare utilizzi già ora l'LLVM (forse è questo uno dei motivi dei ritardi dell'SDK, la cosa sarà ancora un po' in beta).
Io mi riferivo a problemi più terra-terra, come fare un'interfaccia con i widget ottimizzati per uno schermo touch di 3,5" da 160dpi e una risoluzione di 428 x 240 (minimo) , piuttosto che un OS che si deve adattare alle più disparate configurazioni hardware. Anche Google con Android in pratica ha dovuto fare 2 interfacce distinte ed è dovuta scendere a compromessi. Apple no. Ha fatto un OS solo con quell'hardware di riferimento e ha potuto ottimizzare la sua interfaccia per quello.
e continui anche dopo a spararle colossali. Dai torna ad parlare nei tuoi soliti 3d Apple che qui hai già portato tutto molto OT.
Poi è arrivato l'iPhone (e il suo OS) e da zero l'ha distrutto su tutti i fronti.
Puoi dire che i dispositivi windows mobile hanno alcune funzioni in più di iPhone, e senz'altro è vero, ma è impossibile per chiunque affermare che le funzioni equivalenti siano "migliori" su WM.
L'iPhone ha lo stessa forza distruttiva del primo Mac. Semplicemente è di una categoria superiore. Gli altri si dovranno adeguare al nuovo standard, e stanno cercando già di farlo con risultati per ora discutibili (vedi HTC Touch).
Il primo Mac con interfaccia grafica in realtà falli miseramente, quindi speriamo di no eh? Poi il successo degli altri? Non mi sembra coprano il 90% del mercato consumer.
L’unica funzione equivalente peggiore su WM è il frontend grafico fornito di sistema. Il resto è tutto equivalente o meglio… come ho già detto più su, Microsoft necessita di sviluppare un frontend grafico che sia riutilizzabile… probabilmente è già in sviluppo e si tratterà di portare WPF sotto WindowsMobile… cosa che non hanno ancora fatto. Su questo non posso dire di no… iPhone a quell’unico punto di forza, quindi glielo concedo, visto che Apple ha spinto pure solo su quello.
Le ottimizzazioni ci sono per quanto riguarda la gestione dei consumi, ventole, stop (che sui PC in effetti non funzionano mai bene e sui Mac sono impeccabili) o per hardware custom come tastiere retroilluminate, sensori di movimento, wireless 802.11n, ecc.
E’ una limitazione software, perché OS X per funzionare necessita di SSE2 e SSE3. Alcuni software senza le ultime non girano e nessun hacker può farli girare attualmente, perché i sorgenti non sono pubblici. Cosa che invece è diversa per quanto riguarda il kernel di darwin e di conseguenza ricompilabile, abbastanza da farlo avviare e da far avviare mac os x su pc.
Ovviamente si tratta solo o quasi di una questione di ricompilazione per quei software, ma visto che apple non la farà… non succederà mai per ora…
Il fatto che parta una parte dell’OS è diverso da dire che funziona sui PC… i pc sono variegati… non tutti montano Intel… ci sono anche gli amd :P
http://mobile.yahoo.com/iphone/mail
Quindi non dipende da yahoo la cosa, ma è iphone che supporta la push mail di base… bene bene, questa cosa non mi era arrivata fino a oggi o almeno, di tutti i siti che avevo letto tutti dicevano che non era supportata.
CoreData sono delle API OO per la gestione di archivi persistenti che prescindono la tecnologia d'immagazzinamento. I files possono essere archivi SQLite, ma anche files XML o TEXT, in modo trasparente. Non bisogna scrivere una riga di SQL.
Cioè il famoso System.Data del Compact Framwork? Perché da come lo dici fanno esattamente la stessa cosa o quasi.
SQLLite c’è per Windows CE :P
Java è una tecnolgia OLD che non ha mai mantenuto le sue promesse : 1 unico pseudo-binario per tutte le piattaforme, ed è sempre rimasto pesante e graficamente inguardabile.
Mettila come ti pare, per me usare una macchina virtuale per applicazioni native è un controsenso. E se su un desktop le penalizzazioni possono essere quasi trascurabili, non è così su dispositivo mobile, dove memoria e cicli costano in tutti i sensi.
L'LLVM (già usato su iPhone e presto o tardi anche su Leopard) ha un altro approccio ad un utilizzo multilanguage, e le applicazioni restano native. E comunque è un falso problema. I programmi per una piattaforma devono essere scritti nel linguaggio delle sue API. Tutto il resto è sub-ottimale. In .NET i programmi vanno scritti in C#, in OS-X in Objective C (ora 2.0 con supporto opzionale della garbage collection).
A parte il fatto che non ho detto che si può programmare solo managed ma anche in c++. Pure io sono convinto che le migliori prestazioni si ottengono con linguaggio nativo e api native ma ho sempre preferito Delphi a C++, che trovo estremamente stressante… non che cambi tanto alla fine… soprattutto ultimamente.
Cmq la macchina virtuale .Net è decisamente più ottimizzata di quella Java e il codice può anche essere compilato nativo o in gran parte nativo.Ho capito cosa intendi per LLVM, anche se dalla descrizione del sito sembra più una macchina virtuale stile .Net che altro.
Una nota solamente, perché mi è parso di capire una cosa ObjectiveC di Cocoa è cmq molto simile come filosofia a .Net in quanto è in buona parte managed, termine che significa gestito non “non compilato”. Forse piuttosto che a .Net mi ricorda molto di più il sistema a classi di Delphi… ma sono implementazioni non troppo distanti.
Quello che si virtualizza in quel caso è il processore, non l'ambiente.
Il sorgente viene precompilato per un "processore virtuale".
Vari linguaggi possono avere come target questo "processore virtuale".
Il back-end del compilatore LLVM poi si occupa di compilare e ottimizzare il codice intermedio (IR= Intermediate Representation) in codice nativo per i vari processori supportati. Staticamente o in JIT. Si svincola il codice oggetto dal processore, sarà sufficiente un unico IR per qualsiasi piattaforma!!
Putroppo questa cosa non sembra ancora pronta del tutto su Leopard, anche se iPhone pare utilizzi già ora l'LLVM (forse è questo uno dei motivi dei ritardi dell'SDK, la cosa sarà ancora un po' in beta).
Ehm… messa così è UGUALE a .Net allora… ma proprio la stessa cosa… per filo e per segno. Allora non avevo capito male.
Ma in Windows Mobile le due interfacce distinte di cui parli tu sono anche due prodotti distinti: uno è lo smartphone e l’altro è la pocketpc phone edition (che in seguito ha preso altri nomi). E’ come e fossero due OS diversi alla fine.
Quando io confronto WM con iPhone confronto la “pocket pc phone edition”, non certo la “smartphone edition” che ha un mercato totalmente differente.
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".