Ogni anno vengono effettuati miliardi di download di applicazioni mobile da milioni di utenti sparsi per il mondo, ad un punto tale che molti paragonano il creare un app e pubblicarla nei vari stores ad una vera propria miniera d’oro. Ed il numero sta crescendo a dismisura.

La stima dei numero di download di applicazioni mobile nei prossimi anni

Tuttavia, se in alcuni casi gli app stores hanno rappresentato (e rappresentano ancora) una grandissima fonte di ricchezza (come Ruzzle o FlappyBird, tanto per citare le prime app che mi vengono in mente), per ogni app di successo ce ne sono migliaia che non riescono a decollare.

Il fatto è che quando si parla di creare un app, puntualmente ci vengono presentati solamente quei progetti che hanno raggiunto la vetta. E tutte quelle applicazioni che al contrario hanno fallito?

La dura verità: le app che non hanno successo

In particolare, di tutti i milioni di applicazioni scaricate, solo un piccolissima parte (circa il 5/10%) viene effettivamente utilizzata dopo la prima volta.

Quante volte ti sarà capitato di scaricare un’app nel tuo smartphone o tablet, dargli un’occhiata veloce, per poi non aprirla mai più, o addirittura cancellarla?

A seconda dell’utente, la maggior parte delle applicazioni vengono completamente ignorate o cancellate dopo il primo utilizzo.

Il mio iPhone è continuamente colmo di applicazioni di vario tipo, ed ogni giorno mi presenta minimo 50 notifiche di aggiornamenti da effettuare per applicazioni che non ricordo nemmeno di avere.

Così, periodicamente, appena riesco a ritagliarmi un attimo di tempo, mi metto a cancellare tutte quelle app che non mi piacciono o che non utilizzo.

Ma dopo qualche giro di esplorazione su App Store, sono di nuovo al punto di partenza.

E credo che questo sia lo stesso scenario della maggior parte degli utenti che possiedono un dispositivo mobile.

Da cosa dipende?

Semplice: dall’utilità dell’applicazione.

Prima di perdere tempo con la creazione di un’applicazione, cerca di capire se è effettivamente utile

Verifica l’utilità della tua applicazione

Molti vengono a chiederemi delle consulenze per progetti riguardanti applicazioni mobile che risultano veramente inutili, come se si dimenticassero che qualsiasi smartpthone o tablet possiede un browser.

Ora ti chiederai: “cosa c’entra il browser con l’app?”

C’entra eccome.

Uno dei miei clienti (per il quale ho realizzato un e-commerce con WordPress) sapendo che oltre a siti ed applicazioni web mi occupo anche della realizzazione di mobile app,  qualche tempo fa si era fissato con l’idea di voler creare a tutti i costi un’applicazione mobile che offrisse all’utente tutte le funzionalità dell’e-commerce che gli avevo già sviluppato.

Che senso avrebbe avuto realizzare l’applicazione di un’e-commerce già ottimizzato per dispositivi mobile, e quindi già facilmente fruibile da un normale mobile browser?

Provai a spiegargli l’inutilità della cosa, ma non mollò la presa, nemmeno dopo avergli mostrato il mio preventivo.

Morale: il cliente finì per spendere alcune migliaia di euro per un’ottima e funzionale applicazione, ma che non venne mai utilizzata da nessuno (dei circa 900 utenti che avevano effettuato il download nell’arco di un anno, non registrammo nemmeno un acquisto da dispositivi mobili).

Completo fallimento.

Pensaci bene: prima di metterti a testa bassa e impegnarti nella realizzazione di un’applicazione mobile, cerca di capire quali funzionalità e contenuti deve avere.

Se si tratta di elementi disponibili anche su un normale web browser, allora la verità è che non hai bisogno di un’applicazione mobile, o almeno di un’applicazione da distribuire sui vari stores.

Molte delle funzionalità come la geolocalizzazione o il salvataggio dei dati (leggi questo articolo oppure questo per saperne di più) possono essere implementate anche in normali siti web.

Una buona soluzione che personalmente adotto molto spesso è quella di creare una versione mobile del sito web, utilizzando delle tecniche per realizzare HTML Mobile app fluide ed altamente performanti.

In questo modo è possibile creare un’applicazione mobile a tutti gli effetti, ma che sia accessibile anche da un normale browser mobile, e che allo stesso tempo possa essere facilmente trasformata in un’applicazione ibrida, grazie adei tools come Phonegap o Titanium.

È la stessa cosa che ha fatto per esempio Financial Times con la sua applicazione mobile.

Conclusioni: in base a quali fattori puoi capire se tu o il tuo cliente avete veramente bisogno di un app?

Per capire se hai veramente bisogno di creare un’applicazione da poter scaricare nei vari stores, i metri di giudizio ai quali dovresti affidarti e su cui focalizzarti sono:

1. posso fornire all’utente le stesse funzionalità con un normale sito web responsive?
2. quanto tempo, risorse e denaro dovrei impiegare per creare un app e quali per creare un sito web che offra le stesse funzionalità?
3. qual è lo scopo finale (effettivo) del tuo progetto/lavoro?
4. quali sono le reali esigenze dell’utente?

