Parliamo di HTML5 e applicazioni native.
Puoi scegliere una strada o un’altra. O un ibrido delle due. Con una puoi coprire piattaforme multiple con un unico progetto. Con l’altra puoi monetizzare senza grandi sforzi. Con l’una puoi aggirare regole, limitazioni e costi dei marketplace. Con l’altra puoi sfruttare al meglio l’hardware sottostante. Ci sono pro e contro nel seguire una strada o l’altra.
Diciamo che, per ora, le applicazioni HTML5 non sono ancora in concorrenza con le app native (c’è chi dice “perché non scrollano con fluidità”).
Diciamo che, qualora le applicazioni HTML5 dovessero aumentare di importanza e diffusione, si imporrebbe un adeguamento delle caratteristiche degli Internet Browser per supportare nuove funzionalità, maggiori possibilità di input dall’utente, un accesso più spinto al client, ecc. ecc.
Diciamo che, in un futuro non troppo remoto, le applicazioni HTML5 potrebbero andare ad intaccare o addirittura a minacciare il mercato delle app native.
Ecco. Ora andiamo a controllare un secondo chi controlla i marketplace delle app native, guadagnando in media un terzo del costo dell’app per ogni acquisto. Non limitiamoci solo ad una piattaforma, guardiamone almeno tre. Vi vengono in mente tre nomi ? Un aiuto. Apple, Microsoft, Google.
Ora, andiamo a vedere se questi Apple, Microsoft, Google sviluppano anche degli Internet Browser.
Risposta positiva. Coprono anche, congiuntamente, la maggioranza del traffico web con Internet Explorer, Chrome e Safari.
Ora poniamoci un’ultima domanda.
Se l’HTML5 ha bisogno degli Internet Browser, e l’HTML5 va in concorrenza con i marketplace, e chi gestisce i marketplace sviluppa gli Internet Browser, come andrà a finire ?
HTML5 avrà un futuro solo dove non ci sarà questo conflitto di interesse ?
Che ne pensate ?
Considerando che svariate app in realtà non sono altro che widget browser che aprono una pagina web predefinita, direi che il conflitto di interesse scompare: l'utente medio continuerà ad usare quello che il produttore fornisce, che sia app nativa o meno... Al produttore, basta che entrino soldi, il mezzo conta relativamente.
RispondiEliminaDico di più: sono ragionevolmente certo che, prima o poi, vista l'avanzata dell'HTML5 e della grafica 3D accelerata nel browser, presto o tardi le app web pareggeranno i conti con quelle native. Per il discorso "come proteggo il mio codice se è scritto in Javascript?", progetti come l'emulatore web jsLinux dimostrano come sia relativamente alla portata perfino eseguire blob nei browser, per cui...
Bel post! :D
Ciau!
JP
Rispondo da addetto ai lavori.
RispondiEliminaAll'inizio, per quanto fossero semplici o complesse le richieste dei clienti mi accingevo sempre e comunque a soddisfare le richieste con il linguaggio nativo (obj-c), però c'erano dei grossi limiti (per qualcuno magari sembra una bestemmia...). Le animazioni prima di tutto, le api iOS per lo scorrimento delle pagine e/o finestre quello permettono e nient'altro, scegli: Partial-cut, horizontalFlip, Cover-up/Cover-down, CrossDissolve; non ci sono altre animazioni. Quindi mi si presentò un quesito simile quando una famosa università italiana mi commissionò la loro app ufficiale su dispositivi Apple. Come risolvere la cosa ? Iniziai a studiare la possibilità di implementare un ibrido tra app nativa e app html5. La soluzione fu, wrapper in obj-c (sostanzialmente una UIWebView ed un singolo tasto che permettesse l'accesso alla API scelta e poi implementazione di HTML5 e JScript). Ragazzi..il risultato fu fenomenale, una meravigliosa app mix-code con fluidità ed animazione che non aveva assolutamente nulla da invidiare ad una pure-native. Oltretutto i Market ti pubblicano tranquillamente la app HTML5 (o mista) basta che rispetta i requisiti minimi per l'uso del dispositivo (quindi che non mangi memoria, che non inchiodi la fluidità d'utilizzo, che sia user-friendly etc.) e come sapete bene una singola UIWebView consuma un minimo di memoria, molto ma molto meno di un browser come Safari (che invece è goloso). Ovviamente mi sono scontrato con problemi tecnici del tipo: la API WebView non supporta alcuni tipi di custom autentication con la funzione HTTPRequest, ma alla cosa si puo' ovviare con ASIHTTPRequest; nel mio caso il cliente ha cambiato radicalmente tutti i sistemi di autenticazione interni all'università, preferendo le web-auth (ampiamente supportate dalla UIWebView).
Le animazioni: implementare delle animazioni con linguaggio nativo è un lavoro che fa sputare letteralmente sangue (e non parliamo di quanto tempo occorre per lo sviluppo), canvas e jscript creano effetti ed animazioni spettacolari e girano tranquillamente su qualsiasi dispositivo (apple, android o altro, basta che il browser supporti, ma dato che il mercato riconosce solo, e vi assicuro che è così, Apple o Android, quasi sempre Samsung, non ci sono problemi a far girare animazioni implementate in jscript.
Velocità di sviluppo, riduzione dei tempi. Quando inizi un'analisi ed un progetto in linguaggio nativo (nel caso di Apple) devi realmente prevedere N mesi di sviluppo anche solo per una demo degna di tale nome, in html5 si parla di qualche giorno, tempo di mettere in piedi il CSS, disegnare i tasti, legare le funzioni di qualche gallery etc. ed hai in mano una demo funzionante.
Personalmente mi sento di concludere con una piccolissima analisi del passato non troppo passato; prima sui nostri pc (nel mio caso Linux, nel caso di altri Windows o MacOS) giravano molte applicazioni native, VisualC++. C++ o PERL etc. Ora quanti si sono resi conto che appena ci si accinge a sviluppare un qualsiasi software per uso interno si parla subito di MySQL e PHP ? Ecco la risposta quindi, le web application hanno sostituito completamente le applicazioni native sui PC (PERL dal canto suo con le CGI non fa da meno). Succederà lo stesso per i dispositivi mobile; le app html5 sostituiranno completamente le native, accederanno all'hardware del dispositivo (anche se in realtà la cosa è gia possibile, ci sono sistemi di geolocalizzazione in HTML5, giochi tipo biliardo che sfruttano l'accelerometro sviluppati in HTML5 etc.). Per capire dove va il futuro bisogna guardare al passato, la storia è ciclica e si ripete.
Un saluto,
Ivan, classe 1972, ex security expert ora sviluppatore mobile.