Introduzione a MobX

MobX è una nuova libreria di “State Management” per applicazioni Javascript. Si pone quindi come concorrente di altre librerie come Flux e Redux. Il concetto teorico che c’è alla base di MobX è il “Reactive programming”: paradigma basato sul propagarsi automatico del cambiamento. Prendiamo ad esempio una classica assegnazione di una variabile.

const a = b + c;

In questo caso sappiamo benissimo che al cambiare di b o c il valore di a rimane invariato. Se invece utilizziamo un foglio di calcolo e all’interno di una cella inseriamo la seguente formula:

=B1+C1

il valore della cella viene aggiornato automaticamente al cambiare di B1 o C1. Questo è quello che avviene normalmente quando si utilizzano tecniche di Reactive programming. Se volessimo semplificare al massimo potremmo dire un’applicazione basata su questo paradigma è un’applicazione basata in maniera massiva sul pattern Observer.

meme

Reactive programming in un meme

Scendiamo ora nel dettaglio di questa libreria. Sulla documentazione ufficiale di MobX troviamo i seguenti elementi cardine.

Observable State

Il cuore pulsante di MobX è il concetto di “stato osservabile”, la caratteristica principale di MobX è quella infatti di poter rendere qualsiasi oggetto e/o classe JavaScript un observable. Vedremo più avanti tramite un esempio che questa cosa avviene in maniera davvero semplice.

Computed values

Un computed value è un valore che viene automaticamente ricalcolato al variare dello stato. Ritornando all’esempio dello spreadsheet il valore della cella è un computed value mentre le celle B1 e C1 sono l’observable state. Al variare del secondo, il primo viene ricalcolato.

Reactions

Simili ai computed values ma invece che produrre nuovi valori producono esclusivamente side-effect come logging, o render della view.

Actions

Le actions sono le operazioni che modificano lo stato. Al contrario di altre API come Redux, in MobX le azioni non sono parte integrante del framework. Potete infatti cambiare direttamente le proprietà del modello, oppure utilizzare un sistema ad eventi, aumentando la complessità ma anche la robustezza dell’applicazione.

Possiamo schematizzare quanto detto fino ad ora con il seguente grafico:

schema

Schema di MobX

Let’s Code

Proviamo ora a mettere a fuoco quanto detto finora con un esempio: implementeremo una piccola applicazione React che stampa un elenco di utenti presi dai servizi REST messi a disposizione da randomuser.me. Iniziamo subito dallo stato dell’applicazione, che abbiamo racchiuso in una classe Ecmascript6.

Il decorator @observable trasforma per l’appunto le proprietà loading e users in observables, uno dei quali aggiornerà automaticamente il computed value numberOfUsers, definito tramite il decorator @computed. Vediamo ora come utilizzare lo stato appena analizzato in una chiamata REST.

Notate che utilizziamo gli observable di AppState, ma questi vengono utilizzati in maniera trasparente dall’applicazione, che ne può modificare i valori come per qualsiasi altro oggetto. sotto il cofano MobX modifica i setter delle proprietà marchiate come observable tramite il metodo Object.defineProperty.

Vediamo ora come collegare MobX alla nostra applicazione React. Il primo step è creare un’istanza AppState e passarlo come props al nostro unico componente chiamato App.

Prima di passare al contenuto di App soffermiamoci un attimo sulla funzione autorun. Questa funzione è il nostro primo esempio di reaction, infatti rimane in ascolto del cambiamento di numberOfUsers e lo stampa in console. Notate inoltre che il decorator @computed ha trasformato numberOfUsers da metodo a proprietà. Completiamo il flusso con il codice del componente App:

Abbiamo accennato in precedenza che il render in un’applicazione MobX è considerata una reaction scatenato da un’observable. Questa cosa viene messa in atto dal decorator @observer, importato dal pacchetto mobx-react: binding ufficiale di MobX per il framework di Facebook. In pratica il decorator fa in modo che ogni cambiamento su AppState venga automaticamente renderizzato a schermo, in maniera del tutto analogo al metodo setState di React.

Conclusioni

Quando usare quindi MobX? Per capirlo proviamo a paragonarlo a quello che considero il suo rivale attuale: Redux. Rispetto a Redux ha un grosso vantaggio: l’assenza del boilerplate tipico di Redux e delle altre declinazioni di Flux. Rispetto a Redux però ha due grossi svantaggi, il primo è che vi obbliga a sporcare il modello. In Redux la vostra logica è racchiusa in Actions e Reducers, che sono formati in gran parte da codice JavaScript che non dipende da framework. In questo caso invece siete portati a “sporcare” la vostra logica con i decorator di MobX. L’altro problema che vedo è l’assenza di constraints, qui non avete un unico store e le action che modificano lo stato, ma potete avere moltissimi store modificati da chiunque.

Il mio consiglio è quindi quello di utilizzare MobX in applicazioni di dimensioni medio/piccole dove l’assenza di boilerplate vince sugli altri svantaggi, mentre negli altri casi opterei per un più robusto Redux. Tenete presente però che entrami i framework fanno sì che i componenti React dipendano esclusivamente dalle props. Quindi in ottica sacrificale è possibile iniziare lo sviluppo con MobX e quando (soprattutto se) l’applicazione cresce passare a Redux con relativamente poco sforzo.

Se siete interessati al codice, in questo repository GitHub trovate tutto il codice visto in questo post. È inoltre presente un esempio di utilizzo di MobX in ambiente AngularJS. La gestione degli observable di MobX è un ottimo modo per evitare $watch e $broadcast che rischiano di far diventare il vostro codice “spaghettoso”.