Più semplicemente, se hai bisogno di offrire un prodotto che deve essere accessibile da diversi tipi di dispositivi (sia da quelli desktop che da quelli quelli mobili) allora la miglior cosa è sicuramente optare per una versione responsive del sito web.

Nei vari app stores possiamo trovare un numero sempre più grande di applicazioni che integrano il login di Facebook al proprio interno per dare la possibilità all’utente di effettuare l’accesso molto più comodamente e velocemente, evitando di costringerlo ad iscriversi ad un nuovo servizio, con tutti i rischi che tale operazione comporta (come per esempio perdere una grande fetta di utenti).

Per aggiungere questa funzionalità nei miei progetti da pubblicare come applicazioni ibride (mobile app in HTML5 “inglobate” all’interno di app native), ho sempre utilizzato il plugin Phonegap “Phonegap Facebook Plugin“, che utilizza una combinazione dei “moduli” nativo e javascript messi a disposizione dall’SDK di Facebook.

Grazie al Facebook Plugin di Phonegap è quindi possibile “manovrare” il login nativo mediante delle semplici API javascript.

 

In fondo è proprio questo lo scopo dei plugin per Phonegap, ed anche un dei vantaggi di sviluppare mobile app in HTML5: quello di riuscire ad accedere alle funzionalità native del dispositivo direttamente da codice Javascript.

Tuttavia questa strada porta alcuni svantaggi, come quello di dover comunque dipendere da un plugin di terze parti, oppure quello di non poter essere utilizzato nel caso in cui non volessimo distribuire la nostra applicazione HTML5-CSS3-Javascript sotto forma di app ibrida (compilandola quindi con strumenti come Xcode o Eclipse), ma volessimo renderla accessibile in remoto, collegandosi semplicemente ad una pagina web (come per esempio hanno fatto Financial Times e Forecast.io con le loro HTML5 mobile app, vedi immagine seguente).

 

Le applicazioni HTML5 ottimizzate per mobile di Financial Times e Forecast.io

---

#facebook #mobileapp login – Come implementarlo in #HTML5
Click To Tweet

---

Facebook mobile login: una strada alternativa

In questo articolo ti voglio mostrare una risorsa molto interessante, che ho trovato utilissima  per poter implementare un Facebook mobile login su di un’HTML5 mobile app senza necessariamente utilizzare dei tools nativi, come il plugin per Phonegap sopra citato.

Si tratta di una micro-libreria Javascript realizzata da Christophe Coenraets, brillante sviluppatore professionista che lavora per Salesforce.com (ti consiglio vivamente di seguirlo, se sei interessato a come creare un app in HTML5, CSS3 e Javascript), il cui lavoro è principalmente focalizzato sullo sviluppo di applicazioni mobile web-based ( quindi single-page-application).

La libreria si chiama OpenFB e risulta molto utile per poter implementare il Facebook mobile login sulla propria applicazione, senza affidarsi necessariamente a dei componenti nativi.

Coenraets, che avendo la necessità di implementare questa funzionalità in uno dei suoi lavori ha pensato di adattarla in una soluzione standard in modo tale che tutti potessero usufruirne, ha dato la possibilità a chiunque di inserire facilmente il login di Facebook nel proprio progetto.

---

#facebook #mobileapp login – Come implementarlo in #HTML5
Click To Tweet

---

Facebook mobile login: come si usa la libreria OpenFB

Utilizzare la libreria si presenta piuttosto semplice, vediamo come funziona:

Semplice Login:

openFB.login(scope, successHandler, errorHandler);

Riprendere la lista degli amici dell’utente:

openFB.api({path: '/me/friends', success: successHandler, error: errorHandler});

Pubblicare un post nella bacheca dell’utente:

openFB.api(
{
     method: 'POST',
     path: '/me/feed',
     params: {
          message: 'Messaggio di prova per le API di Facebook'
     },
     success: successHandler,
     error: errorHandler
});

Facebook mobile login: primi passi

Per integrare la risorsa nei tuoi progetti hai solamente bisogno di:

1. Creare un’applicazione Facebook da associare al tuo progetto recandoti a questo link
2. Copiare l’ID dell’applicazione Facebook appena creata ed usarlo come primo parametro della funzione di inizializzazione della libreria OpenFB posta nella pagina principale della tua Single Page Application (index.html): openFB.init().
3. Eseguire la pagina index.html da un indirizzo che corrisponda a quello inserito al momento della creazione dell’applicazione Facebook, in corrispondenza del parametro “Valid OAuth redirect URIs” situato nella scheda “Settings”.

---

#facebook #mobileapp login – Come implementarlo in #HTML5
Click To Tweet

---

Facebook mobile login: conclusioni

Come vedi il funzionamento è piuttosto semplice, e chiunque può facilmente integrarlo nella propria applicazione, app che non deve essere necessariamente distribuita sotto forma di app ibrida/nativa ma che può essere benissimo pubblicata online.

Infatti l’autore della libreria mette a disposizione anche la demo di un’applicazione-base che puoi consultare per capire meglio come integrare OpenFB nella tua Single Mobile Application; la demo che funziona anche se visualizzata con un normale browser, sia mobile che desktop.

