30 January 2012
Category:
blog
Comments: 2

App Native, Web ed Hybrid

Scegliere la migliore soluzione per la propria Mobile App

Introduzione

La storia recente e l’evoluzione del mondo Mobile sono cose note a tutti: da quando è comparso il termine App, continuiamo giorno dopo giorno ad assistere ai mutamenti e agli adattamenti delle tecnologie coinvolte in questo mondo e di quelle che cercano di entrare nel circus.

Forse per la prima volta, concetti molto tecnici dell’informatica stanno arrivando per propulsione mediatica al grande pubblico e talvolta si instaurano concetti non propriamente corretti che è bene ridefinire.

App Native vs WebApp (e il terzo incomodo)

La più sintetica definizione per un’app nativa è: applicazione mobile tradizionale, compilata, scritta usando IDE (Integrated Development Environment) e librerie specifici e proprietari, e installata sui nostri Smartphone e Tablet tramite vetrine digitali chiamati Store (Market, AppWorld etc).

L’app nativa è quanto di più integrato si possa sviluppare per un dispositivo Mobile, perché può integrare in modo naturale tutte (o quasi) le feature messe a disposizione dai vendor: le nostre App “vivono” nel device, ne fanno parte integrante come tassello di funzionalità. Non ultimo, l’aspetto economico di revenue sharing promosso dai vendor stessi favorisce e stimola la creazione di nuove App continuamente.

Tuttavia, con un ritmo impressionante, il mondo Web ha cercato di colmare la precedente divergenza tecnologica. Mediante l’introduzione di HTML5, CSS3 e specifiche librerie Javascript, normali applicazioni web permettono di simulare l’aspetto delle interfacce proprie di app native, creando quindi il concetto di app web-based o webapp.

Per la loro natura, queste applicazioni portano con sè notevoli limitazioni, essendo destinate ad alto livello (browser del device) e tenute a debita distanza dalla visibilità enorme dei marketplace digitali.

Fino a questo punto è tutto semplice: durante un’analisi di fattibilità per app mobile, riusciamo a capire quale strategia intraprendere in base alle sue necessità. Ad esempio, ci chiediamo:

  • la nostra App richiede feature specifiche proprie del terminale, deve salvare dati, deve essere acquisibile a pagamento da uno Store? Sarà nativa.
  • Consiste invece in una gerarchia di contenuti e di navigazione? Potrebbe essere webapp.

E il terzo incomodo?

E’ denominato hybrid app, e rappresenta l’anello mancante tra i due modelli appena descritti . Consente di costruire app compilate (native) ma dotate di strumenti di gestione di interfacce HTML (webapp). Lo scopo di tale unificazione è chiaramente quello di trarre i vantaggi da entrambe le tipologie e di consentire un miglioramento dell’intero processo di costruzione delle App in chiave RAD (Rapid Application Development).

Il principale vantaggio della metodologia ibrida è riscontrabile nella naturale propensione alla multi-platform, con conseguente vantaggio nella replicazione di alcune app per classi di device differenti.

Le app Ibride sono la soluzione?

Dipende. Nulla è più relativo dello sviluppo Mobile, e il playground (le necessità, i requisiti, le ipotesi di integrazioni future) determina in gran parte lo strumento da usare per lo sviluppo.

Quello che ci possiamo limitare a fare è comparare le tre metodologie, raffrontando gli oggettivi punti principali di forza e debolezza di ciascuna di esse.

Lo schema seguente identifica questa comparazione:

In prima analisi, il modello ibrido rappresenta un buon compromesso tra le due categorie principali, e spesso offre un vantaggio in termini di velocità di realizzazione, per lo meno per quanto riguarda aspetti di User Interface e navigazione.

Quindi, un singolo approccio (ibrido) per tutti?

In una parola: no. Ci sono 3 fattori principali che determinano la scelta tecnologica, e che vanno tenuti in considerazione in modo equivalente:

  • Target dell’App: a chi si rivolge l’app? L’audience è mono-brand o ripartita per vendor e device? È tendenzialmente un target online?
  • Requisiti funzionali: cosa deve poter fare l’app? Stendere una lista delle funzionalità necessarie aiuta a determinare facilmente che strada percorrere
  • Tempi e Budget: il tempo necessario allo sviluppo dell’app è il principale fattore di modifica del costo. Web apps, a fronte di limitazioni evidenti, consentono d’altra parte tempi di sviluppo più brevi e conseguente risparmio economico

Nell’ambito B2B, esperienza insegna che il miglior modello di sviluppo va studiato con il cliente dopo aver esplorato insieme l’idea applicativa, i requisiti attuali e il target dell’app, oltre che i suoi possibili future trends.

Conclusione, attendendo nuovi modelli di sviluppo

Lo sviluppo Mobile è strategico, non semplice tattica. Gli strumenti attuali permettono di effettuare una scelta consapevole e non preclusiva, che diventa vincente quando è dettata dalla conoscenza completa della propria idea applicativa, unita ad un’attenzione costante alle evoluzioni di questo mondo.

Alessandro Giacomella
CIO Digitnut

2 responses on “App Native, Web ed Hybrid

  1. Un esempio pratico avrebbe giovato nel favorire la chiarezza. Mi permetto di suggerirne uno. Si tratta di una applicazione “morta” nel senso che fu sviluppata per una società che adesso è stata sciolta, per cui nessuna pubblicità occulta 🙂 Soprattutto era una applicazione destinata a computer desktop (a volte server) quindi non propria del mondo mobile, ma credo possa aiutare chi non è del mestiere a capire.

    Un sistema ibrido potrebbe consiste in pratica in un “connettore” tra l’interfaccia web e l’host (il device, nel caso del mobile) consentendo di eseguire cose che la webapp non potrebbe. Nell’esempio che propongo si trattava di una applicazione che permetteva il controllo di un ambiente domotico, cioè di automazione domestica, attraverso una interfaccia che era disponibile attraverso un normale brower web. L’applicazione tuttavia essendo residente poteva fare cose impossibili altrimenti, cioè codificare messaggi in un protocollo macchina usato dai dispositivi di controllo di automazione domestica, ad esempio l’invio di un comando per impostare una temperatura, o impostare un ciclo automatico di apertura controllata delle serrande al mattino, o ancora registrare dati (esempio i consumi elettrici) nel device host, in questo caso ricevuti dal sistema di automazione.
    Ebbene tutto questo viene realizzato dall’applicazione, che svolge un ruolo da dietro le quinte, mentre l’utente vede l’interfaccia webapp che può essere sia residente sullo stesso device sia su unità non locali (in questo caso effettivamente mobili).

    Saluti

    • Alessandro says:

      Ciao Claudio,
      grazie per la risposta.

      Un sistema hybrid nel contesto mobile è in realtà qualcosa di diverso rispetto all’esempio che hai descritto (il tuo è un sistema client-server che può essere benissimo declinato su diversi tier applicativi).

      Nell’ambito della discussione, un’app ibrida va vista come un’app nativa con “qualcosa in più”, ovvero:
      – un sistema di gestione di interfacce utente html invece che compilate
      – un sistema di traduzione input/output (bridge) che consente, ad esempio, di interpretare i gesture di touch, swipe, etc da html come se arrivassero dalle normali view compilate.

      E pur essendo possibile costruire autonomamente il proprio middleware di bridge tra l’app e la sua nuova interfaccia, esistono molti framework che possono essere integrati in pochi minuti nella propria app (phonegap, appcelerator, etc).

      Alessandro

Leave a Reply

Your email address will not be published. Required fields are marked *