La canzone di questo post è La Bestia Nel Grano tratto dall’ultimo album di Vinicio Capossela intitolato Canzoni Della Cupa. Buon Ascolto.

Flattr this!

Pubblicato in Javascript Taggato con: , ,

Speech Recognition e Speech Synthesis Web API

Obiettivo di questo post è quello di analizzare due API Web sperimentali, la Speech Recognition e la Speech Synthesis. Queste specifiche servono, rispettivamente, per poter trasformare la voce dell’utente in testo (speech-to-text) e per trasformare un testo in “voce” (text-to-speech).

Speech Recognition

Iniziamo con la più complessa delle due, ma probabilmente la più interessante. la Speech Recognition ci permette di stare in ascolto della voce dell’utente, previa autorizzazione ad utilizzare il microfono, e ritornare una stringa con la frase appena pronunciata. Ad oggi questa API è praticamente supportata esclusivamente da Chrome, come potete vedere dalla relativa pagina di Can I Use.

Compatibilità Speech Recognition Api

Compatibilità Speech Recognition Api

L’oggetto alla base di questa Api è webkitSpeechRecognition. Vediamo subito come utilizzarlo con un piccolo esempio:

Come vedete l’oggetto recognition mette a disposizione oltre dei classici metodi start e stop che servono per iniziare e fermare la registrazione del flusso audio dal microfono dell’utente. Inoltre abbiamo a disposizione alcuni hook, tra i quali quelli che vengono scatenati allo start, allo stop e per ogni risultato trovato. Concentriamoci per l’appunto sulla callback onresult. la variabile e.results contiene dei dati che hanno la seguente forma:

Questo oggetto contiene varie registrazioni, una sola delle quali marcata come final. Ogni registrazione contiene poi vari transcript e il valore che vogliamo ottenere è quello con la confidence più alta. Otteniamo questo risultato utilizzando il metodo maxBy di lodash.

Speech Synthesis

Passiamo all’altra faccia della medaglia, la Speech Synthesis. In questo caso partendo da una stringa riusciamo a far “parlare” il nostro browser. Sempre grazie a Can I Use vediamo come questa API sia implementata sia Safari che da Chrome.

Compatibilità Speech Synthesis Api

Compatibilità Speech Synthesis Api

Utilizzare la Speech Synthesis è un’operazione davvero semplice come dimostra il prossimo esempio:

Gli oggetti di tipo SpeechSynthesisUtterance hanno vari parametri tra cui il volume e la voce da utilizzare tra quelle disponibili nel sistema. Per l’elenco completo delle proprietà vi rimando alla documentazione su Mozilla Developer Network.

Conclusioni

Data la scarsissima adesione a queste Api la vostra webapp non può fare fortemente uso di queste tecnologie. Però possono essere un ottimo plus per tutti gli utenti Chrome. Immaginate ad esempio un servizio clienti su un e-commerce o un sistema di web banking che accetta come input la voce stessa dell’utente. Potete vedere un esempio in questa pagina github.io: una piccola chat in cui le risposte sono simulate grazie a Bacon Ipsum, un Lorem Ipsum a base di maiale! 🙂 Potete inoltre leggere il codice dell’applicazione in questo repository Github.

Il mio computer ama il maiale!

Il mio computer ama il maiale!

Come al solito concludo con una canzone, stavolta tocca a Burn The Witch dei Radiohead, tratto dal nuovissimo album A Moon Shaped Hole. Buon Ascolto.

Flattr this!

Pubblicato in Javascript Taggato con: , ,

Test di applicazioni Ionic con Appium

Mike Cohn nel suo libro Succeeding with Agile: Software Development Using Scrum introduce un concetto che è ormai diventato famosissimo nel mondo degli sviluppatori: la piramide del testing.

La piramide del testing

Photo by https://www.scrumalliance.org/

Il concetto è abbastanza semplice: i test delle vostre applicazioni dovrebbero essere formati in gran parte da test unitari, superando di molto il numero di test UI o anche detti end-to-end. Questo principio, anche se corretto, ha secondo me portato il mondo degli sviluppatori a concentrarsi in maniera preponderante sui test unitari. Trascurando o, in alcuni casi tralasciando del tutto, i test end-to-end.

Un esempio lampante di questo fenomeno è la community Ionic. Nella maggior parte dei casi questa tipologia di test sono delegati a Protractor, approccio ereditato dal “fratello maggiore” AngularJS. Ritengo questi test alquanto inutili perché girano all’interno di un browser sui vostri computer o in un server di continuous integration. Ma in realtà quella che voi state sviluppando è un’applicazione mobile che girerà all’interno di una webview. Quello che andrebbe testato sono le due app Android e iOS all’interno dei device reali o dei simulatori. In questo modo replichiamo, quanto più fedelmente possibile, le operazioni dei nostri utenti.

Appium

In nostro soccorso arriva Appium tool di testing end-to-end per Android e iOS sviluppato da Sauce Labs: la famosa piattaforma cloud di testing. Appium ci permette di testare le nostri applicazioni mobile, siano esse native che ibride. Tramite un apposito web driver è perfettamente compatibile con Protractor, quando la nostra app utilizza una webview. Possiamo quindi utilizzare lo strumento principe del testing end-to-end delle applicazioni AngularJS, ma li faremo girare all’interno di un sistema quanto più possibile simile a quello reale. Appium si installa tramite npm digitando il seguente comando:

Vediamo ora come configurare Protractor per farlo funzionare con Appium.

