Quali sono i pro e i contro degli approcci HTML5, nativi e ibridi per le app mobili?

Voglio sviluppare un'applicazione mobile. Di recente ho letto un articolo sul forum di Telerik , che confronta tra tre tipi di applicazioni mobili e non so quale dovrei scegliere per iniziare. Ecco un'immagine che descrive i pro ei contro delle diverse scelte di progettazione mobile

Per decidere tra queste scelte progettuali, vorrei comprendere meglio i pro ei contro di ogni scelta di architettura elencata nel diagramma. Quali sono i pro e i contro di ogni approccio in architettura?

Sono uno sviluppatore mobile che ha trascorso molto tempo a considerare questo problema.

Perché lo chiedi?

Molto probabilmente, speri di ridurre i costi di sviluppo delle app:

• Utilizzo delle competenze di sviluppo HTML5 / Javascript esistenti
• Targeting per più piattaforme senza scrivere più app da zero
• Non dover mantenere più codebase in futuro

I motivi possono anche includere:

• Sviluppo HTML5 / Javascript percepito come "più semplice" rispetto allo sviluppo della piattaforma nativa
• Evitare il pagamento delle tasse di registrazione del programma per sviluppatori
• Evitare le restrizioni sui contenuti dell'appstore (gioco d'azzardo ecc.)
• Evitare l'acquisto di hardware di sviluppo (ad es. Mac per lo sviluppo di iPhone)

definizioni

Stabiliamo esattamente cosa intendiamo per ciascuno dei tre approcci citati:

Nativa
Un'app installata su un dispositivo, in genere dal suo app store (anche se a volte può essere sideloaded). Ai fini di questa discussione, l'interfaccia utente di un'app nativa di solito non consiste solo in una visualizzazione Web a schermo intero.

Web mobile
In realtà questa può essere qualsiasi pagina Web, tuttavia per questa discussione consideriamo un'app Web a pagina singola che tenta di imitare l'aspetto di un'app nativa. Non è un'app nativa, ma viene eseguita nel browser del dispositivo.

Applicazione
ibrida instanceofnativa per app ibrida .

La maggior parte delle persone probabilmente capisce che un'app ibrida è un'app Web mobile a pagina singola (ancora una volta molto probabilmente imitando l'aspetto di un'app nativa), ma confezionata come un'app nativa con accesso ai servizi nativi (à la Phonegap).

Tuttavia, esiste in effetti uno spettro tra il modello Phonegap e quello completamente nativo, a cui verrò più avanti.

Web mobile

Restrizioni tecniche Per
prima cosa elenchiamo alcune restrizioni tecniche sulle app Web per dispositivi mobili che potrebbero di per sé essere determinanti a seconda di ciò che stai facendo:

• Solo interfaccia utente HTML / canvas
• Nessun accesso a determinati eventi e servizi del dispositivo (questi sono ampiamente documentati)
• Non può essere elencato negli app store (influendo sulla rilevabilità)
• Può diventare a schermo intero e avere l'icona homescreen su iOS, tuttavia questa è un'esperienza insolita e non familiare per la maggior parte degli utenti

Se riesci a convivere con tutto quanto sopra, continua a leggere per saperne di più sulle sfide delle app Web in stile nativo a pagina singola. Tuttavia questa sezione non sarebbe completa senza riferimento all'app FT.

Financial Times
L' app web FT è un famoso esempio di questo stile di app. Ecco una caratteristica interessante del quotidiano The UK Guardian al riguardo.

È certamente una straordinaria impresa di ingegneria. Si noti che al momento è ancora disponibile solo solo su iOS - questo mi dice che stanno scoprendo che risolvere le sfide dello sviluppo avanzato tra browser è davvero molto difficile.

App Web in stile nativo a pagina singola

Questa sezione si applica sia al Web mobile che alle app in stile Phonegap.

L'aspetto nativo all'interno di un'app Web viene solitamente ottenuto con un framework come Sencha Touch che fornisce una suite di componenti dell'interfaccia utente che è possibile utilizzare.

Tali framework vanno bene per interfacce utente molto semplici. Tuttavia mancano di flessibilità. Non sarai in grado di implementare alcun design di app nativo utilizzando Sencha, dovrai adattare il tuo design a ciò che il framework può ospitare.