In particolare, la libreria è stata pensata per fare in modo che il Facebook mobile login funzioni sia nel caso in cui il progetto preveda l’utilizzo di Phonegap (quindi nel caso di un’applicazione ibrida), sia nel caso di applicazioni “browser-based“: se eseguita con Cordova essa sfrutta una web view nativa, mentre se eseguita su browser, il login sarà mostrato attraverso una finestra di popup.

Io l’ho già implementata in una mia applicazione, e la trovo molto utile.

Ma mi piacerebbe sapere il tuo parere: cosa ne pensi?

Fammelo sapere nei commenti!

PS. Quasi dimenticavo: ecco il link all’ottimo ed utilissimo articolo originale di Coenraets, ai sorgenti e alla demo:

Per creare una Mobile App in HTML o una qualsiasi web app javascript è fondamentale organizzare il progetto secondo una struttura ben adeguata, evitando di produrre codice secondo la “non-logica” Spaghetti Code (leggi questo articolo per saperne di più).

Come già affrontato in altri numerosi post, adottare una logica di sviluppo basata sull’MVC può aiutare notevolmente lo sviluppatore a raggiungere tale obiettivo.

Un altro metodo molto utile per mantenere il codice scalabile e mantenibile, oltre che aumentare le performance dell’applicazione, consiste nell’utilizzo di sistemi di Javascript templating in stretta relazione con le view, che si occupano della rappresentazione visiva dei vari componenti dell’interfaccia.

I sistemi di templating Javascript consentono infatti di generare il markup dinamico di una determinata view (leggi questo articolo che ho scritto per YourInspirationWeb  per sapere come utilizzare una view con backbone.js) in base ai dati che gli vengono passati al momento della compilazione.

Prima di entrare più nel dettaglio, vediamo quali sono solitamente le alternative adottate per la generazione di markup in una Mobile App sviluppata in HTML5, CSS3 e Javascript.

---

Come creare #MobileApp in #HTML5: il sistema di #javascript templating
Click To Tweet

---

Creare Mobile App in HTML: come viene generato solitamente il markup

Siccome in una HTML5 Mobile App tutta la generazione del markup e degli elementi DOM dell’interfaccia avviene tramite linguaggio lato-client, e quindi tramite javascript, generalmente si tende a seguire 3 strade principali per inserire il codice HTML di ogni schermata (o view) all’interno del progetto:

1 – Effettuare chiamate ajax che restituiscono dati HTML da un server remoto.

Rappresenta secondo me il tipo di approccio più sbagliato.

Stiamo parlando di applicazioni mobile e ciò comporterebbe il trasferimento di una grande quantità di dati e tempi di attesa più lunghi, soprattutto se l’utente sta usando l’applicazione in una zona fisica in cui il traffico è limitato o quasi assente.

Senza contare il fatto che il codice restituito (stringa formata dall’HTML generato dal server) risulta difficile da interpretare per l’applicazione JavaScript, e solitamente necessita di un’adeguata formattazione prima dell’immissione all’interno del documento.

La comunicazione in remoto dovrebbe essere pertanto utilizzata solo al fine di reperire o inviare dati “puri” (come per esempio un oggetto JSON).

2 – Inserire l’HTML di tutte le schermate nel documento

Per creare una Mobile App in HTML si utilizza un file principale index.html. 

Secondo questo metodo all’interno di quel file viene inserito tutto il markup necessario per far funzionare l’applicazione, relativo a alle varie view che la compongono.

Può andar bene per progetti formati al massimo da 4/5 schermate, dopo di ché diventa facile smarrirsi nei meandri del codice HTML come un bambino di 3 anni in un bosco.

Se poi consideriamo il fatto che in quelle view possiamo avere la necessità di inserire dati dinamici, per aggiungerli al DOM dovremmo comunque servirci di codice Javascript, utilizzando così non uno, ma due tipi di approcci diversi per lo stesso scopo (1 – html statico, 2 – generazione di markup via javascript).

Inoltre, inserire tutti i nodi DOM all’interno del documento riduce notevolmente le prestazioni di rendering, a causa del numero di elementi HTML per i quali la CPU è costretta a ricalcolare gli stili nel momento in cui si verifica qualsiasi modifica CSS, oppure ogni volta che un elemento si sposta nello schermo (quando ciò questo accade vengono coinvolti nello spostamento anche altri nodi del documento).

3. Generare codice tramite javascript con una concatenazione di stringhe

E’ provato che creare grandi blocchi di codice HTML tramite una concatenazione di stringhe riduce drasticamente la velocità per le prestazioni di esecuzione, in quanto la variabile in-memory utilizzata per svolgere tale operazione va ad occupare parte della CPU.

Coloro che adottano questa tecnica inoltre, si perdono spesso in cicli nidificati in cui non si capisce quale tag chiude l’altro, e dove non si riesce a distinguere dati puri dall’HTML.

Ecco un possibile esempio di questa tecnica:

var markup = "<div class=\"main-wrapper\">"+
				"<header class=\"page-header\" role=\"header\"><h1 class=\"\"></h1></header>"+
				"<section class=\"page-section\"></section>"+
				"<ul class=\"contacts-list\">";

			for(var i=0;i<contacts.length;i++){
				markup+="<li class=\"contact-list-item\">"+contacts[i].name+" "+contacts[i].surname+"</li>";
			}

			markup+="</ul></div>";

$(".content").append(markup);

 