Tramite la proprietà capabilities andiamo a definire sistema operativo e modello del device. Definiamo inoltre il path del file .app da lanciare all’interno del simulatore iOS durante i test. Andiamo poi a collegare Protractor con il web driver di Appium nella funzione onPrepare. Altra grossa differenza rispetto alla configurazione di un Protractor classico è l’assenza del baseUrl. Il motivo è che nei test Appium non abbiamo un concetto di URL in quanto stiamo testando un’app e quindi non possiamo forzare l’url di partenza.

Al momento dell’uscita di questo post, Appium è compatibile anche con Android ma di fatto risulta inutilizzabile per progetti Ionic in quanto non compatibile con Crosswalk ma solo con la webview nativa. Gli interessati possono consultare questa issue su GitHub per seguire gli sviluppi.

Il nostro primo test

Scriviamo ora il nostro primo test, sfruttando come caso d’uso una semplice todo-list fatta in Ionic di cui ho scritto su Coding Jam. L’unica cosa che andremo a testare sarà che all’avvio l’applicazione atterri effettivamente sul controller “list”.

Per aiutarci nel lancio dei test andiamo a creare anche un task di gulp, task runner presente di default nelle applicazioni Ionic.

Notate che prima dei l’avvio dei test viene lanciata una build iOS. In questo modo il nostro codice sarà sempre allineato con l’app che andremo effettivamente a testare.

Per avviare i test quindi aprite due shell e nella prima digitate:

mentre nella seconda invocate il comando gulp scrivendo:

Et voilà! vedrete i vostri test girare all’interno del simulatore iOS che si chiuderà automaticamente una volta conclusi.

Ecco i nostri test che girano sul simulatore iOS

Ecco i nostri test che girano sul simulatore iOS

Conclusioni

Questi test rispetto ai normali test con Protractor sono molto lenti, basti pensare che ad ogni lancio di una suite bisogna tirar su un’istanza del simulatore iOS e installarci sopra la nostra app preventivamente buildata. Ma credo che sia meglio far girare meno test end-to-end a patto che quelli che ci sono siano per quanto possibile vicini alla realtà. La scrittura di questi test è simile a quelli standard di Protractor, ma non esattamente identici. In un prossimo articolo vedremo insieme una suite completa di test per la nostra app todo-list per capire meglio quali sono le caratteristiche dei test Protractor+Appium.

La canzone di questo post è Ghiaccio Bollente del mio caro amico Martello, tratto dal suo primo album omonimo. Buon Ascolto.

Flattr this!

Pubblicato in AngularJS, Ionic Taggato con: , , ,

Automatizzare la pubblicazione di un’app sull’App Store

Nel mio ultimo articolo ho spiegato come automatizzare la pubblicazione di un’app Cordova sul Play Store di Google. In questo nuovo articolo analizzeremo “l’altra metà del cielo” ovvero la pubblicazione sull’App Store di Apple. Come nel precedente post non ci occuperemo semplicemente della pubblicazione, ma di tutto il ciclo di build di un’app ibrida.

Fase 0: CFBundleVersion

Esattamente come per il caso Android anche ogni build iOS da rendere pubblica sugli store deve essere taggata con un differente numero di build. Questo numero nel mondo iOS si chiama CFBundleVersion. Questa informazione va aggiunta all’elemento widget del file config.xml:

Per incrementare questo numero ad ogni build andiamo ad utilizzare lo stesso hook Cordova che abbiamo utilizzato per il version code di Android, cambieremo solo la proprietà che verrà modificata durante la build.

Fase 1: build

Il prossimo passo è quello di generare in maniera rapida il file .ipa senza passare dall’interfaccia grafica di Xcode. Per ottenere questo risultato sfrutteremo prima Cordova per creare un file .app dopodiché utilizzeremo il comando xcodebuild per creare il pacchetto installabile in maniera automatizzabile:

Gli unici parametri di cui avete bisogno sono il nome del progetto (in questo caso Soisy) e il nome con il quale avete registrato il provisioning profile per la pubblicazione sullo store. A questo punto abbiamo un .ipa pronto per lo store, non ci resta che pubblicarlo.

Fase 2: pubblicazione

Dopo che abbiamo registrato la nostra app su Itunes Connect e creato la relativa scheda per lo store, possiamo procedere con il caricamento automatico del file binario. Al contrario di quanto succede per Android la pubblicazione sullo store Apple non è esposto tramite API. L’unico modo quindi che abbiamo per automatizzare questo passaggio è quello di invocare l’Application Loader da shell. Vediamo insieme come:

Le operazioni che questo script effettua sono:

  1. Calcolo della dimensione e dell’hash md5 del file
  2. creazione del file metadata.xml in una cartella temporanea, contenente le informazioni sul file calcolate in precedenza
  3. Lancio dell’Application loader

Unico dato che dovete reperire è l’ID Apple rilasciato da Itunes nel momento in cui create la scheda della vostra app. Questo valore (numerico) non è da confodere con l’ID pacchetto che invece definite voi per il progetto (di solito nella forma com.company.project). A questo punto il binario è pronto per essere pubblicato dal vostro pannello di amministrazione su Itunes Connect.

Ecco dove trovare l'id Apple della vostra applicazione

Ecco dove trovare l’id Apple della vostra applicazione

Conclusioni

