Il mercato che iPhone ha sostanzialmente inaugurato, quello degli smartphone da circa 500 € destinati al grande pubblico, si trova ancora in una fase che potremmo definire “prepuberale”.
In questa fase tuttavia, due approcci fondamentali dividono l’industria e il mercato: l’integrazione verticale fra hardware e OS/App e un approccio orizzontale, con OS e il relativo parco applicazioni disponibile per un numero elevato di produttori.
Per motivi che ho esposto già qualche mese fa, sono persuaso del fatto che, in questo momento, l’integrazione verticale hardware-software rappresenti la strada maestra per questo mercato.
I motivi di questa mia convinzione risiedono essenzialmente nella necessità di sfruttare in modo ottimale un hardware (batteria compresa) molto limitato e nella necessità altrettanto cogente di mantenere il parco App libero dal vincolo dei requisiti di sistema – in tal senso è ottimale la condizione in cui ogni App gira su ogni hardware compatibile con un determinato OS, sfruttandolo appieno.
L’acquisizione di Palm da parte di HP rafforza in me questa convinzione e, nello stesso tempo, ribadisce un elemento strategico fondamentale: ogni azienda mira ad avere sotto il suo diretto controllo tutti i fattori che possono influenzare la user experience e in ultima analisi il successo dei suoi prodotti.
In questo senso, per un’azienda che abbia le risorse necessarie a sviluppare e supportare un ecosistema software pare, ancor più dopo l’affare HP-WebOS, preferibile utilizzare sui propri smartphone un OS controllato in maniera diretta ed esclusiva.
Il valore di un OS sviluppato in casa, laddove esistano le economie e le risorse tecniche per sostenerlo, risiede nella differenziazione. Da un lato, se un produttore di OS “aperti” spinge sull’ottimizzazione, è costretto a fissare delle specifiche hardware vincolanti per i produttori, che si ritrovano a competere con prodotti più o meno feature equivalent, i quali finiscono per scontrarsi su elementi collaterali come il design, o sul prezzo.
Se al contrario il produttore di un OS tiene le briglie sciolte sulle specifiche hardware, il rischio è quello di performance e caratteristiche esperite dall’utente non proporzionali al potenziale dell’hardware e, di conseguenza, una compatibilità a macchia di leopardo del parco App. Da quest’ultimo fattore discende il ricorso al vincolo dei requisiti di sistema, che limita la fruibilità delle applicazioni, particolarmente da parte di un pubblico orientato più alla funzione che all’approfondimento delle feature tecniche.
Credo che l’acquisizione degli asset di Palm da parte di HP rafforzi queste considerazioni e rappresenti una forte indicazione rispetto alla volontà di HP di porre sotto il proprio diretto controllo tutti i fattori che possono differenziare i suoi prodotti dalla concorrenza.
In questo, ovviamente, Microsoft e Google si trovano a perdere un potenzialmente grandissimo cliente, che invece finisce nella lista dei competitor.
Un’analisi azzeccata imho.
Sono assolutamente d’accordo col punto centrale dell’articolo, che l’acquisizione di Palm da parte di HP sia abbastanza simile a una scelta dell’integrazione verticale. Rimango invece non del tutto persuaso riguardo alla “superiorità” dell’integrazione verticale per il mercato: credo che l’approccio aperto di Android, Windows Phone o Meego permetta anche a realtà più piccole di “entrare nel gioco” producendo cellulari con costi minori (non dovendo sviluppare da sé un OS), personalizzazioni comunque possibili (vedi interfaccia Sense di HTC) e, se le API di questi sistemi sono sufficientemente stabili, applicazioni egualmente funzionanti su tutti i cellulari della medesima piattaforma.
In altre parole, realtà enormi come Apple e HP possono permettersi di sviluppare internamente un OS completo e ben funzionante; realtà più piccole come la stessa Palm rischiano di essere fagocitate e, a mio parere, è naturale trovino più conveniente basarsi su piattaforme aperte. Se Android, Meego e Windows Phone si riveleranno piattaforme sufficientemente stabili da permettere questo, non credo verranno schiacciate da piattaforme chiuse (ad esempio per ora Android si è evoluto tumultuosamente, ma è probabile che tale evoluzione rallenti in futuro).
@ Arunax
A livello di performance, io rimango persuaso della superiorità dell’integrazione verticale almeno fino a quando l’hardware sarà da considerare una risorsa molto scarsa.
I costi minori di sviluppo di un cellulare ce li hai a patto di avere un tasso di differenziazione inferiore rispetto alla concorrenza. Se questo viene compensato dalla compatibilità con un vasto parco software, se non margini almeno fai volumi.
Con Blackberry e iPhone ben piazzati nella torta del mercato, ed HP che procede nella stessa direzione, e Android che di fatto siede su HW molto eterogenei, non vedo ancora le citate economie di scala delle piattaforme “aperte”.
@Alessio Di Domizio
Per quanto riguarda la superiorità di performance pura hai sicuramente ragione, anche se forse sarebbe da definire meglio quanto scarse devono essere le risorse per rendere vantaggioso lo sviluppo verticale da entrambi i punti di vista (economico e di performance): anche perché sviluppare da per sé un OS o acquisire una società che ne sviluppa uno può rivelarsi un investimento molto oneroso, che solo i giganti si possono permettere. Ad esempio, se HP dovesse avere scarso successo commerciale con WebOS, si troverebbe nei guai (se non altro per spiegare ai suoi azionisti un investimento di questa portata non andato a buon fine): ti porto di nuovo l’esempio di Palm. Staremo a vedere, in ogni caso! Io confido in una equa suddivisione del mercato fra piattaforme “chiuse” e “aperte”, alla fine al cliente medio queste questioni interessano poco ;)
Per onestà intellettuale, devo aggiungere che un mondo a “integrazione verticale” nel senso di Apple (ovvero: un iPhone a tutti, uguale per tutti) non mi ispira affatto: ma questa è semplicemente questione di gusti, non si tratta di un ragionamento di carattere tecnico!
Non dimentichiamo, però, che il buon sfruttamento dell’hardware dipende anche dall’abilità dei programmatori che scrivono il codice che poi effettivamente gira su questi dispositivi, e non è affatto scontato che sia di qualità…
@ Cesare
Certo che sì. Però integrazione verticale significa anche un maggior controllo sulla qualità del software. Ad oggi Apple non ha filtrato app scadenti, il che credo risponda ad una necessità iniziale di fare numero per zittire la concorrenza (ma anche su altre piattaforme mi risulta ci siano belle ciofeche).
Quando allo sviluppo di app si contribuisse con n altri kit di sviluppo, su app store terzi, la possibilità di esercitare un controllo qualitativo sul codice si azzererebbe, ma i problemi di user experience che ne deriverebbero finirebbero pur sempre per gravare sulle spalle del machietto che vedi scritto sul telefono, Apple o altri che siano.
Vagli a spiegare poi agli utenti che se la batteria gli si fulmina in quattr’ore dipende dal tempo CPU rubato da uno specifico task bacato in backgound…
Non penso che Apple faccia un controllo anche sul consumo della batteria di un’applicazione. Sarebbe troppo complesso e difficile da mettere in atto, poiché i pezzi di codice eseguito non sono sempre gli stessi, ma variano nel tempo. Quindi ciò presupporrebbe una fase di test che richiederebbe non poco tempo.
E nemmeno è ipotizzabile il controllo dei sorgenti, che sarebbe anche peggio. Poi non è certo una politica di Apple (non mi risulta che abbiano chiesto i sorgenti delle applicazioni).
Il problema per come lo vediamo oggi è ancora limitato, dal momento che all’esecuzione in background è limitata a un set limitatissimo di funzioni, controllate strettamente da Apple. Quando verrà introdotto il multitasking anche per applicazioni di terze parti, sono certo del fatto che Apple utilizzerà il massimo livello di controllo (a livello funzionale e/o di codice) per assicurare che non vengano distribuiti “vampiri” per il già critico comparto batteria di iphone e di tutti i suoi analoghi.
quoto Cesare Di Mauro.
Aggiungo che la storia della batteria, IMHO, è solo una scusa che hanno tirato fuori per giustificare l’assenza del supporto a Flash. Le reali ragioni dell’esclusione invece, sempre IMHO, sono da ricercarsi nel fatto che Flash rappresenta, di fatto, una tecnologia capace di portare i giochini su iPhone “senza passare dal Via” (cioè dall’appstore), e quindi senza ritirare le famigerate 20 mila lire :D
Ad esempio, secondo questo ragionamento, dovrebbero escludere dall’appstore tutti quei giochi che sfruttano troppa CPU e GPU come i giochi 3D, i programmini per manipolare le foto e altri…
@Alessio: intanto ci sono decine di migliaia di applicazioni già rilasciate. Quindi Apple che farà? Le ricontrollerà tutte? E magari ne boccerà un po’, dopo averle approvate, perché si sarà accorta che “succhiano” troppa corrente?
Non mi pare ipotizzabile, come pure un eventuale controllo del consumo della batteria da parte di un’applicazione che, come dicevo prima, tecnicamente è difficile da effettuare.
Anche perché il carico su CPU, chipset, memoria e GPU non è costante nel tempo, ma varia dinamicamente in base al tipo di codice eseguito in un preciso momento.
Poi ci sono applicazioni intrinsecamente voraci di batteria, come ha citato giustamente TheKaneB, a cui non è che si può mettere un “limitatore”, pena un malfunzionamento della loro fruizione, che non sarà fluida e danneggerà la user-experience.
Per me quella di Apple non è nemmeno retorica, ma “fumus persecutionis” nei confronti di chi, “semplicemente”, non gradisce.
Vedi Android che, notizia di ieri, ha abbracciato Flash. A Google la batteria non sta a cuore? Certamente, ma non mette paletti ideologici (e ci sono andato leggero), anche perché sa benissimo che il solo supporto ai giochi equivale a una resa incondizionata nei confronti della batteria…
@ TheKaneB
Con le applicazioni native migliori del mondo, e un uso intenso, puoi far fuori la batteria di un iphone in 4 ore e qualcosa. Questo non IMHO ma provato in prima persona e replicabile da chiunque.
Dopodiché tutte le teorie del complotto sono possibili fino a prova contraria. Sottolineo solo che
– sul fatto che il comparto batteria degli smartphone di ultima generazione sia molto critico non c’è molto da argomentare;
– su qualunque piattaforma Flash sia mai arrivato, è stato un CPU hog formidabile; un esempio? la CPU minima necessaria per far girare flash 10.1 è un Cortex-A8 (ARM v7), ovverosia l’ultima release disponibile di ARM (come se flash per PC richiedesse dal Core i7 in su); questo già scarta il 90% dei telefono prodotti dal 2008 indietro, tipo iPhone 2g/3g, su cui invece, fin dal lancio, puoi tranquillamente vedere Youtube senza Flash;
– i giochini Flash di cui parli sono progettati, come il 99,9% delle applicazioni flash, per essere fruiti con mouse e tastiera; basta che cerchi su techcrunch come gira Zynga, uno dei giochi flash più famosi e più sviluppati per computer; l’iPhone si comanda col touch;
Tutto questo al netto del fatto che, come sicurezza, Flash è ritenuto un colabrodo: Charlie Miller, esperto di sicurezza CanSecWest, alla domanda su quale fosse il browser più sicuro ha risposto: “probabilmente non c’è abbastanza differenza fra i concorrenti. La questione principale è non installare Flash!”
In poche parole, non sappiamo esattamente di cosa parliamo, ma gli “indizi” circa la funzionalità di Flash su smartphone sono piuttosto chiari in una direzione.
@ Cesare
No, credo farà bene ad accertarsi che quelle che si candidano a girare in background siano snelle e leggere il più possibile. Il problema del consumo di batteria è principalmente valido alla vigilia dell’introduzione di OS 4. E vedrai che casino uscirà fuori comunque…
Ripeto, il problema non riguarda tanto le applicazioni tipo giochini a cui dedichi cinque minuti sul treno. Il problema riguarda quelle che si suppone debbano girare in background per tutta la giornata. Per quelle sono certo che Apple imporrà vincoli strettissimi, e me lo auguro anche! D’altronde anche RIM ha le sue “superapp”, che passano per un processo di revisione più stringente. Cosa c’è di strano?
Mah io credo che per supporre una persecuzione di A verso B si debba avere un’idea sul motivo che spinge A a perseguitare B. Io questo motivo, riguardo a Flash, non lo vedo. Mi pare piuttosto che si stia difendendo un software elefantiaco che da anni e anni piega le CPU e spesso disturba la navigazione Internet… Non parliamo poi del supporto Flash a OS che non siano Windows! Insomma, da dove viene fuori questo improvviso amore per Flash? :-D
Tanto più quando vanno definendosi standard web aperti (supportati da aziende del calibro di MS e Google oltre Apple) in grado di riassumerne le funzionalità…
@ tutti
Segnalo che, forse più pertinente del supporto Flash su iPhone, rispetto all’argomento del post è la questione che riguarda il runtime AIR per lo sviluppo di applicazioni cross platform per smartphone.
A mio avviso Flash fa paura per una sola cosa: i giochi. Perché usarlo per le cosiddette “commodity” lascia il tempo che trova, visto che si possono realizzare più semplicemente con l’SDK oppure con strumenti come MonoTouch (e qui mi spiegherà Apple per quale motivo non ne consente l’utilizzo).
E poiché i giochi sono i principali consumatori della batteria anche per quelli “nativi”, io non ci vedo proprio nulla di male.
@ Cesare
Fa paura per i giochi? Quegli stessi giochi che mi piantano un core di un Core2, dovrebbero confrontarsi coi giochi sviluppati e ottimizzati per girare su architettura ARM?
Un esempio qui:
http://techcrunch.com/2010/02/22/farmville-nexus-one/
Tanto per ribadire che siamo all’alba di Flash su smartphone e la piattaforma non si può certo dire né rodata, né particolarmente ottimizzata per interfaccia touch o risparmio energetico…
Dopodiché una versione definitiva di quel Flash 10.1 che oggi si insiste a ritenere escluso ingiustamente da iPhone, non esiste ancora. In altre parole, di che stiamo parlando? Del perché un’azienda non offra supporto a un SW che ancor oggi – e non è certo ieri che Apple ha deciso su Flash – a metà 2010, è in stadio RC?
E poi, ad oggi, qual è il peso di Flash nel mondo mobile? Cosa mi perdo navigando sul web da smartphone, senza flash?
@ Cesare
Perché non te ne torni su PI a fare le tue solite sparate? Qui sembri pure intelligente…
@ ruppolo
Questo genere di attacchi personali non è contemplato dalla buona educazione. In assenza di buona educazione, non è contemplato dalle regole di moderazione di AD. Sei pregato di tenerne conto.
@ ruppolo
Su PI ci sei già tu che scrivi trollate tutti i santi giorni quindi, per favore, abbandona questo sito per non rovinarlo con i tuoi soliti post vuoti e di parte come hai già fatto con il forum di PI. Qui ci sono persone che vogliono discutere seriamente.
@Alessio Di Domizio
Se fai un giro sul forum di PI ti renderai conto di quale triste personaggio è questo ruppolo. E’ solo un fanatico Apple della peggior specie.
Se vuoi un consiglio bannalo o questo spazio dedicato ai commenti rischia di trasformarsi in un asilo nido come il forum di PI. Io non frequento più quel forum proprio perché è pieno di utenti immaturi (soprattutto Apple fanboy) come lui.
Chiedo scusa per l’OT ma ci voleva.
@ zac
Grazie del consiglio ma per favore rimaniamo in topic.
@Alessio: la paura riguarda la disponibilità di una foltissima libreria di giochi Flash disponibili a costo zero.
Poi che la soluzione mobile del player attualmente sia immatura, non posso che essere d’accordo, ma le notizie sullo sfruttamento dell’accelerazione hardware sono arrivate e credo che presto vedremo girare Flash decentemente anche su Mobile. Tra l’altro dal link non sembra nemmeno male quella versione, che non è certo l’attesa 10.1…
Per quanto le altre domande, beh, lasciamo che siano gli utenti a decidere se vale la pena o meno di usare Flash, no?
@ Cesare
Io non credo affatto che la foltissima libreria di giochi flash, sepolti in siti web non ottimizzati per il mobile e difficilmente navigabili anche da computer, quando non vettori adware, spyware e malware in generale (non dimentichiamoci che a questo riguardo Flash è una porta spalancata), sia fruibile via interfaccia touch, essendo questi giochi disegnati per l’uso da tastiera e/o mouse.
Peraltro su AppStore trovi tonnellate di giochi gratis, e titoli di qualità paragonabile a quelli che su PSP o DS paghi 40€, a 3,99… Quindi non vedo proprio cosa ci sia da temere dal parco titoli videoludici in flash.
L’implementazione di Flash su mobile è immatura e le applicazioni preesistenti che fa girare non hanno alcun criterio di accessibilità via touch e risparmio energetico, né per iPhone, né per quelli che hanno promesso supporto a Flash nei loro smartphone touchscreen.
D’altronde il supporto Flash per Mac sono dieci anni che fa solo pena e la CS4 è ancora a 32bit e scritta in Carbon – l’API offerta da Apple per agevolare la migrazione di applicazioni Classic a OSX 10 anni fa. Con la CS5 gli utenti Mac conosceranno finalmente le potenzialità di un’applicazione scritta con l’API di riferimento per OSX a 64 bit. Dopo soli 10 anni dal lancio di OSX agli sviluppatori.
Su queste basi cosa ci si dovrebbe attendere? Bisognerebbe accogliere a braccia aperte il supporto a un SW che è ancora in RC e non si sa quando arriva in versione definitiva, e con quali prestazioni? Peraltro segnalo che Flash 10.1 richiede un Cortex A8 – la più potente architettura ARM single core oggi disponibile – come requisito *minimo*.
Il che significa che milioni di iPhone 2g e 3g ancora in circolazione (più n altri smartphone recenti) comunque non potrebbero far girare flash…
Mettici pure le app in background con OS4 e la frittata è fatta.
Il tutto quando HTML5 si prepara a riassumere molte funzioni di Flash e funziona al punto da avere il pieno supporto di MS e Google oltre ad Apple.
Tu dici: facciamo scegliere gli utenti. Ma ti domando: sei certo che quando un utente di iPhone vedrà la batteria che gli si fulmina in un quarto d’ora, andrà a leggersi lo storico del tempo CPU di ogni singolo task in esecuzione?
Io credo che quei giochi siano facilmente adattabili anche al mobile. E ti parlo per esperienza non personale, ma quasi, visto che abbiamo una divisione che sviluppa giochi per qualunque piattaforma (dal mobile al PC, web e Flash incluso).
Per quanto riguarda Flash l’ho già detto che è immaturo come progetto su mobile, ma la situazione è destinata a cambiare in breve tempo.
L’esempio di OS X a 64 bit non lo farei: ho fatto un articolo proprio su quello. :D Apple è arrivata a una piattaforma pienamente a 64 bit soltanto con l’ultima versione del suo s.o., Snow Leopard. E penso che sia l’ultima titolata a lamentarsi della lentezza nell’aggiornamento del parco software. :P
Le specifiche di Flash non le prenderei come “assoluto”: dipende sempre dalle applicazioni, in ultima analisi. Anche perché mi sembra che, dal link che hai fornito prima, non si lamentino certo delle prestazioni, e quella non era nemmeno un’alpha di Flash 10.1…
Concordo su HTML 5, ma questo non è ancora uno standard (lo sarà fra 12 anni) e, soprattutto, lascia delle voragini aperte, come la scelta del codec da usare per riprodurre video. Altro passo falso del W3C (come se non fossero abbastanza tutti quelli che aveva fatto prima).
Infine sulla batteria, beh, se un utente gioca con un’applicazione nativa come un gioco, e dopo che esce si accorge che è stata consumata, non darà mica la colpa ad Apple. E’ chiaro che, intuitivamente, capirà di avere “sforzato troppo” il telefono. E lo stesso farà con un’applicazione Flash. ;)
@ Cesare
Quand’anche i giochi siano facilmente adattabili all’interfaccia touch, la cosa ha un costo. Mettici pure che vanno adattati i siti che quei giochi contengono, ed è un altro costo. Da cosa vengono compensati questo costo?
Sui siti tradizionali infili dentro una tonnellata di pubblicità, un po’ di pornazzi e magari un po’ di spyware, e con qualche milione di unici magari riesci a tirare un conto positivo a fine mese.
Ma dopo che hai convertito tutti i giochi per interfaccia touch, e hai convertito i relativi siti, e sai che quei giochi girano solo su una piccola parte dei telefoni in circolazione (da Cortex A8 in su), quando pensi di riprenderli i soldi?
Riguardo a OSX non parlavo di 32 o 64 bit, il punto centrale è Cocoa vs Carbon, ed è scandaloso che Adobe solo nel 2010 smetta di usare un’API che era stata progettata per la transizione delle app da OS9 nel 2000 e passi a Cocoa. Stesso dicasi per il penoso supporto di flash su piattaforme che non siano windows.
HTML5 non sarà ancora uno standard, ma ha alle spalle tre fra le più influenti aziende della Silicon Valley, MS, Apple e Google. Questo significa che per Adobe – un’azienda che vale circa dieci volte meno la più piccola delle tre – quella dell’antitrust è davvero l’ultima carta.
Sui costi io lascerei che siano le aziende a valutarli. Apple non c’entra nulla in questa storia. Da parte mia posso solo dirti che soldi non ne servono tanti per l’adattamento.
Inoltre penso che potranno girare su sistemi anche non dotati dell’A8, come si legge dal link che hai fornito.
Detto ciò, finora abbiamo parlato di Flash, ma davanti a MonoTouch Apple non può riciclare le stesse accuse. Allora le motivazioni reali emergono e parlano chiaro: la chiusura è strettamente politica perché la casa di Cupertino vuole tagliare fuori la concorrenza dalla SUA gallina dalle uova d’oro.
Sicuramente flash è pesante e succhiabatterie ma vorrei fare alcune considerazioni dato che mi trovo sulla linea di Cesare Di Mauro.
1)Ci sono applicazioni flash che non funzionano bene con uno schermo touch ma anche parecchie che funzionano senza problemi:
http://admin.precentral.net/adobe-flash-player-101-demod-pre
http://www.precentral.net/flash-webos-14-hands
2)Apple non proibisce solo Flash ma anche VM Java o emulatori vari come ad esempio ScummVM. E’ ridicolo che avventure grafiche come Monkey Island o Indiana Jones che giravano sui 286/386 non possano girare bene con i processori Arm di oggi. Infatti ScummVM gira senza problemi anche sui vecchi palmari di qualche anno fa. Idem per altre vecchie glorie come Doom etc. che si potrebbero giocare con emulatori senza doverle ricomprare nell’App Store.
Per esempio, per webOS è disponibile dal lancio l’emulatore di Palm OS che gira molto più velocemente dei vecchi palmari con Palm OS nativo.
3)Riguardo il runtime AIR per lo sviluppo di applicazioni cross platform per smartphone. Nessuno si è ricordato che l’iPhone sdk di Apple richiede obbligatoriamente MacOSX e che la licenza di quest’ultimo proibisce anche che venga installato come guest in una VM. Quindi per sviluppare sei obbligato ad acquistare computer Apple. Invece con gli strumenti di Adobe si può sviluppare anche su windows. Inutile dire che questo non piace ad Apple.
4)Magari l’iphone 2G e 3G non sono abbastanza potenti ma come la mettiamo con il 3GS e il prossimo modello? Ce la fa il Palm Pre a far girare flash… E l’iPad che ha potenza che vendere?
Anche la storia che l’autonomia dell’iPad scenderebbe da 10 a 1,5 ore non regge dato che il mio vecchio eee 900 con schermo da 9 pollici con linux e celeron 900 fa 5-5,5 ore senza navigare e wifi spento e 3,5 ore navigando con wifi e plug-in flash attivo.
5)Anche il problema del multitasking non regge molto. WebOS di Palm ha dimostrato che un multitasking completo (non limitato a 7 funzioni come nel futuro firmware 4.0) non prosciuga la batteria se si mette in pausa:
http://admin.precentral.net/adobe-flash-player-101-demod-pre
OK, è un filmato di Adobe però è interessante si nota come nelle applicazioni in background la riproduzione di flash va automaticamente in pausa.
6)Perché non implementare in Safari un filtro (tipo i componenti aggiuntivi di firefox) per i contenuti in flash delle pagine web? Così verrebbero caricati solo quelli richiesti dell’utente con un “tap” evitando le maledette pubblicità in flash (ma salvando le pubblicità statiche di immagini).
7)Se Apple si preoccupa tanto della batteria allora perché non permette la sostituzione facile come in tutti i cellulari del mondo così che uno possa comprarne una con maggior mAh come le ottime Seidio (20-30% in più con stesse dimensioni)?
La risposta è nel sito Apple dove c’è scritto che per cambiare la batteria dell’iPhone bisogna pagare ben 92€ ad Apple stessa.
Oppure c’è il fai-da-te ma molte persone non il coraggio di farlo e perciò…
Oppure si potrebbe bloccare l’esecuzione di flash nel browser quando la batteria è sotto un certo livello con un avviso. Mi ricordo che il mio vecchio Palm TX disattiva automaticamente bluetooth e wifi se la batteria è sotto il 20% (se non erro) con un avviso. Ed è un sistema operativo di 6 anni fa derivato da uno di 8 anni fa.
8)Alla presentazione del firmaware 4.0 un giornalista chiese se c’era la speranza di vedere in futuro flash e Jobs rispose con un lapidario NO. Ma invece dell’ostracismo totale non sarebbe più intelligente se l’accettazione di flash venisse subordinata a certi limiti massimi di consumi e limiti minimi di prestazioni? Così si tagliano le gambe al 10.1 senza neanche averlo provato.
9)HTML5 sarà il futuro così finalmente ci libereremo di flash ma il presente e l’immediato futuro è ancora troppo legato a flash. Diversi siti fanno parecchio uso di flash. E in un tablet che grazie allo schermo da 9.7″ viene usato di più per navigare la mancanza si farà sentire ancora di più. Infatti anche Engadget nella recensione dell’iPad ha definito la navigazione una “broken experience” per la mancanza di flash.
10)Anche il rischio di sicurezza mi sembra un po’ eccessivo. Sicuramente ci sono problemi come evidenziato da Miller ma non ricordo di epidemie di malware o di intrusioni in massa dovute a flash.
In base alle considerazioni sopra sono giunto alla conclusione che, imho, l’esclusione di flash sia dovuta più a motivazioni di natura politica e di controllo tipiche di Apple mentre le motivazioni tecniche siano secondarie e utilizzate soprattutto come fumo.
e dimenticavo al punto 3) che, come detto da Cesare di Mauro, Apple non ha certo l’interesse di facilitare il cross-platform delle sua applicazioni dato che con 150-200000 apps ha un grande vantaggio sulla concorrenza. E molte semplici app non hanno certo bisogno di una ottimizzazione estrema per funzionare più che bene.
@ Cesare
Dove Apple (o qualunque altro produttore cui non si può imporre ad oggi il supporto a uno specifico SW) c’entra è la preservazione della user experience. Se è lecito ritenere poco probabile che i miliardi di giochini flash, è lecito per un produttore preoccuparsi del fatto che la poca fruibilità di quei giochini degradi la user experience dei suoi utenti, particolarmente quando questi non sembra siano accampati sotto la sede a fare scioperi della fame per poter accedere a quei giochini.
Il link che ti ho fornito fa riferimento a Flash Lite 3, le specifiche di Flash 10.1 richiedono come minimo il Cortex A8.
La politica inserita a Apple nel comma 3.3.1 non parla né di Adobe né di altre aziende ma solo di metodologie per lo sviluppo di applicazioni. Dopodiché Apple di concorrenti ne ha a bizzeffe, che vendono anche molto più di iPhone e pare vadano a braccetto con Adobe. Né può fare nulla per combatterli oltre a tentare di migliorare i suoi prodotti.
Mi pare del tutto legittimo non che un’azienda decida quale software far girare e quale no, ma che decida di preservare il controllo della piattaforma che sviluppa e vende col suo marchio…