E’ preferibile invece lasciare libera la memoria del dispositivo per le operazioni di rendering, che influiscono sulla user-experience del prodotto finale, così come è preferibile lasciare separati codice HTML da codice Javascript, in modo da aumentare la mantenibilità e la scalabilità del progetto e poter facilmente riutilizzare uno stesso template in diverse parti.

Creare Mobile App in HTML: il funzionamento dei sistemi di templating

Gli sviluppatori javascript hanno a disposizione diversi framework di templating per generare via client il markup HTML delle view che compongono le loro applicazioni (come per esempio Handlebars.js, Mustache, o il sistema interno al framework underscore.js).

Per conoscere anche altri sistemi di javascript templating, ti consiglio di leggere questo mio precedente articolo:

• I sistemi di javascript templating e le migliori librerie

I template possono essere savat in variabili in-memory, in file HTML indipendenti o all’interno del documento, solitamente racchiusi in tag <script> con un attributo “type” personalizzato (per esempio “text/template”:  “<script type=“text/template”> <!– markup del template —> </script>”).

---

[Tweet “Come creare #MobileApp in #HTML5: il sistema di #javascript templating
Click To Tweet

---

“]

Ogni template ha accesso a delle variabili, a seconda dei dati che gli vengono passati.

Utilizzare le variabili è molto semplice e generalmente è possibile farlo all’interno di appositi delimitatori, il cui funzionamento non è molto diverso da quello della generazione del markup HTML dinamico tramite i più diffusi linguaggi lato-server (ASP, PHP, C# ecc.).

Il lavoro è reso ancora più facile per il fatto che la maggior parte di questi sistemi accetta dati in formato JSON (formato in cui può essere convertito facilmente qualsiasi tipo di dati).

I delimitatori delle variabili possono differire a seconda del framework utilizzato, ma il funzionamento logico rimane pressoché sempre lo stesso.

Due sono le categorie principali in cui si suddividono i vari tipi di sistemi di templating:

• embedded javascript, comprende i frameworks che permettono l’utilizzo di codice javascript all’interno dei propri template
• logic less, comprende quelli che non permettono l’utilizzo di javascript al loro interno, ma limitano l’uso di logiche come cicli e condizioni a sintassi personalizzate

Vediamo il funzionamento del sistema di templating di underscore.js, che appartiene alla prima categoria, e che può essere utilizzato per creare mobile app in html con il framework MVC Backbone.js.

Più concretamente, vediamo l’esempio di un ciclo che genera in maniera dinamica l’HTML necessario per mostrare una lista di individui.

Consideriamo di dover generare il markup della lista servendoci dei seguenti dati in formato JSON:

{
	'employees': [
		{‘name': ‘Giacomo Freddi’, occupation: ‘Web Designer / Front-End Developer’},
		{‘name': ‘Mario Rossi’, occupation: ‘CEO’},
		{‘name': ‘Franco Mancini’, occupation: ‘Web Marketer’},
		...
	]
}

Ecco come potrebbe presentarsi il template secondo il sistema di templating di underscore.js

<ul>
   <%for(var i=0;i<employees.length;i++){%>
   <li><%=employees[i].name%> - <%=employees[i].occupation%></li> 
   <%}%>
</ul>

In tal caso il risultato del markup generato sarebbe:

<ul>
   <li>Giacomo Freddi - Web Designer / Front-End Developer</li>
   <li>Mario Rossi - CEO</li>
   <li>Franco Mancini - Web Marketer</li>
   …
</ul>

Con i javascript templating lo sviluppatore ha sicuramente una cosa in meno a cui pensare, in quanto la maggior parte del lavoro di generazione del markup viene svolto dal sistema stesso.

Creare mobile app in HTML: i benefici del sistema di templating

Ciò porta ad un gran numero di benefici nel creare mobile app in HTML o qulasiasi single page application, in particolare se si decide di salvare i template di ogni view all’esterno del documento principale dell’applicazione (index.html), inserendo ognuno di essi in un apposito file (es.: nome-della-view.html).

Il contenuto del file viene poi caricato dinamicamente, solamente se e quando abbiamo bisogno di effettuare il render di quella view all’interno dell’interfaccia.

Quello appena esposto è il metodo che preferisco, in quanto permette di separare completamente all’interno del progetto il concetto di templating da tutto il resto (sinonimo di mantenibilità e scalabilità) e, nel senso più “fisico” del termine, ogni view dall’altra.

Così facendo è possibile mantenere la struttura dei file dell’applicazione ancora più organizzata.

Bisogna comunque  fare attenzione al fatto che i template non rappresentano di per sé delle view, bensì lo strumento grazie al quale esse possono effettuare il render del markup HTML che le rappresenterà all’interno del documento. Molti sviluppatori spesso confondono il concetto di view con quello di template, ma non sono assolutamente la stessa cosa.

Una view è un oggetto che che osserva un modello dati (in MVC i cosiddetti model) e mantiene la propria rappresentazione visiva aggiornata in base ad esso. Una view è definita da codice Javascript.

Il template potrebbe essere lo strumento di cui si serve la view per generare parte del proprio markup necessario alla visualizzazione, o di tutto il markup necessario.

---

Come creare #mobileapp in #HTML5 – i benefici del #javascript #templating
Click To Tweet

---

Conclusioni

Oltre che per creare mobile app in HTML o qualsiasi altro tipo di web app sviluppata in HTML, CSS3 e Javascript, i sistemi di templating sono molto utilizzati anche per la realizzazione di siti web che forniscono una user-experience di qualità molto elevata.

Solitamente gli sviluppatori front-end più affermati si servono di sistemi di javascript templating per generare markup da template salvati in file .html esterni, o dichiarati all’interno della pagina in appositi script personalizzati.

E tu hai mai utilizzato i sistemi di javascript templating? Ne hai privato qualcuno da suggerire? Scrivilo nei commenti e sarò felice di risponderti!

Più volte ho discusso l’importanza di usare i pattern di sviluppo MVC nella realizzazione di applicazioni web ed HTML5 Mobile App realizzate in Javascript e CSS3: scrivere codice come capita e senza alcuna logica può andar bene per progetti di piccolissime dimensioni o singole pagine web, ma se stiamo parlando di una single page application, quindi un’applicazione in cui il codice lato-client gestisce, oltre ai dati, anche la generazione di markup, il discorso cambia.

 

Spaghetti code

E’ ciò che dobbiamo evitare in quei casi. In altre parole dobbiamo evitare di sviluppare single page application e web app senza un’architettura logica che ci consenta di scrivere codice ben organizzato, facilmente leggibile, mantenibile e riusabile.

Questo è lo scopo principale dei metodi di sviluppo MVC.

Abbiamo visto quanto possono essere importanti le view nel web in generale e perché considerare di usare un framework javascript MVC per la realizzazione di HTML5 Mobile App.

In un post che ho scritto per YourInspirationWeb, metto in evidenza l’importanza dell’impiego delle view in ambito web ed il perchè esse sono così importanti:

• HTML5 Mobile App: il web ha bisogno delle view

---

#HTML5 #MobileApp definire la struttura dati con #backbonejs
Click To Tweet

---

HTML5 Mobile App: MVC per rendere il javascript mantenibile e riusabile

Per molti anni il pattern di sviluppo MVC è stato usato in moltissimi linguaggi di sviluppo. Al giorno d’oggi, tutti i web designer e front-end developer hanno già cominciato da qualche tempo ad applicare la logica MVC al linguaggio che per noi risulta più rilevante: il Javascript.

Con il Javascript abbiamo a disposizione diversi tipi di frameworks che offrono supporto per l’MVC nelle sue numerose variazioni ( la famiglia di pattern MV*), permettendoci di estendere la struttura delle nostre applicazioni senza troppe difficoltà.

Alcuni dei frameworks più famosi possono essere per esempio Backbone o AngularJS. Il loro ruolo è fondamentale, in quanto consentono allo sviluppatore di evitare la scrittura del codice in modalità Spaghetti code. Pertanto è importantissimo capire di cosa possiamo beneficiare con un adeguato pattern di programmazione.

In un precedente articolo avevo spiegato come realizzare una semplice HTML5 Mobile App con Backbone.js:

• Semplice HTML5 Mobile App con Bootstrap Ratchet e Backbone.js

In questo capitolo ti voglio mostrare più nel dettaglio una delle parti che compongono l’acronimo MVC: il model (o modello).

Lo farò in relazione ad uno dei sopra citati framework MVC, ovvero Backbone.js, che è proprio quello che approfondiremo per la realizzazione di HTML5 Mobile App.

Gestire i dati con il model per una HTML5 Mobile App

I modelli costituiscono i dati dell’applicazione.

Un modello può rappresentare per esempio un individuo, una nota, un articolo, un libro, o qualunque altra entità che possa avere 1 o più caratteristiche (nome, cognome, sesso, codice ISBN, matricola, colore, ecc..).

I modelli possono essere visti in modo completamente separato dagli elementi che compongono l’interfaccia-utente, anche se quando un modello subisce delle modifiche, esso normalmente avvisa gli “osservatori” (altre parti della struttura come per esempio le view – viste ) che si è verificato un cambiamento, permettendogli di agire di conseguenza.

Facciamo un esempio concreto al fine di comprendere meglio i modelli. Più nello specifico, prendiamo come punto di riferimento Tint, la mia applicazione per il meteo.

In una normale applicazione meteo, il concetto di località ha bisogno di un suo modello che la rappresenti come un tipo di dato unico, con delle specifiche caratteristiche, che possono essere il nome (città o luogo), la latitudine, la longitudine, il paese di appartenenza ed altri possibili dati aggiuntivi.

Una specifica località potrebbe essere salvata nell’istanza di un model, che sarebbe accessibile e riusabile in più parti dell’applicazione.

Vediamo la definizione di un semplice modello che rappresenta il tipo di dati “località” con Backbone.js:

var LocationModel = Backbone.Model.extend({

	initialize:function () {
	//ci assicuriamo che ogni modello appena creato abbia un ordine numerico
	if( isNaN ( this.get(“order”) ) )
		this.set( {“order”, 0 } );
	},

	//dati predefiniti per la località

	defaults:{
		defaultLocation: false,
		userLocation: false,
		viewed: false
	}

});

---

#HTML5 #Mobileapp come definire un model con #Backbonejs
Click To Tweet

---

La funzionalità integrate dei modelli variano a seconda del framework utilizzato, ma generalmente tutti i framework danno la possibilità di definire gli attributi, ovvero le proprietà di ogni modello, (come per esempio la cilindrata, il colore, la gamma o la marca per un ipotetico modello “macchina da strada”).

Backbone, come molti altri MVC frameworks, offre anche la possibilità di salvare i dati secondo varie modalità, come per esempio il localStorage o la sincronizzazione con un database.

Per avere maggiori informazioni sul metodo di salvataggio dei dati, ti consiglio di leggere  questo articolo che ho scritto per YourInspirationWeb.com:

• HTML5 Mobile App: tecniche per il salvataggio dei dati

Gli osservatori dei modelli

Un modello può avere anche diverse view (parti visuali dell’interfaccia) che lo stanno “osservando”, pronte a reagire ad eventuali cambiamenti.

Ritornando all’esempio di Tint, ogni località presenta la lista dei giorni e relativo meteo, oltre che una lista di orari, anch’essi ciascuno con la relativa condizione meteo.

L’applicazione usa 3 diverse view per ognuna delle località:

• la view per mostrare i dati principali e il meteo attuale del luogo
• la view per mostrare il meteo nelle prossime ore della giornata
• la view per mostrare il meteo nei prossimi giorni della settimana

Tutte le view sopra elencate risultano “associate” allo stesso modello, e osservano eventuali cambiamenti che lo stesso può avere.

Backbone.js e HTML5 Mobile App: le collection

Nella maggior parte dei framework MV*, i modelli possono essere organizzati in gruppi: con Backbone.js tali gruppi vengono chiamati “Collection” (o collezioni).

Gestire i modelli in collezioni aiuta a sviluppare applicazioni secondo una logica che permetta non osservare ciascun modello individualmente, ma reagire di conseguenza a qualunque modello che subisce delle modifiche in maniera “centralizzata”.

Per comprendere meglio questo concetto, prendiamo di nuovo l’esempio su Tint: consideriamo 2 view in particolare, tra quelle che compongono l’interfaccia:

• la view ManageLocations: quella che consente di aggiungere, eliminare o modificare l’ordine delle località
• la view Locations: che viene mostrata subito dopo l’avvio dell’applicazione ed offre all’utente la possibilità di scorrere orizzontalmente le varie località secondo l’ordine con cui esse sono state organizzate nella prima view menzionata. Questa view si preoccupa di creare per il modello di ogni località presente nella collection la relativa “sotto-view” inserendola al suo interno.

L’applicazione è impostata in modo tale che la view “Locations” osservi i cambiamenti della collezione “LocationCollection”, la quale contiene tutti i modelli di ciascuna località aggiunta dall’utente, oltre a quella relativa alla sua posizione.

Così, non appena un‘utente aggiunge, elimina o modifica l’ordine di una località usando la view delle impostazioni (ManageLocations), la view Locations aggiunge la view associata al nuovo modello, rimuove quella del modello eliminato, o, qualora si trattasse di un riordinamento, reinizializza lo slider orizzontale.

 

Di seguito ti mostro l’esempio della definizione di una Collection di località tramite Backbone.js, che ho usato per Tint:

var LocationCollection = Backbone.Collection.extend({

	//definisce a quale modello di riferisce la collezione
	model: LocationModel,

	//definisco che il metodo di salvataggio per collection debba essere il localStorage (voglio salvare tutte le località aggiunte dall’utente nel dispositivo,
	//in modo da potergliele ripresentare al prossimo avvio)
	localStorage: new Backbone.LocalStorage("Parallax_Weather-locations"),

	//funzione che ho usato per generare in modo sequenziale l’ordine di ogni nuovo model,
	//per far sì che possa essere aggiunto all’ultimo posto

	nextLocation: function(newModel) {
		if (!this.length) return 1;
		return this.last().get('order') + 1;
	},

	//definisco la modalità di ordinamento dei modelli, in questo caso in base all’attributo ‘order'
	comparator: function(location) {
		return location.get("order");
	}

});

---

#HTML5 #MobileApp definire un #collection con #Backbonejs
Click To Tweet

---

Conclusioni

L’astrazione dei dati è un fattore fondamentale nella realizzazione di qualsiasi progetto web, e lo diventa ancora di più nel caso di HTML5 Mobile App sviluppate in CSS3 e Javascript.

Grazie ai numerosi framework MVC (e tutte le varianti dell’MVC, solitamente indicate con MV*) è possibile organizzare i dati di un progetto secondo una struttura logica che consenta di modificarli facilmente, oltre che separare totalmente la loro gestione da quella dell’interfaccia e della user-experience, di cui solitamente si occupano altri componenti come view e controllers.

E tu? Cosa pensi dei javascript framework MVC? Fammelo Sapere nei commenti!

Tutti gli sviluppatori e web designers hanno a che fare prima o poi con la manipolazione di elementi HTML DOM, momento in cui fanno conoscenza solitamente di jQuery, che con  tutti i plugin disponibili offre una mano non indifferente.

Il problema sorge di solito quando non si tratta più di realizzare siti web, ma iniziamo ad affacciarsi al mondo delle web app, dove è facilissimo perdersi in una pila infinita di elementi DOM e callback javascript intrecciate e nidificate tra di loro.

Visto che il numero di dispositivi mobile sta crescendo a vista d’occhio e sempre più sistemi operativi stanno rivolgendosi verso la direzione delle single page applications, (hai notato che anche le applicazioni di Windows-8 sono single-page-app costruite in HTML5?), ma soprattutto perché esse costituiscono il metodo principale per lo sviluppo di HTML5 Mobile App ibride, è opportuno considerare l’approccio a Frameworks Javascript Moderni. 

Tali frameworks ci possono assistere nel processo di strutturazione ed organizzazione dei nostri progetti, facendo in modo che essi risultino facilmente mantenibili e scalabili anche a lungo-termine.

---

#Javascript #HTML #mobileapp: l’importanza del #framework #MVC
Click To Tweet

---

HTML5 Mobile App: MVC, Di cosa si tratta?

Questi nuovi framework sono nati con il preciso scopo di fornire allo sviluppatore un modo efficace di organizzare il codice usando delle variazioni del design pattern MVC, ovvero quella logica di programmazione che prende in considerazione tre tipi di entità:

• Modelli (models): rappresentano l’astrazione dei dati. Un modello notifica a tutti i componenti che stanno “osservando” il suo comportamento quale sia il suo stato attuale. Per fare un esempio più concreto, un modello definisce il tipo di dato in questione: può rappresentare una persona, una nota, un file, un articolo.
• Viste (views): sono gli elementi che compongono l’interfaccia di un’applicazione. Generalmente (ma non necessariamente) ad ogni vista è associato un model (per esempio, nella parte di interfaccia che mostra un’ipotetica lista di articoli, ogni riga della lista è costituita da una view, quindi ad ogni view è associato il model dell’articolo). Il compito della view è quello di “osservare” il comportamento del model associato ed agire di conseguenza, ma senza interferire con esso.
• Controller: è quella parte dell’ applicazione che gestisce gli input (ovvero le azioni dell’utente) e modifica i model di conseguenza. Quando un model viene modificato o cambia di stato per mezzo del controller, la view associata, che sta “osservando” quel model, opera gli opportuni cambiamenti. Quindi possiamo dire che il controller gestisce le view indirettamente.

Solitamente i models sono raggruppati in collections, ovvero “liste di models” che possono anch’essi essere associati ad una o più views, come succede per i models.

Ecco uno schema di come funziona la maggior parte dei frameworks MVC:

Per sapere di più sui javascript design patterns ti consiglio di leggere questo mio articolo:

• Web Applications: scrivere codice ben strutturato con i Javascript Design Patterns

HTML5 Mobile App: perché usare un framework MVC

Un’applicazione Mobile realizzata in HTML5, CSS3 e Javascript rappresenta a tutti gli effetti una single-page-application.

Anche le app più semplici, che magari sono costituite da 3 o 4 schermate, il più delle volte hanno una user-interface molto complicata, a causa di tutte le richieste HTTP presenti, gli aggiornamenti del markup, le modifiche del DOM ecc. (senza contare che una schermata ne può avere di per sé altre al suo interno, come per esempio in una lista di elementi ).

Gli sviluppatori che scrivono “a naso” il loro codice, quindi senza utilizzare dei framework per la struttura logica dell’applicazione, inconsapevolmente creano delle view, dei model, e dei controller: l’unica differenza è che tutto ciò che fanno non è riusabile, ne tantomeno mantenibile.

In altre parole, finché il progetto rimane di piccole dimensioni riesce a “stare in piedi”, ma appena si complica anche solo di poco e diventa necessario aggiungere o modificare una parte dell’interfaccia, allora molto probabilmente cadrà in mille pezzi.

I Javascripts frameworks MVC, oltre a fornire robusti e stabili controlli come Models, Views e Controllers, forniscono anche una solida struttura, comprensiva di soluzioni testate negli anni da una gigantesca community di sviluppatori, che prima di noi hanno affrontato e risolto tutti gli stessi problemi logici e di programmazione in cui potremmo incappare nei nostri progetti.

Ciò può costituire un incredibile risparmio di tempo (se sei un web designer o sviluppatore sicuramente saprai cosa significa).

Non so se hai mai notato applicazioni come Asana, Trello, Todoist, Wunderlist, ma anche Twitter o gli stessi Gmail e Google Drive (la lista sarebbe infinita): si tratta di single page application che caricano tutte le risorse come script, stili e views all’inizio, per poi modificare l’interfaccia con i dati che hanno già ottenuto, senza mai ricaricare la pagina, ma lasciando tutto il “duro lavoro” della gestione dei dati (creazione, modifica, eliminazione) al server, attraverso opportune richieste HTTP asincrone (le chiamate ajax).

Quindi, ricapitolando, se stai progettando un’applicazione che, come appunto tutte le HTML5 mobile app Ibride (ma anche le web application desktop), si serve di un servizio dati API di back-end, e si deve solo preoccupare di gestire le varie parti dell’interfaccia senza ricaricare mai la pagina (Single Page Application), allora l’impiego di un Javascript Framework MVC è proprio quello che ti serve.

Tuttavia, se stai progettando una semplice app in cui la generazione del markup risiede perlopiù nel server, mentre lato-client sono sufficienti pochi comandi jQuery per modificare il DOM del documento (come generalmente accade in un normale sito web), allora forse non ha senso impostare il tuo prossimo progetto basandolo su di un framework MVC, situazione in cui tutte le sue funzionalità sarebbero superflue.

Ma noi stiamo parlando di HTML5 Mobile App giusto?

Il framework MVC è quello che fa al caso nostro.

---

La scelta giusta per #HTML #mobileapp – i #framework #MVC
Click To Tweet

---

La difficoltà nell’apprendere la programmazione MVC

A causa del vertiginoso progresso dei dispositivi client (in particolare di quelli mobili) che sta avvenendo in questi ultimi anni, il numero di sviluppatori javascript (quindi in particolare quelli che si occupano di interfacce front-end) è cresciuto a dismisura, e questo tipo di programmazione ha subìto come una “rinascita”.

Il tipo di linguaggio non è molto diverso da quello con il quale la maggior parte degli sviluppatori sono stati abituati a programmare in passato, sia per quanto riguarda la realizzazione di desktop software che di web application. Nel corso degli anni, infatti, gli sviluppatori sono stati abituati ad usare diversi tipi di linguaggi, come C++ o Java per i software client, o PHP, ASP, Python, ASP.NET ecc. per quelli web-based.

Linea temporale della nascita e dell’utilizzo nel corso degli anni dei linguaggi di programmazione più usati

Possiamo affermare che la logica dell’ MVC per strutturare un’applicazione deriva effettivamente dalle precedenti generazioni di linguaggi, sin dagli anni 70.

Tuttavia, per tutti coloro che in questi ultimi anni hanno iniziato la propria carriera di web designers con linguaggi come ASP o PHP, è ancora molto difficile iniziare a comprendere il funzionamento di un’applicazione Javascript MVC.

E’ normale.

E’ normale soprattutto per quelli che fanno un utilizzo massiccio di codice lato-server per la generazione dell’interfaccia, i quali si trovano molto confusi, in particolare per quanto riguarda i concetti di view e di generazione di markup lato-client.

Effettivamente quello di comprendere la logica MVC è uno scoglio abbastanza grosso da abbattere, ma una volta superato questo ostacolo il divertimento è assicurato:

• velocità di scrittura
• organizzazione tra le viste
• riusabilità di una stessa vista da tutte le parti dell’applicazione
• scalabilità del codice: l’applicazione è facilmente espandibile e riducibile senza alcun problema
• estrema separazione del codice lato-client e codice lato-server – che costituisce un’altro elevato fattore di scalabilità e mantenibilità

sono solo alcuni dei vantaggi che offre l’MVC.

Sei mai stato a Mirabilandia?

Periodicamente mi piace andare con i miei amici a Mirabilandia, che si trova a Ravenna, a sole due ore di macchina da dove vivo (Città di Castello, Perugia); nonostante i vari impegni, cerco di andarci nel mezzo della settimana, quando c’è meno gente ed è possibile divertirsi con le varie giostre senza fare code troppo elevate.

La giostra che mi piace di più è il Katun (l’hai mai provato?).

Fonte della foto: Flickr

 

Il Katun è progettato in modo tale che appena la giostra parte c’è una salita non indifferente, che viene percorsa molto piano, in modo da alimentare la paura del visitatore, prima di partire a grande velocità.

E ci riesce eccome! Ogni volta che salgo per la prima volta nel Katun dopo molto tempo, l’ansia e la paura durante quella salita sono alle stelle, ma appena la giostra parte il divertimento è assicurato da una grandissima scarica di adrenalina, tanto che appena finito il giro, mi fiondo di nuovo a fare la fila per farne un’altro.

Posso dire che vado a Mirabilandia solo per salire sul Katun.

Imparare il framework MVC è un po come andare sul Katun, superata la salita iniziale, progettare interfacce web javascript e single page application diventa un vero e proprio divertimento, grazie alla semplicità e alla facilità con cui è possibile aggiornare le varie views in modo indipendente dagli altri componenti.

---

Programmare con #frameworks #MVC è come andare a Mirabilandia!
Click To Tweet

---

HTML5 Mobile App ed MVC: Conclusioni

Visto che stiamo parlando di HTML5 Mobile App sviluppate in HTML5, CSS3 e Javascript, e che applicazioni di questo tipo sono a tutti gli effetti single page application, ovvero quei tipi di progetti in cui la pagina non viene mai ricaricata e tutte le operazioni di creazione, modifica e cancellazione dei dati viene delegata al server tramite un servizio di restful API, invito enormemente tutti gli sviluppatori client a cominciare ad interessarsi all’MVC.

Siccome, analogamente a molti altri campi (come quello del  web marketing), ci stiamo affacciando solo ora a questo aspetto della programmazione, mentre molti altri paesi lo stanno già facendo da tempo, e siccome il mondo delle client web application è in costante evoluzione, qualsiasi web designer e sviluppatore front-end dovrebbe secondo me considerare di inserire l’MVC nelle proprie skills, magari dedicando parte del proprio tempo a capirne il funzionamento.

E tu cosa ne pensi? Hai mai provato a sviluppare un tuo progetto Javascript con la logica dell’MVC? Scrivilo nei commenti!