Il fatto che l’App Store non sia accessibile tramite API come la suo controparte Google è un grosso limite per due motivi, il primo che è siamo legati alla versione di Xcode che abbiamo installato sulla nostra macchina, quindi dobbiamo controllare che ad ogni aggiornamento di Xcode lo script sia ancora valido. Il secondo problema è che come avete letto poco sopra la pubblicazione di un’applicazione iOS non è mai totalmente automatizzabile, dovete in ogni caso dare una conferma tramite la vostra dashboard su Itunes Connect. In ogni caso consiglio a tutti gli sviluppatori di utilizzare questi script in quanto vi fanno guadagnare preziose ore di lavoro.

La canzone di questo post è I Killed A Day di Seja, tratta dall’album All Our Wires. Buon Ascolto.

Flattr this!

Pubblicato in Ionic, Tools Taggato con: , ,

Automatizzare la pubblicazione di un’app sul Play Store

In questo ultimo periodo lavorando all’app del progetto Soisy, sono riuscito ad automatizzare completamente la pubblicazione dell’app stessa sugli store Google a Apple. In questo post ci soffermeremo sulla pubblicazione sul Play Store di un’applicazione Apache Cordova, analizzando insieme tutti gli script necessari, dalla build fino alla pubblicazione vera e propria.

Fase 0: version code

Un’operazione preliminare per ogni build Android è quella di definire un nuovo version code.  Questo numero deve essere incrementale e sempre differente dalla build precedente. La prima cosa che dobbiamo automatizzare è proprio quindi la creazione di un nuovo numero di versione. In un’applicazione Cordova questo si traduce con il modificare il file config.xml, il quale ha la seguente forma:

Dobbiamo quindi modificare automaticamente l’attributo android-versionCode nel nodo widget. Cordova ci viene in auto con il meccanismo degli hook. Un hook non è nient’altro che uno script Node.js che viene invocato in una fase specifica del ciclo di vita dell’applicazione stessa. Per definire un hook basta aggiungere lo script all’interno della cartella hooks presente di default nella root di tutti i progetti Cordova. La sotto-cartella nella quale inseriremo lo script definirà in quale fase esso verrà invocato. Per un elenco completo di tutte le possibili fasi alle quali è possibile agganciarsi vi riamando alla guida ufficiale.

Struttura degli hook Cordova

Struttura degli hook Cordova

La fase che utile al nostro scopo è “before_prepare”, in questo modo la versione sarà aggiornata prima di ogni build. Lo script che stiamo per vedere setta come version code la data odierna in formato YYYYMMDD.

Notate l’utilizzo della libreria xml2js per passare dall’xml del file config.xml ad un oggetto JavaScript facilmente modificabile all’interno dello script stesso. Potete poi modificare come volete la regola di creazione della versione stessa, passando magari da un timestamp o da un semplice contatore.

Fase 1: build

Ora che abbiamo definito un nuovo version code possiamo effettuare la build e la firma dell’apk risultante. Questo script bash fa entrambe le cose:

Quello che succede è riassunto in questo breve punto elenco:

  1. Creiamo l’apk in modalità release
  2. Firmiamo l’apk tramite con il keystore precedentemente creato
  3. Ottimizziamo il nostro apk tramite il comando zipalign

Fase 2: pubblicazione

Ora che abbiamo il nostro binario firmato possiamo procedere con l’ultima fase: la pubblicazione. Per automatizzare questo processo andremo ad utilizzare un pacchetto npm chiamato playup. Per prima cosa installiamo il pacchetto tramite il comando:

Prima di poter utilizzare questo tool dobbiamo creare un service account Google collegato alla Google Play Developer Console, in questo modo sarà possibile accedere in maniera alle API di pubblicazione sul Play Store. Una volta creato il service account va creata la chiave di accesso di questo nuovo “utente”. Alla fine ci verrà chiesto di scegliere una tipologia di chiave tra JSON e P12.

Google Developer Console

Creazione di un service account

Scegliendo JSON otterremmo una chiave con la seguente forma:

A questo punto siamo pronti a lanciare playup:

I parametri che abbiamo utilizzato sono:

  • auth: path al file JSON contenente la chiave utente precedentemente creata
  • recent-changes: il changelog della release corrente che sarà visibile sulla scheda dello store
  • track: questo parametro indica il tipo di canale di pubblicazione, i valori accettati sono alpha, beta, production e rollout
  • Infine come ultimo parametro c’è il path al file apk da pubblicare.

Conclusioni

Questo è solo il primo di una serie di post che tratteranno l’argomento della build automation. Il prossimo step sarà ottenere lo stesso risultato ma per il mondo Apple: vedremo come creare un file ipa e lo invieremo all’App Store. Dopodiché ci occuperemo di integrare queste soluzioni dapprima con dei task runner come Grunt e/o Gulp e ed infine con Jenkins: il famoso software di continuous integration.

Come al solito chiudiamo con una canzone: If I Get High dei Nothing but Thieves, tratta dal loro primo album omonimo. Buon ascolto!

 

Flattr this!

Pubblicato in Build Automation, Ionic, Javascript Taggato con: , , ,

Test con React

In un mio articolo su cosenonjaviste.it ho fatto una piccola panoramica su React: nuovo tool di Facebook per la creazione di front-end web.

Come ho accennato nell’articolo introduttivo una delle caratteristiche fondanti di React è il virtual DOM. Tutte le operazioni sul DOM vengono fatte su un clone del DOM attuale che gira completamente in memoria, per poi applicare sul DOM reale solo le modifiche effettivamente necessarie. Questo meccanismo oltre ad avere un forte impatto sulle prestazioni ha un side effect interessante: il render dei componenti React viene effettuato da codice e mai tramite semplice markup.