Il modo principale in cui soffrono questi framework è nel tentativo di emulare le complessità dell'interfaccia utente della piattaforma. Quel piccolo effetto di rimbalzo che ottieni quando hai fatto scorrere fino alla fine di un elenco su iPhone? Il tuo framework deve emularlo in Javascript. È impossibile ricrearlo completamente, sarà incline a rallentare e i tuoi utenti rimarranno bloccati nella "valle misteriosa" di un'app che sembra un po 'come nativa, ma chiaramente non lo è e non è tecnica l'utente non sarà in grado di mettere il dito esattamente sul perché.

Il mito "HTML5 / Javascript è facile"

La frammentazione dei dispositivi nei browser Web è diffusa e quando si supera l'HTML e i CSS più elementari, si noterà che le cose non funzionano come ci si aspetterebbe. Potresti ritrovarti a dedicare più tempo a risolvere problemi di interfaccia utente complicati di quanto avresti risparmiato facendolo due volte in modo nativo. Se stai diventando nativo, tieni presente che le visualizzazioni Web delle app native non sono le stesse dei browser dei dispositivi e hanno i loro problemi di frammentazione.

E man mano che la tua app diventa più complessa dal punto di vista funzionale, scoprirai che hai bisogno di qualcosa di più delle semplici competenze jquery per mantenere il tuo Javascript pulito e gestibile.

Detto questo, è perfettamente possibile creare app semplici e funzionali abbastanza rapidamente con questo approccio. Ma è abbastanza ovvio quando un'app lo sta facendo.

Più avanti lungo lo spettro

Quindi, vogliamo una UX migliore di quella che le app in stile Phonegap possono offrire, senza scrivere assolutamente da zero più volte. Cosa possiamo fare?

Condividi codice non UI

Sono disponibili diverse tecniche per la condivisione della logica di business su più piattaforme native. Google ha lanciato J2ObjC che traduce Java in Objective-C. Con un attento factoring del codice, una libreria Java potrebbe essere utilizzata sia su Android che su iOS.

Librerie come Calatrava e Kirin consentono di manipolare basi di codice scritte in Javascript (e quindi tutto ciò che può essere compilato in Javascript) da codice nativo. Disclaimer: lavoro per Future Platforms che hanno creato Kirin; abbiamo avuto un grande successo nell'usarlo su iOS con Javascript generato da Java con GWT, con il codice Java eseguito anche nativamente su Android.

Utilizzare le visualizzazioni Web ... ove appropriato

Le visualizzazioni Web a schermo intero hanno molto lavoro da fare per poter imitare le transizioni dello schermo e gli effetti di rimbalzo. Ma una visualizzazione web all'interno dell'app nativa di Chrome può essere indistinguibile da quella nativa.

Esistono metodi standard e ben documentati per la comunicazione tra app native e visualizzazioni Web.

Gli elenchi e le tabelle possono funzionare particolarmente bene se eseguiti in questo modo, tuttavia l'immissione di testo è un esempio di qualcosa che può essere gestito in modo nativo (per il pieno controllo della tastiera).

In sintesi

L'approccio giusto per te dipende da quanto è complicata la tua app e da quale livello di polacco dell'interfaccia utente sarai soddisfatto.

Il mio motto: utilizzare le visualizzazioni Web ovunque sia possibile, ma assicurarsi che gli utenti non possano dirlo .

Per prima cosa controlla questo sondaggio per sapere cosa sta succedendo!

confronto tra i tre tipi: Comprensione delle opzioni di sviluppo delle applicazioni mobili

Confronti tra nativo e iprid:

HTML5 vs nativo

HTML5 vs App nativa: quale scegliere ??

Questo è davvero buono: HTML5 v app native: considerazioni chiave per la tua strategia mobile

Commenti:

• Puoi sceglierne uno a seconda di ciò che hai (abilità) e cosa puoi ottenere (aspetto grafico, prestazioni, funzionalità, ...)
• Ogni sviluppatore di app mobili dovrebbe avere una visione / requisiti chiari sull'applicazione che sta sviluppando per le prime versioni e quelle future! solo per assicurarsi che l'opzione che avrebbe usato non lo limitasse ad un certo punto.
• Non c'è niente come avere una vera esperienza con i tre modi ed essere aggiornati allo stesso tempo, questo ti darà il senso e la capacità di prendere la giusta decisione.