Possiamo sfruttare questa caratteristica a nostro vantaggio per quanto riguarda il testing delle nostre applicazioni, infatti possiamo trasformare la maggior parte dei nostri test E2E in test unitari. Questo approccio ha diversi vantaggi, il primo è la minore complessità architetturale. Non abbiamo infatti bisogno di configurare alcun server Selenium per permettere ai nostri test di girare.

Come esempio analizzeremo questa piccola applicazione React: una todo list che sfrutta l’architettura Flux.

Todo-list

La nostra applicazione

I componenti principali di questa applicazioni sono:

  • Menu: utilizzato per passare dal List a Detail
  • Detail: form per inserire/modificare un todo
  • List: tabella contenente l’elenco dei todo con la possibilità di eliminarne uno cliccando sul pulsante ‘delete’

Durante questi test andremo a utilizzare la classica accoppiata Karma+Jasmine, ma nulla vieta di utilizzare altri framework di test. Iniziamo con una semplice suite di test che riguardano il componente Menu.

Come si può facilmente notare, il “cuore” del testing in React è l’oggetto TestUtils. In questo caso grazie a questo singleton possiamo effettuare il render del componente che vogliamo testare, e ricercare elementi all’interno del componente stesso. In questo caso specifico abbiamo utilizzato il metodo findRenderedDOMComponentWithTag che ritorna l’unico e solo elemento ul all’interno del componente Menu. In questo semplice caso abbiamo solo expectations sulla forma del componente, passiamo ora ad analizzare i test del componente List:

In questa suite di particolare interesse è l’ultimo test: tramite delle Action popoliamo la tabella di due record, simuliamo poi un click su uno dei pulsanti di ‘delete’ tramite il metodo Simulate.click e controlliamo che il numero di righe sia effettivamente diminuito di un’unità.

Nell’ultima suite di test, che riguarda il componente Detail, possiamo vedere come poter modificare il valore di un componente di input.

In questo caso utilizziamo il metodo Simulate.change per settare il valore dell’input che contiene il valore del todo corrente.

Conclusioni

Qui di seguito potete vedere l’output dei test che abbiamo analizzato in questo post:

React Test output

Report dei nostri test

Notate che le prestazioni sono paragonabili a quelli di qualsiasi test unitario, ma stiamo facendo dei test end-to-end a tutti gli effetti. Ovviamente per le parti più delicate dell’applicativo un vero test E2E può in ogni caso essere la soluzione migliore, ed è possibile (con qualche hack) utilizzare Protractor anche per applicazioni React.

Per quanto mi riguarda credo che i test con React siano il vero “WOW Effect!” di questo nuovo framework, potrebbe addirittura aprire la strada la strada al TDD per il markup. Tecnica che finora ho sempre considerato un miraggio data la complessità di scrittura e la scarsa velocità di esecuzione dei classici test E2E.

Per chi è a digiuno su Flux, sempre su cosenonjaviste potete leggere un mio post dove viene introdotto questo nuovo pattern architetturale.

Come al solito vi lascio con una canzone, questa volta tocca a Pyongyang dei Blur. Questa traccia è tratta dal loro ultimo album The Magic Whip. Buon Ascolto.

Vai a Spotify

Flattr this!

Pubblicato in Javascript, React Taggato con: , , ,

ng-screensaver

Voglio presentarvi ng-screensaver. Come il nome può far intuire si tratta di uno screensaver per webapp AngularJS. Probabilmente qualcuno si starà chiedendo a cosa possa servire uno screensaver per un sito web. In realtà il caso d’uso dai cui è nata l’idea per questo progetto è il seguente: creare un’applicazione per un totem multimediale come quello nella foto sottostante. Lo stack scelto è stato NW.js (ex Node-Webkit) e AngularJS. Per chi non lo sapesse NW.js è un tool utile per racchiudere un’applicazione web completa di server Node.JS e browser Chromium in un exe portable. Se questa applicazione non viene utilizzata per un paio di minuti lo schermo dovrà essere invaso da un video fullscreen.

Totem

Il nostro caso d’uso

Il Codice

Ovviamente ng-screensaver si traduce in una direttiva AngularJS, di cui potete leggerne il codice nel prossimo riquadro

La funzione reset() si occupa inizializzare o reimpostare il timer che farà scattare l’evento sleep, cioè lo start dello screensaver. Se specificato dall’utente in questo frangente verrà invocata la callback onSleep. Al click su qualsiasi parte del DOM reimpostiamo il timer e, qualora ci trovassimo nello stato di sleeping, lo annulla invocando contestualmente la callback onWake.

Nei prossimi due esempi vedremo come utilizzare questa direttiva. Iniziamo con la parte HTML:

Vediamo che per attivare la direttiva basta aggiunge ad un qualsiasi elemento HTML l’attributo ng-screensaver. Gli altri attributi definiscono le due callback descritte in precedenza e il timeout dopo il quale sarà attivato il nostro screensaver.

Vediamo ora il codice del controller:

Come vedete le callback non fanno altro che cambiare l’attributo sleeping dello scope. Questo fa sì che i due div all’interno del body della nostra pagina siano visibili alternativamente (simulando di fatto uno screensaver).

 

Esempio

La nostra direttiva all’opera

Conclusioni

Dubito che questa direttiva possa rivelarsi utile a qualcuno che non si sia trovato in una situazione estremamente simile a quella descritta. Ma spero che in ogni caso questo post possa dimostrare come AngularJS (pur con la sua mole di problemi) sia un framework molto potente e versatile. Se volete scaricare questa direttiva, e utilizzate Bower, nella root del progetto digitate questo comando:

Potete consultare/modificare il codice del progetto collegandovi al repository GitHub.

Come al solito vi lascio con una canzone. Questa volta tocca a Anna di Will Butler, meglio noto come cantante degli Arcade Fire, tratto dal suo primo album da solista Policy. Buon Ascolto.

Vai a Spotify

Flattr this!

Pubblicato in AngularJS, Javascript

Ionic Framework

In questo articolo analizzeremo insieme Ionic Framework, un insieme di API e tool pensati per lo sviluppo di app ibride: in altre parole app scritte in HTML+CSS+JavaScript che però hanno accesso a features tipiche dei dispositivi come fotocamera, accesso ai file, etc etc. Questo post non vuole essere un tutorial ma una serie di considerazioni sullo stato di salute di questa tecnologia e su alcuni aspetti poco conosciuti. Queste considerazioni sono il frutto del lavoro dedicato allo sviluppo di un’app per Android e iOS chiamata weQuote.

Cos’è Ionic

Ionic mette semplicemente insieme Apache Cordova e AngularJS. Inoltre come potete notare dalla sua documentazione, le API sono composte anche da una serie di servizi e direttive che ci aiutano ad ottenere in maniera veloce un look and feel da app nativa, tra le quali:

Action Sheet

Esempio di Action Sheet con Ionic

Essendo basato su Cordova, le app svilluppate con Ionic sono compatibili non solo con iOS e Android, ma anche con Windows Phone, Amazon Fire OS, Firefox OS.

Quick Start

Installare Ionic e lanciare la prima app è un gioco da ragazzi, se avete installato Node.JS sulla vostra macchina, vi basterà digitare il seguente comando sulla shell per installare l’ultima versione del framework.

A questo punto possiamo creare una nuova applicazione semplicemente digitando:

dove ‘hello-ionic’ è il nome della nostra applicazione e ‘blank’ è il template che vogliamo utilizzare (in questo caso vuoto), gli altri template disponibili sono ‘tabs’,’maps’,’sidemenu’,’tests’,’complex-list’,’salesforce’. Una volta creato il progetto basta entrare nella cartella appena creata e digitare i seguenti comandi per lanciare l’applicazione.

 

Ionic Blank Template

Blank template di Ionic

ngCordova

ngCordova è indispensabile in qualsiasi progetto Ionic. Si tratta di una serie di servizi AngularJS che wrappano le chiamate al dispositivo fatte da Cordova o dai suoi plugin. Ad esempio il service $cordovaCamera permette di utilizzare la fotocamera del cellulare con una sisntassi alla “Angular Way”, come possiamo vedere nel seguente snippet:

Una cosa interessante da notare è che ngCordova non è in alcun modo legato all’utilizzo di Ionic. Potete infatti utilizzarlo in un’applicazione Cordova+AngularJS la quale però non prevede la presenza di Ionic.

logo ngCordova

logo ngCordova

Ionic Creator

Ionic Creator è un editor WYSIWYG web che vi permette di creare velocemente degli stub per le vostre applicazioni. La cosa interessante è che in pochissimi secondi potete avere l’applicazione funzionante sul vostro device. Il sistema infatti assegna al vostro progetto un id univoco e potete scaricare e lanciare il progetto con il seguente script.

Per quanto personalmente non apprezzi gli editor visuali in generale, devo dire che la possibilità di vedere la vostra applicazione live con il tempo in cui di solito si realizza un mockup fa un certo effetto, e probabilmente farà effetto anche ad un eventuale cliente/fornitore.

Creazione icone e splash screen

Come tutti i programmatori mobile sanno, creare icone e splash screen per ogni risoluzione/form factor può essere un’operazione particolarmente noiosa. Nell’ultima beta di Ionic è presente una comoda utility che fa questo lavoro al posto vostro. Basta creare la directory ‘resources’ all’interno della root del vostro progetto e posizionare all’interno i file icon.png e screen.png, come nel seguente esempio:

Situazione pre ionic resources

Ionic resources: il prima

A questo punto basta lanciare il comando:

Ionic invierà le immagini ad un server che si occuperà della conversione delle immagini. Una volta completata l’operazione, il sistema aggiornerà anche autonomamente il file config.xml in modo che l’applicazione utilizzi le immagini appena generate.

Situazione pre ionic resources

Ionic resources: il dopo

Debug

Come accennato in precedenza Ionic si basa su Cordova, quindi la vostra applicazione gira all’interno di una WebView. Questo fa sì che il debug di queste applicazioni sia estremamente semplice. Basta infatti collegare il vostro dispositivo, lanciare l’applicazione e aprire il browser (Chrome per Android e Safari per iOS) attivando la modalità inspect. Su Chrome ad esempio basta visitare l’URL chrome://inspect/#devices, dopo aver abilitato il debug USB, sul vostro dispositivo e vi troverete davanti ad una schermata come la seguente

Chrome Inspect

Chrome Inspect

Cliccando appunto su inspect apriremo il Developer Tools di Chrome, il quale però punterà alla WebView della nostra app. Procedura del tutto analoga è attiva su Safari per i dispositivi iOS.

Mobile Chrome Dev Tools

Mobile Chrome Dev Tools

Crosswalk

Quando si sviluppano applicazione ibride per Android bisogna tenere in considerazione che la WebView cambia in base alla versione di Android del dispositivo. Questo porta ad una grossa mole di problemi, banalmente perché difficilmente abbiamo a disposizione tutti i dispositivi di cui avremo bisogno. Inoltre per dispositivi con una versione di Android precedente alla 4.4 non è possibile attivare il debug nelle modalità che abbiamo visto precedentemente. Per fortuna con Ionic è semplicissimo installare Crosswalk, in sostanza una WebView basata su Chromium che ci portiamo dietro insieme all’app stessa. In questo modo la versione di Chrome è sempre la stessa al cambiare del sistema operativo. Per utilizzare Crosswalk al posto della WebView canonica ci basta digitare

Unico lato negativo di questa tecnologia è che la vostra applicazione peserà almeno 25Mb in più quando genererete l’apk.

Conclusioni

Quello che il team di Ionic sta cercando di fare non è semplicemente un framework per costruire UI, ma un vero e proprio ecosistema che aiuterà gli sviluppatori dalla creazione dell’app fino alla sua pubblicazione sugli store. Ovviamente il tutto è ancora work in progress e spesso tra un beta e l’altra le cose smettono di funzionare. Per fortuna la beta corrente (la 14) sarà l’ultima prima prima della 1.0 prevista per l’autunno 2015. Unico vero punto dolente di Ionic è la documentazione: probabilmente a causa del suo stato di beta. Ma se non avete paura di dover leggere il codice per capire quali sono gli attributi di una direttiva o i parametri di un metodo fatevi pure sotto!

La canzone di questo post è Rattlesnake di St.Vincent tratto dall’album omonimo, vincitore del Grammy 2015 come “Best Alternative Music Album”. Buon Ascolto.

Vai a Spotify

Flattr this!

Pubblicato in Ionic, Javascript Taggato con: , ,

Estendere PrimeFaces: AJAX

Questo è l’ultimo di una serie di post (qui il primo ed il secondo) dove cerco di spiegare come utilizzare PrimeFaces come API per creare nuovi componenti JSF. In questo articolo ci occuperemo di come aggiungere ai nostri componenti dei listener AJAX. Il componente che analizzeremo insieme è lo Switch di StrazzFaces: un semplice wrapper di uno dei widget di Drinks Toolkit che viene utilizzato per gestire un valore boolean.

Componente

Come sempre iniziamo con il codice del componente:

La caratteristica principale di questo componente è quella di implmentare l’interfaccia ClientBehaviorHolder: stiamo cioè dichiarando che la nostra classe è in grado di gestire i ClientBehavior. Un ClientBehavior è un oggetto che rappresenta un comportamento client definito tramite uno script, in poche parole rappresenta un tag <p:ajax/>. I metodi che abbiamo implementato nel codice precedente sono getEventsName e getDefaultEventName: il primo ci indica quali sono gli eventi AJAX validi (definito tramite l’attributo ‘event’ del tag <p:ajax/>) il secondo invece definisce l’evento di default (qualora non specificato sul tag).  Nel nostro caso l’unico evento lecito è “change”.

Gli altri metodi da implementare permettono di aggiungere/leggere instanze di ClientBehavior, ma sono definiti all’interno della classe UIComponentBase: la base di quasi tutti i componenti JSF.

Renderer

Passiamo ora ad analizzare il Renderer:

Come si nota dal codice precedente tutta la gestione dei ClientBehavior è demandata a due metodi: encodeClientBehaviors e decodeClientBehaviors. Questi metodi ereditati dal CoreRenderer di PrimeFaces si occupano di agganciare alla widget JavaScript delle funzioni AJAX (encode) e di trasformare poi le chiamate AJAX in metodi sul server (decode). È interessante notare come di nostro pugno non abbiamo scritto niente, PrimeFaces ci prensenta una soluzione “out the box” perfettamente funzionante.

Widget

L’ultimo elemento che andiamo ad analizzare è il widget Javascript:

Come vediamo per far scattare un ClientBehavior, basta invocare la funzione Javascript corrispettiva dell’oggetto behaviors della nostra widget. Il compito del metodo encodeClientBehaviors è proprio quello di popolare questo oggetto.

Esempio

Una volta creato il componente, il suo utilizzo è del tutto simile a quello di qualsiasi altro componente PrimeFaces come possiamo vedere in questo esempio:

Il risultato, visibile qui, è il seguente:

Esempio Ajax  (1)

Esempio Ajax (1)

Esempio Ajax (2)

Esempio Ajax (2)

Conclusioni

Ricapitoliamo il flusso logico delle operazioni che ci permettono di aggiungere un listener AJAX in un componente:

  1. Ognuno dei tag <p:ajax/> che inseriamo all’interno del nostro componente viene trasformato in un ClientBehavior.
  2. Il renderer crea la widget e aggancia ad esso una funzione JavaScript per ogni ClientBehavior (encode).
  3. Il widget attende l’interazione dell’utente ed, eventualmente, invoca la funzione relativa all’evento.
  4. Il renderer si occupa di trasformare l’evento client in un metodo server (decode).

Tutte queste operazioni in realtà richiedono pochissimo codice per essere attuate, infatti ereditiamo quasi tutto il codice dalle classi di PrimeFaces.

Con questo post si conclude la mia piccola guida per creare dei nuovi componenti custom con PrimeFaces. Potete analizzare il codice di questo e di altri componenti nel repository di StrazzFaces.

La canzone di questo post è “Everyday Robots” title-track dell’ultimo album di Damon Albarn, storico leader dei Blur. Buon Ascolto.

Vai a Spotify

Flattr this!

Pubblicato in Java, JSF, StrazzFaces Taggato con: , ,

Chromecast Custom Receiver Applications