Se è necessario accedere all'hardware del telefono, è necessario creare un'app nativa (in HTML5 è possibile accedere ad alcuni componenti hardware del dispositivo come il GPS).

Se ti senti più a tuo agio con lo sviluppo web, dovresti attenervi a meno che non sia necessario creare un'app nativa.

Per quello che dovresti sapere, direi che dovresti tenere a mente tutte le diverse dimensioni dello schermo (incluso l'orientamento verticale e orizzontale). Dovresti tenere a mente varie versioni del sistema operativo (questo è più per Android). Poiché si tratta di dispositivi mobili, esiste la possibilità che l'utente risponda a una telefonata, è un telefono e inoltre non ha la potenza di calcolo di un desktop o di un server.

Per me quando scrivo un'app di consumo, ciò che è fondamentale per il suo successo è l'accettazione e la percezione dell'app da parte dell'utente. Per questi quattro motivi a favore delle app native, nonostante i costi aggiuntivi associati all'apprendimento, alla formazione e alla perdita di WORA (scrivere una volta eseguito ovunque) sono:

1. Avvio più rapido dell'app
2. Scorrimento più fluido
3. Un'interfaccia più coerente che si collega in modo più coerente con il resto del sistema operativo e delle app
4. Risposta più rapida dell'interfaccia utente dell'app

Quello che vuoi sopra ogni altra cosa è un'ottima esperienza utente che aiuta la tua app ad avere successo in un mercato ridotto. Naturalmente ci sono eccezioni, in particolare mancanza di competenze, mancanza di tempo e budget. A volte le app sono rivolte a un numero limitato di utenti aziendali a cui potrebbero non interessare così tanto queste cose.

È ragioni simili a queste che Facebook ha abbandonato la sua strategia di app a favore di app native per IOS e Android:

Si prega di leggere:

Mark Zuckerberg: il nostro errore più grande era scommettere troppo su HTML5 http://techcrunch.com/2012/09/11/mark-zuckerberg-our-biggest-mistake-with-mobile-was-betting-too-much-on- HTML5 /

Perché Facebook ha abbandonato il Web mobile e è diventato nativo con la sua nuova app iOS http://readwrite.com/2012/08/23/how-facebook-ditched-the-mobile-web-went-native-with-its-new- ios-app # awesm = ~ o9jDrRefxdgnpS

Spero che sia di aiuto.

Con quanto segue, la mia posizione attuale su questa debacle è che l'ibrido è buono per iniziare, per esplorare la tua app, iterare rapidamente il feedback dei clienti e stabilizzare il set di funzionalità. Quindi, per riscrivere l'app in modo nativo in base alle specifiche, per migliorare l'esperienza.

Ho lasciato fuori Mobile Web, perché ha uno scopo completamente diverso. Se vuoi essere negli app store, Native / Hybrid è la strada da percorrere. Se vuoi semplificare l'implementazione e vuoi sacrificare l'esperienza e le capacità tecniche, scegli Mobile Web.

Pro / Contro nativo :

• Pro: si adatta al resto dell'esperienza del dispositivo, senza problemi inquietanti a valle .
• Pro: fornisce principalmente un'interfaccia utente uniforme e uniforme, senza ritardi, senza balbuzie.
• Pro: poche limitazioni tecniche, puoi utilizzare completamente il dispositivo.
• Pro: gli strumenti nativi garantiscono la conformità con la convalida degli app store.
• Pro: i framework nativi includono modifiche per versione della piattaforma, meno tempo dedicato alla messa a punto.
• Contro: è costruito per durare e quindi richiede più tempo per essere costruito.
• Contro: Richiede sviluppatori poliglotta che sono difficili da trovare, costosi.
• Contro: è necessario familiarizzare con le API di ciascuna piattaforma del dispositivo (iOS / Android / ecc.).
• Contro: curva di apprendimento ripida.
• Contro: set di strumenti diverso per piattaforma.

Pro / Contro ibrido :

• Pro: base di codice singola per il targeting di piattaforme di più dispositivi.
• Pro: cicli di sviluppo rapidi, grande flessibilità nel layout, perfetto per prototipazione e MVP .
• Pro: curva di apprendimento confortevole, molta documentazione, framework per aiutarti.
• Pro: set di strumenti di sviluppo singolo. Gli strumenti di debugger di Chrome sono eccellenti.
• Pro: una base di codice per targetizzare più piattaforme di dispositivi.
• Pro: molti sviluppatori disponibili, facili da imparare.
• Contro: richiede un framework UI decente per adattare l'interfaccia utente per ogni piattaforma diversa per essere coerente con l'esperienza del dispositivo. Esistono soluzioni come l' interfaccia utente di Kendo , Sencha Touch .
• Contro: è necessario essere molto consapevoli della memoria e dell'utilizzo del calcolo, alcuni CSS, i cicli javascript possono rallentare seriamente l'app. Strumenti non molto buoni disponibili sul dispositivo per il debug.
• Contro: non ancora maturato, le cose possono improvvisamente cambiare, ma gli strumenti stanno migliorando.

Essendo uno sviluppatore mobile, la cosa peggiore è l'accesso offline. Devi semplicemente forzare gli utenti ad essere online, il che dovrebbe funzionare in molte app, ma non in tutte.

L'altro aspetto negativo è la lentezza. Il tempo necessario per analizzare i dati remoti può richiedere molto tempo. Sì, puoi precaricare i dati durante il tempo di caricamento, ma in tutti gli altri casi non puoi evitare la lentezza.

Ho scoperto che tale app è diventata più costosa di quelle native. Non li consiglio più a nessuno dei miei clienti.

Il grosso problema con le app ibride è la frammentazione dei framework: ce ne sono chiaramente molti di più (Ionic, Xamarin, React Native, ecc.) Rispetto alle piattaforme mobili native (di solito solo due, Android e iOS). Questi framework competono, emergono, diminuiscono, quindi andare in ibrido non ti salverà dal saltare da una piattaforma all'altra anche se hai intenzione di mantenere la tua squadra attuale per tutta la vita.

Google e Apple stanno facendo del loro meglio per fornire e supportare editor, debugger, framework di test, strumenti di refactoring e altri mezzi per sviluppare per le loro piattaforme. Quindi prenderei una frase tipica " è molto più semplice sviluppare un'app ibrida, modificare con il tuo editor preferito e aprire in un browser " con la ragionevole riserva. Xamarin e React Native sono piattaforme di sviluppo, come lo sono Swift o Java / Android, e mentre "ciao mondo" può sembrare più breve, alla fine dovrebbe prendere il tempo comparabile per imparare correttamente.

Se, in ogni caso, dovesse sorgere la necessità di componenti nativi (ad esempio, la libreria di terze parti esistente deve essere integrata), ti ritroverai con tre framework anziché due: iOS, Android e il tuo framework ibrido in alto, finendo con un'architettura più complessa. Il debug di tali app, il passaggio da una chiamata all'altra, la registrazione di tutti i livelli, la sincronizzazione del codice a volte è complessa a volte impossibile.

Alcuni sostengono che "l' app avrà lo stesso aspetto per tutte le piattaforme ". È davvero una buona cosa? L'app per Android deve assomigliare all'app per Android e l'app per iOS deve apparire come l'app per iOS.

E le nuove funzionalità? Indossabili? App istantanee ora offerte dalla piattaforma Android? Visualizzazione di dati aggiuntivi su display esterno? Le app ibride ora supportano molte funzionalità native, ma le supportano davvero tutte ? In qualsiasi momento, immediatamente?

Infine, non solo le prestazioni e l'esperienza utente, ma anche la sicurezza potrebbe essere più dal lato dell'app nativa. Il framework ibrido aggiunge il livello di riferimento indiretto che può avere bug propri, inclusi bug di sicurezza.

Concludendo tutto quanto sopra, con la possibilità di scegliere, sceglierei sicuramente le due app native, una per iOS e una per Android o in alternativa progetterei semplicemente una versione mobile del sito Web senza preoccuparmi dello sviluppo di app per nessuna piattaforma. .