In un precedente post su questo blog ho cercato di spiegare come creare una Sender Application per Chromecast tramite le API fornite da Google. In questo nuovo articolo ci occuperemo dell’altra faccia della medaglia: le Receiver Applications.  Queste applicazioni girano all’interno del Chromecast stesso, e sono suddivise in:

  • Styled Media Receiver: Un’app per lo streaming di base in hosting sui server Google, della quale è possibile modificare leggermente l’interfaccia tramite un file CSS.
  • Custom Receiver:  completamente custom, permettono di creare dei software che non si occupano di streaming.

In questo articolo ci occuperemo delle applicazioni custom. Prima di addentrarci nella struttura di questo tipo di software, vediamo insieme quali sono i passi “burocratici” che sono necessari per iniziare a sviluppare per Chromecast.

Google Cast SDK Developer Console

Per creare delle applicazioni receiver dobbiamo creare un account Google Cast SDK Developer. Per fare ciò basta collegarsi all’URL  https://cast.google.com/publish e iscriversi pagando “l’obolo” di 5$. Una volta effettuata la registrazione ci ritroveremo davanti alla Google Cast SDK Developer Console.

Google Cast SDK Developer Console

Google Cast SDK Developer Console

Creare la prima applicazione

Per creare la nostra prima applicazione basta cliccare sul pulsante “Add new application”. Qui, dopo averne scelto il tipo (Custom Receiver), dobbiamo dargli un nome e definire l’URL di ingresso. Una volta data conferma, la nostra applicazione è pronta. Come potete notare dalla foto precedente le applicazioni appena create sono nello stato “Unpublished”,il che significa che possono essere utilizzate solo dai dispositivi che registreremo nella console. Per poterle renderle disponibili al pubblico dobbiamo fornire a Google alcune informazioni tra le quali i dettagli di almeno un’applicazione Sender (tra Chrome,iOS e Android).

Creazione di una nuova Custom Receiver App

Creazione di una nuova Custom Receiver App

Registrazione del nostro dispositivo

Per poter utilizzare le nostre applicazioni anche quando sono “Unpublished” dobbiamo registrare il nostro dispositivo tramite la nostra console.  Per registrare il nostro Chromecast basta cliccare su “Add new device” e inserire il numero di serie stampato sul retro del vostro dongle. Siamo ora pronti a creare la nostra prima Custom Receiver application.

Il Numero di serie del Chromecast

Il Numero di serie del Chromecast

Struttura di una Custom Receiver App

Come avrete notato, quando abbiamo registrato la nostra applicazione è stato necessario fornire l’URL della nostra applicazione. Questo perché ogni applicazione Receiver è semplicemente un applicazione web che viene fatta girare all’interno di un’instanza di Chrome all’interno del Chromecast.

Struttura Chromecast Custom Receiver Applications

Struttura di una Receiver Application (fonte: https://developers.google.com/cast/docs/custom_receiver)

La nostra prima applicazione sarà abbastanza banale: un orologio. Il sorgente della nostra app sarà il seguente:

Il cuore della nostra applicazione sono le Receiver API scaricate dai server di Google. Analizziamo insieme le operazioni che ci permettono di lanciare la nostra applicazione:

  1. Registrarsi all’evento che viene lanciato alla disconnessione dei Sender, quando non ci sono più Sender collegati chiudo la finestra (e quindi l’applicazione).
  2. Invocare il metodo start() del CastReceiverManager.

Utilizziamo poi la libreria CoolClock per creare il nostro orologio. Una volta creato un semplice Sender possiamo far partire l’applicazione. Il risultato sarà il seguente:

La nostra prima Chromecast Custom Receiver Application

La nostra prima Receiver App

Scambio di messaggi

L’SDK del Chromecast ci permette anche di scambiare messaggi tra il Sender e il Receiver, nel prossimo esempio creeremo un piccolo videogame: Il Sender lancerà un comando (“roll”) e il Receiver estrarrà un numero da 1 a 6 stampandolo a schermo e inviandolo indietro al Sender. Vediamo prima il codice del Sender:

Questo invece è il codice del Receiver:

Come potete vedere per creare un collegamento tra Sender e Receiver va definito un namespace, nel nostro caso ‘urn:x-cast:it.strazz.cast.dice’ per rendere univoca la comunicazione. Vediamo nel dettaglio come si inviano/ricevono messaggi sia nel Sender che nel Receiver:

 SenderReceiver
InvioUtilizzare il metodo sendMessage dell'oggetto session.Una volta ricevuto un messageBus da castReceiverManager, basta invocarne il metodo send.
RicezioneAggiungere una callback tramite il metodo addMessageListener dell'oggetto sessionAl messageBus collegare una callback sovrascrivendo il metodo onMessage

Il risultato di questa coppia di applicazioni è il seguente:

Dice Application Sender

Dice Application Sender

 

Dice Receiver Application

Dice Receiver Application

Come vedete grazie ai messaggi scambiati tra Sender e Receiver, i valori sono sincronizzati.

Conclusioni

Le applicazioni Custom Receiver sprigionano il vero potere del Chromecast. Ci permettono infatti di estendere le (limitate) funzionalità “out of the box”. Purtoppo le app disponibili per Chromecast al momento (qui un elenco completo) non sono molte, se escludiamo le applicazioni di streaming. Quindi largo alle idee e sperimentate! 😉 Come sempre il codice presente in questo articolo lo potete trovare al mio GitHub.

La canzone di questo post è “Born To Die”, title track dell’album d’esordio di Lana Del Rey. Buon Ascolto.

Vai a Spotify

Flattr this!

Pubblicato in Chromecast, Javascript Taggato con: , ,