Daniele Campogiani

Card Scanner on Android using CameraX and MLKit

Sat, 15 Aug 2020 08:00:00 +0200

Having to insert card details manually into an app could be a pain for users, but thanks to CameraX and MLKit, we can easily add a scanning feature in our app with minimal effort.

CameraX

CameraX is a Jetpack library to use camera APIs with device compatibility issues already handled for us and with lifecycle support.

The library is based on uses cases and we are going to use two of them: Preview and Image Capture.

Library Setup

For this post, we are going to use the following dependencies:

Preview

This use case will allow us to display on-screen what the camera is capturing in real-time.

To do so, we need to add androidx.camera.view.PreviewView to our layout:

Then in code, we can build the Preview use case as follows:

To run our use cases we need a CameraProvider and a CameraSelector, I’ve created some extension using Kotlin Coroutines to get a CameraProvider:

While for the CameraSelector this is all we need:

We can now bind our use cases in this way:

Image Capture

This is another CameraX use case, and the setup is pretty similar to the previous one.

We can create the use case in this way:

It’s time to update our bindUseCases method and also use this new one, but since CameraX is using a callback, and we would like to use kotlin coroutines let’s add a convenient extension method:

Now we can update bindUseCases function like the following:

MLKit

Now that we have our image is time to extract data from it. For this purpose, we are going to use MLKit Text Recognition.

Library Setup

We need to add this dependency :

and update our Manifest to download the ML model to the device after our app is installed:

Let’s create an ExtractDataUseCase to encapsulate the MLKit integration:

In this use case, we are accepting an instance of TextRecognizer that could be retrieved with TextRecognition.getClient().

To extract data from our image we first need to transform it into something MLKit can understand. Luckily for us, there is the InputImage.fromMediaImage(image, rotationDegrees) fatory method designed just for that.

Now that we have an image MLKit can understand we can pass it to our textRecognizer and await the text result.

Once again, we are using Kotlin coroutines so we can use this extension as a bridge from Task (returned by textRecognizer) and our suspend method.

Data Extraction

Thanks to CameraX we got the image, and then thanks to MLKit we were able to extract the text on it. Now is our turn to do some minimal logic and pass from raw data to some useful information.

As a first step let’s define what we can extract from the image, and create a data class:

All fields are optional because I have several (debit) cards and on each of them I have a different layout, some of them have the owner on the same side of the number, some of them no.

Same for the expiration date, so ¯_(ツ)_/¯.

Now we can encapsulate our data extraction logic inside a Kotlin Object:

Let’s extract some data:

Here the rationale is to try to get the string that:

contains at least a space char (between name and surname)
contains no digits (I think you can’t have them in a name)

If we have more than one match, choose the longest one.

For the number, we are picking the first line that:

has at lease a space (between numbers)
has all the chars as digits

Expiration could be something like 08/20 or, 08/2020 this is why I’m choosing the line with

5 chars (like 08/20) o 7 chars (like 08/2020)
’/’ as third char

Now that we have found the expiration line we need to separate the month from the year

Final touches

We can now update the activity to use our ExtractDataUseCase

Let’s create it

And then use it

We can now finally bind our result to UI:

That’s all folks! You can find the complete source code at https://github.com/dcampogiani/CreditCardScanner

Use GitHub Pages and kscript to host and validate static JSON API

Thu, 12 Mar 2020 07:00:00 +0100

In Bologna, we have a community about Functional Programming, and lately, I was looking for a quick and easy way to host all the data of the talks.

In this post, we will see how we can use GitHub pages to host the JSON files, and kscript to validate the data before “deploy”.

Github Pages

GitHub Pages is a quick way to host data for free so why don’t we use it also to store some static JSON and use it as API in an app?

To use it we just need a Github repo and enable the feature as explained in this guide

Once done we can push the JSON file and it will be hosted for us for free.

Example:

file in a git repo: https://github.com/fp-in-bo/data/blob/master/events/all.json
same file hosted by GitHub Pages: https://fp-in-bo.github.io/data/events/all.json

kscript

Kscript will bring enhanced scripting support for Kotlin on *nix-based systems, so we can use it fo validate our data before deploying it.

After a quick installation we can start to write our validation script.

To write our first kscript here’s what we need to do:

create empty file

touch script.kts
make a script automatically install kscript and its dependencies on the first run if necessary

kscript --add-bootstrap-header script.kts
open the script with some IDE / text editor (I’ll use IntelliJ)

kscript --idea script.kts
write our logic

Kscript allows us to use dependencies, so we’re going to use Jackson in this example. To add the dependency in our script we just need to declare it directly inside the script like following:

//DEPS com.fasterxml.jackson.module:jackson-module-kotlin:2.10.1

In this example we are going to read a file from arguments, then parse it using Jackson, here is the full script:

Another feature of kscript is to create standalone binaries, let’s do it because we’re gonna use it in our continuous integration:

kscript –package script.kts

Continuous Integration

Our desired flow to publish a new talk to the repo is:

open a new branch
add a talk into the JSON
open a PR
waiting for checks in Continuous Integration
merge the PR

This way once the PR will be merged to master, the new talk will be available in our API. In this repository, I’m using Travis for CI, and all we need is to invoke our script passing the right file

scripts/validateJson events/all.json

That’s all. I find this approach and the mix of these two tools pragmatic and I suggest this approach if you need to host some data that will not change very frequently. You can find here the repo.

Thanks @FChiusolo for the fish.

Android Functional Validation 4 - Validated

Sat, 10 Feb 2018 23:16:01 +0100

This is the last post of the Functional Validation serie and we are going to use Validated, our last data type.

Validated is like Either with some additional power, and using it we can finally aggregate all errors and give proper feedback to our users.

Let’s use Validated

Like Either, Validated will contain two possible values, one when the data is invalid, and one when the data is valid. But this time we are going to use different types.

We will use

Validated<Nel<ValidationError>, String> for email
Validated<Nel<ValidationError>, String> for phone numbers
Validated<Nel<ValidationError>, Data> for the whole form

ValidationError is a sealed class used to define all possible errors:

And Nel is a NotEmptyList that will aggregate errors.

Validated has two possible values: Valid and Invalid and we will use the as following:

Mail

Phone Number

Once again we will use kotlin extension methods invoking validMail and validNumber functions we have discussed in the first post to build our instances.

if the validation function returns true we will wrap the value using the .valid() method, otherwise we will create a Nel with the correct error and wrap it using the .invalid() method.

Map them

By now we are experts of map, let’s use it

Using Validated our map finally has the desired behaviour and we get all input errors in the list:

Android UI

In our ViewModel we will use the previously discussed code to update a <Validated<Nel<ValidationError>, Data>>

In the activity we retrieve the viewModel, register click listener and observe the result of the validation. Once we get the result we clear previous errors and then fold it.

Fold

Once again we are using method reference with the following methods:

In the invalid path we using kotlin when to find the correct error message and TextInputLayout to notify the user, while in the valid path we just show data to user.

You can find here the implementation using Either

Android Functional Validation 3 - Either

Fri, 09 Feb 2018 23:16:01 +0100

In the previous post we saw the limitations of using Option and in this post we are going to solve them choosing a different data type.

The issue with option was that when something goes wrong we have no information about the failure. We just know that our expected value is missing.

So we need a data type that holds some representation of the result of a failed execution. This data type is called Either.

Option was like a box that could contain a value, Either instead is a magic box that can contains a value of a type or another value of an other type.

By conventions those two possible values are called Left and Right, and usually we store the error in the left and the correct value in the Right.

Let’s use Either

Like we did for Option, we are going to use one Either to represent the mail, one Either to represent the phone number and then we will merge them to obtain the output of our validation

In our representation we will use Right to wrap valid input and Left to wrap invalid input, so for example:

Once again to obtain such behaviour we can use kotlin extension methods invoking validMail and validNumber functions we have discussed in the first post

Map them

We have already discusse how map works in the previous post, so let’s use it:

The <String> you are reading in the code is needed because we are using Strings to model errors. Using valid mail and phone number the output will be:

But the improvement compared with Option is that now we can also understand what goes wrong, so if we provide and invalid mail:

or an invalid phone number:

We finally have something to show to the user when he’s giving us wrong data!

Cool, but…

Either limits

What happens when all inputs are wrong?

Map implementation of Either will give us just the first error, we don’t have (yet) a way to accumulate errors.

Android UI

Let’s update our android form to use Either.

In our ViewModel we will use the previously discussed code to update a LiveData<Either<String, Data>>

In the activity we retrieve the viewModel, register click listener and observe the result of the validation. Once we get the result we fold it.

Fold

Once again we are using method reference with the following methods:

This time we are getting an input in each method, in the first one we are getting a String that represents the error, while in the second we are getting the value of the Right, a Data instance in our implementation.

But, as previously discussed, if the user will give us multiple invalid inputs we will notify him just the first error, so Either is not a great choice for validation.

In the next post we will use our last data type that will solve all our problems!

You can find here the implementation using Either

Android Functional Validation 2 - Option

Thu, 08 Feb 2018 23:16:01 +0100

In this implementation of Functional Validation we are going to use Option.

Quoting Arrow doc:

Option is a container for an optional value of type A. If the value of type A is present, the Option is an instance of Some , containing the present value of type A. If the value is absent, the Option is the object None.

So basically is a sealed class with two different implementations:

Some
None

The main idea is to wrap a value that can be present or absent. Wrapping this value in a container such as Option allows us to use this data without worrying to check each time if the value is present or not. We can just use some standard functions like map and flatmap to manipulate the content and write less boilerplate code.

Let’s use Option

We are going to use one Option to represent the mail, one Option to represent the phone number and then we will merge them to obtain the output of our validation

In our representation will use Some to wrap valid input and None for invalid input, so for example:

To obtain such behaviour we can use kotlin extension methods invoking validMail and validNumber functions we have discussed in previous post

At this point we have a Option representation for each field, but what we really want is to validate the whole form!

Map to the rescue

Our goal is to obtain an instance of Data when the form is valid:

but what we achieved so far are two Option.

Luckily for us there is a useful method that accept two Option as inputs, and returns whatever we want. This method is called map and we can use to build our Data instance

In this snippet we first wrap mail and phoneNumbers arguments to Option, then use map to merge them.

With map we pass as last parameter a lambda that takes as input a Pair with the values of the two Options. So in our case the lambda receives as input a Pair with two strings, the mail and the phone number, and returns a Data instance. (it.a is the first value of the pair, and it.b is the second value of the pair).

If we take a look at the return type of the validateData we discover that we are returning a Option of Data and not a Data directly, but we are not creating an instance of Option anywhere, so it must be the map method that wraps our result in a Option!

The real power of map method is that it allows us to write just the happy path in the lambda we pass and it will handle all other scenarios for us. If all arguments are Some (and not None) it will execute our lambda and wrap the result in a Option.

Cool, but…

Option limits

What happens when at least one input is None?

In this case our happy path lambda will be ignored and None is returned.

and exact same result for

Since we are getting None in both cases we can’t know which input is wrong!

Android UI

Let’s use this code to build an android form.

I’m using Android Architecture Components, so the glue code will be in a ViewModel, while the activity will do just UI rendering.

In our ViewModel we will use the previously discussed code to update a LiveData<Option<Data>>

In the activity we retrieve the viewModel, register click listener and observe the result of the validation. Once we get the result we fold it.

What is Fold?

Fold is a method defined on Option that takes to functions, the first one will be executed if the Option is empty, while the second one if the Option contains a value.

In our case we are using method reference with the following methods:

As you can see in the second method we receive as input the value of the Option, while in the first method we don’t get any input. So, as previously discussed, using Option we cannot notify our user which field is wrong.

So, Option is not a great choice for validation, but don’t worry we will fix this issue in the next post using a different data type.

You can find here the implementation using Option

Android Functional Validation 1 - Introduction

Wed, 07 Feb 2018 23:16:01 +0100

This year I’ve been at Scala Days 2017 and because I’m a functional programer noob I attended all beginners’s talks.

One talk that really got my attention and gave me the the intuition of the power of functional programming was Easy and Efficient Data Validation with Cats.

In her talk Daniela gave an example of how functional abstractions can help us developer, even if we don’t know (yet) what a Monad is.

Some months laters I’ve discovered Arrow:

Functional datatypes & abstractions for Kotlin

and I started to study it, to grok some functional concepts and play with Android.

Ok cool, but what has to do all of this with Android?

In this serie of posts I’d like to replicate Daniela’s talk using kotlin and Android.

We are going to build a simple form with two inputs: - Mail - Phone Number and validate it.

We are going to achieve this using different data types, improving the current solution in each step choosing a new data type.

Wait, what is a data type?

Quoting the (excelent) arrow documentation, a data type is:

A datatype is a class that encapsulates one reusable coding pattern. These solutions have a canonical implementation that is generalised for all possible uses. Some common patterns expressed as datatypes are absence handling with Option, branching in code with Either, catching exceptions with Try, or interacting with the platform the program runs in using IO.

Don’t worry if you don’t understand the definition right now, we are going to use three of them we will discuss them.

Demo application structure

We are going to use one activity and one viewmodel for each data type, sharing the same xml view with two different TextInputLayout.

The input of our validation will be a data class with two strings.

To validate mail and phone number we are going to use two pure functions in a kotlin file.

Enough for first post, we can start to see some real code in following posts:

The source code for this article is available here.

Applicazioni Ibride e Native #6 – Confronto

Fri, 01 Aug 2014 15:16:38 +0200

Dimensione Apk

Applicazione Ibrida

Per quanto riguarda l'applicazione ibrida il file apk è stato generato due volte, una volta senza minimizzare il codice e una volta minimizzandolo ottenendo dei risultati non aspettati, come mostrato in tabella:

Come si può notare, semplicemente minimizzando il codice otteniamo un file circa cinque volte più piccolo. Una volta installata sul dispositivo l'applicazione occupa 1,2 MB.

Applicazione Nativa

Il file apk generato dal codice dell'applicazione nativa è di 2,1 MB. Nel codice utilizzo una libreria esterna per la gestione delle animazioni, senza usare questa libreria il file apk è di 2 MB.

Una volta installata l'applicazione occupa nel dispositivo 6,4 MB.

Linee di Codice

Trattandosi di applicazioni scritte in linguaggi diversi il confronto è da considerarsi puramente indicativo, inoltre non viene preso in considerazione il codice di librerie utilizzate ma solo il codice effettivamente scritto per l'applicazione.

Applicazione Ibrida

Sono stati scritti 10 file in Javascript per un totale di 649 righe di codice, un file CSS di 5 righe e 6 file HTML per un totale di 164 righe. Sommando tutti i file otteniamo 818 righe di codice.

Applicazione Nativa

Per quanto riguarda l'applicazione nativa sono stati scritti 6 file Java per un totale di 828 righe di codice e 8 file XML per un totale di 180 righe di codice. Nel complesso sono state scritte 1008 righe di codice.

Tempo necessario per scattare e memorizzare un'immagine

I seguenti risultati sono stati ottenuti utilizzando un Nexus 7 2013 con Android in versione 4.4.2 ( custom rom ParanoidAndroid 4.3-Beta7) dotato di CPU quad core a 1.5 GHz e 2GB di RAM.

Le foto in esame sono state scattate con la fotocamera frontale.

Ho calcolato due intervalli di tempo: il primo (chiamato acquisizione nelle successive tabelle) è il lasso di tempo che trascorre tra la pressione del tasto per scattare una fotografia e la restituzione del controllo all'applicazione (sia nativa che ibrida) con la foto appena scattata, e il secondo (chiamato salvataggio nelle tabelle) è il tempo necessario per memorizzare l'immagine nel filesystem e nel database dell'applicazione.

Ho eseguito questo test sia con le due applicazione “pulite” (ossia senza nessuna foto ancora memorizzata) sia con cinque foto memorizzate senza riscontrare però cambiamenti degni di essere considerati.

Inoltre ho eseguito il test considerando il fatto che la foto che stessi scattando fosse la prima (dall'apertura dell'applicazione) oppure se fosse una foto successiva, e anche in questo caso non ci sono stati cambiamenti degni di nota.

Applicazione Ibrida

In tabella sono riportati in millisecondi i due intervalli sopra descritti nel caso di applicazione con zero foto memorizzate e prima foto scattata dall'apertura dell'applicazione

In media sono necessari 3602 millisecondi per acquisire un immagine e 197 secondi per memorizzarla.

Non sono riportati i test con applicazione con cinque foto memorizzate oppure il caso in cui la foto scattata non fosse la prima dall'apertura dell'applicazione perché hanno differenze non significative rispetto al caso riportato.

Applicazione Nativa

Analogamente all'applicazione Ibrida riporto in tabella i valori dei due intervalli ottenuti in cinque test

Anche in questo caso non ho riscontrato cambiamenti degni di nota effettuando test con applicazione con cinque foto memorizzate, o scattando una foto che non fosse la prima dall'apertura dell'applicazione, per cui riporto solo il caso di applicazione “pulita” e prima foto scattata.

In media sono necessari 3254,6 millisecondi per scattare una fotografia e 50,4 millisecondi per memorizzarla nel filesystem e nel database.

Analisi dei risultati

Per quanto riguarda l'acquisizione dell'immagine l'applicazione ibrida è leggermente più lenta, invece per quanto riguarda la memorizzazione impiega circa quattro volte il tempo impiegato dall'applicazione nativa.

Utilizzo di memoria

Ho misurato l'utilizzo di RAM delle due applicazioni, e come si può notare in tabella l'applicazione ibrida richiede una quantità di memoria decisamente maggiore.

Apertura

È qui di seguito riportata la RAM occupata all'apertura, al variare del numero di immagini memorizzare nell'applicazione:

L'applicazione ibrida richiede sempre almeno 106 MB di memoria, mentre l'applicazione nativa ne usa quasi un sesto.

Scorrimento nella timeline

Riporto in tabella l'utilizzo di RAM delle due applicazioni dopo aver visualizzato tutte le foto nella timeline (scorrendo la view fino in fondo e poi tornando in cima), anche in questo caso al variare di foto memorizzate:

L'applicazione nativa utilizza quindi circa un quarto della memoria richiesta dall'applicazione ibrida.

Mappa

Spostandosi nella view che mostra le foto sulla mappa abbiamo questi dati:

Anche in questo caso l'applicazione ibrida risulta molto più “pesante”, richiedendo circa tre volte la memoria necessaria all'applicazione nativa.

Considerazioni finali

Il modello applicativo utilizzato per realizzare l'applicazione ibrida (utilizzando il framework AngularJS) è molto più semplice del modello usato da Android per la realizzazione di applicazioni native. In AngularJS oltre alle view HTML, le directive e i controller esistono i servizi, componenti software singleton che si occupano di tutto il resto. In Android invece esistono molto più componenti.

Risulta quindi più facile all'inizio sviluppare un'applicazione ibrida, ma una volta capiti i diversi componenti che Android fornisce, si riesce ad avere un'applicazione con una miglior struttura, e a scrivere meno codice perché Android realizza già molte funzionalità di base.

Per quanto riguarda i tools forniti agli sviluppatori non c'è paragone, il supporto fornito a sviluppatori Cordova è praticamente inesistente e limitato all'uso del terminale attraverso lo strumento chiamato Cordova Command-line Interface. Per questo motivo mi sono trovato costretto ad utilizzare una serie di tool esterni per migliorare il workflow come Grunt, Bower e Yeoman. Anche il debug è più complicato trattandosi di codice interpretato.

Per lo sviluppo dell'applicazione nativa ho invece utilizzato Android Studio una soluzione completa fornita da google per lo sviluppo, il test e il deploy delle applicazioni.

Confrontando le performances delle due applicazioni risulta nettamente vincitrice l'applicazione nativa, sia per il consumo di memoria che per la fluidità ottenuta. L'applicazione ibrida in particolare ha uno scroll molto più lento nelle liste.

Punto a favore dell'applicazione ibrida invece è la possibilità di riutilizzo del codice scritto, infatti i componenti scritti possono essere utilizzati sia in una applicazione mobile/ibrida che un normale sito web. Ovviamente in un normale sito web non si hanno a disposizione le API fornite da Cordova, ma i componenti che non le usano possono essere “portati” anche su desktop, mi sono infatti spesso trovato a provare l'applicazione su browser desktop prima di effettuare il deploy su dispositivo per controllare velocemente le modifiche apportate. Nello specifico l'unica API che non ho potuto utilizzare da desktop è quella di accesso alla fotocamera, mentre per la persistenza e la geo-localizzazione non ho avuto problemi poiché Chrome fornisce le stesse API che Cordova implementa su dispositivi mobili. Vale la pena ricordare inoltre ricordare che una applicazione scritta utilizzando Cordova può essere utilizzata su più piattaforme mobile, mentre nel caso di applicazione nativa si è limitati ad una sola piattaforma.

Android pur utilizzando codice Java forza lo sviluppatore a realizzare componenti estendendo quelli forniti dalla piattaforma, per cui questi componenti non possono essere “portati” su una normale JVM desktop.

Inoltre per la scrittura di una applicazione nativa, il produttore della piattaforma fornisce uno stack completo di supporto (dall'interfaccia grafica all'accesso all'hardware) mentre Cordova fornisce solo un set di API per l'accesso al dispositivo e nessun supporto per la realizzazione di UI, e ho dovuto quindi utilizzare un framework esterno.

Applicazioni Ibride e Native #5 – Realizzazione di una Applicazione Nativa

Wed, 16 Jul 2014 22:46:39 +0200

Content Provider

In Android i Content Provider sono utilizzati per disaccoppiare il layer di persistenza dal layer applicativo. Ogni applicazione ha accesso ad un database privato, usando i Content Provider è possibile invece condividere i dati con altre applicazioni, ed è inoltre possibile eseguire query asincrone su di essi per ottenere un'applicazione responsive. Android ha diversi Content Provider built-in utilizzabili dagli sviluppatori, ad esempio Media Store, Contacts, Calendar e Call Log. È inoltre possibile definire nuovi content provider.

PicturesProvider

Per l'applicazione ho realizzato un provider per memorizzare e ottenere i dati relativi alle foto scattate dall'utente. Il provider al suo interno utilizza un database SQLite gestito estendendo la classe di SQLiteOpenHelper fornita da Android.

Il database ha una singola tabella che memorizza il path su filesystem dell'immagine, la descrizione inserita dall'utente, le coordinate geografiche ed un id univoco.

È possibile interrogare il provider per ottenere tutte le immagini attualmente memorizzate attraverso l'url content://com.danielecampogiani.picturesprovider/pictures, mentre se si desidera ottenere informazioni su una specifica foto è sufficiente inserire in fondo all'url 'id della foto : content://com.danielecampogiani.picturesprovider/pictures/id.

Dopo aver fatto un match sull'url richiesto al provider (per discriminare se sono richieste tutte le immagini, o una specifica) il content provider delega il reperimento dei dati al database, e nel caso di modifiche notifica i Content Resolver permettendo così di ottenere delle callback lato applicativo senza dover rieseguire query (come spiegato più avanti).

Activity

Una Activity rappresenta una schermata mostrata ad un utente solitamente occupando tutto lo schermo del dispositivo, per creare un'attività è sufficiente estendere la classe Activity e definire i metodi di callback richiamati dal sistema Android per gestire il ciclo di vita dell'attività.

MainActivity

Per l'applicazione ho creato una sola Activity, poiché utilizzo all'intero di essa diversi Fragment che vengono automaticamente mostrati/nascosti utilizzando un' actionBar a tabs.

Per gestire le transazioni di Fragment ho creato la classe TabListener che si occupa di instanziare quando necessario il fragment che gestisce e di aggiungerlo e rimuoverlo dallo schermo utilizzando FragmentTransaction quando l'utente seleziona il tab relativo.

Ho inoltre aggiunto un menu alla actionBar con un pulsante che quando selezionato crea l'intent Mediastore.Action_Image_Capture specificando un uri negli extra dell'intent poi “lancia” questo intent aspettando la restituzione del controllo con il metodo startActivityForResult. Così facendo verrà lanciata l'applicazione scelta dall'utente per scattare fotografie, e una volta che la foto è stata fatta sarà memorizzata nell'uri specificato negli extra dell'intent e il controllo tornerà all'attività MainActivity.

Ogni qual volta possibile ho eseguito le operazioni all'interno di AsyncTask, questo permette di eseguire codice in background, senza quindi utilizzare il thread dedicato alla UI, e sincronizzare l'interfaccia grafica al termine della loro esecuzione.

La classe AsyncTask si occupa della creazione, gestione e sincronizzazione di thread, per cui lo sviluppatore si deve preoccupare solamente di scrivere la logica applicativa.

Nello specifico ho utilizzato SavePictureAsyncTask per leggere le coordinate geografiche dall'immagine restituita dall'applicazione fotocamera e per memorizzare l'immagine nel content provider, e NewPictureAsyncTask per le operazioni di I/O necessarie per creare il nuovo file sul filesystem.

Fragments

I fragment vengono utilizzati per creare UI dinamiche e flessibili che si adattano a diversi schermi. Ogni fragment è un componente a se stante (con un suo ciclo di vita) utilizzabile da diverse activity. Per creare un nuovo fragment è sufficiente estendere la classe Fragment.

TimelineFragment

È il fragment collegato al tab “Timeline” e mostra in una lista (estende la classe ListFragment) le foto scattate in ordine cronologico. Sotto ogni foto è presente la descrizione e due pulsanti, uno per cancellare la foto e uno per condividerla.

Per ottenere le foto da mostrare utilizzo un loader di cursor poiché le operazioni su database possono essere time-consuming.

I loaders sono un meccanismo per caricare dati in maniera asincrona e per monitorare le sorgenti di dati. Possono essere utilizzati per qualunque tipo di dato, nell'applicazione li ho utilizzati per caricare dei cursor ossia il risultato di query su database in Android.

Per ottenere un comportamento asincrono all'interno del fragment ho implementato l'interfaccia LoaderManager.LoaderCallbacks<Cursor> realizzando i metodi:

onCreateLoader: responsabile di creare il loader (usando la classe CursorLoader di Android) specificando i parametri della query desiderata.
onLoadFinished: richiamato quando la query asincrona restituisce dei risultati che vengono passati come parametro in questo metodo. Il metodo è invocato anche ogni qual volta cambiano i dati di interesse per la query specificata nel metodo onCreateLoader.
onLoaderReset: per resettare il loader.

Per lo specifico fragment, il loader creato interroga il PicturesProvider richiedendo l'id, la descrizione e il path su filesystem di ogni foto.

Nel metodo onLoadFinished aggiorno la grafica mostrando i risultati utilizzando come adapter della lista la classe TimelinePicturesAdapter.

PlacesFragment

Il fragment collegato al tab “Places” mostra sullo schermo una google map centrata sulla posizione attuale dell'utente e ogni foto nelle coordinate geografiche nelle quali è stata scattata.

Anche in questo fragment ottengo dati in maniera asincrona implementando l'interfaccia LoaderManager.LoaderCallbacks<Cursor>richiedendo a PicturesProvider la latitudine, la longitudine e il path su filesystem per ogni foto.

Una volta ottenuti i dati provvedo ad aggiornare l'interfaccia grafica utilizzando l'AsyncTaskAddMarkersAsyncTask che elabora le foto restituite dal loader creando dei marker da mostrare sulla mappa.

Per ottenere la posizione attuale dell'utente utilizzo la classe LocationClient e implemento le interfacce di Android GooglePlayServicesClient.OnConnectionFailedListener e GooglePlayServicesClient.ConnectionCallbacks e aggiornando l'interfaccia nella callback che restituisce la posizione dell'utente.

Adapter

Gli adapter sono usati per effettuare il binding tra i dati e le view che estendono AdapterView, come ad esempio ListFragment (che ho esteso per realizzare TimelineFragment). Gli adapter sono responsabili di creare le view figlie per mostrare i dati.

TimelinePicturesAdapter

Classe che estende CursorAdapter e per ogni cursor (una foto) utilizza una ImageView per visualizzare su schermo la foto, una TextView per mostrare la descrizione e due pulsanti, uno per condividere la foto e uno per cancellarla. Il pulsante per la cancellazione mostra inoltre un AlertDialog per chiedere conferma all'utente una volta selezionato. Il pulsante per la condivisione invece lancia l'intent Intent.Action_Send specificando come tipo di dato image/jpeg, così facendo l'utente può scegliere con quale applicazione condividere il file.

Anche in questo caso ho utilizzato un AsyncTask per non svolgere operazioni potenzialmente lunghe nel thread della UI. DeletePicturesAsyncTask rimuove l'immagine dal content provider e dal filesystem.

Layouts

I Layouts permettono di separare il layer di presentazione dalla logica di business, specificando l'interfaccia grafica in file XML invece che crearla via codice.

Una volta definiti i file XML, questi possono essere “inflated” nei rispettivi componenti (Activity e Fragment) usando il metodo setContentView per le Activity e il metodo Inflator.inflate per i Fragment (l'oggetto Inflator è passato al fragment nel metodo onCreateView).

L'utilizzo di layouts è considerato una best practice in Android, perché è un meccanismo che permette di creare interfacce ottimizzate per diversi tipi di hardware, ad esempio diverse dimensioni di schermo, o la presenza o meno di una tastiera o touchscreen.

Per l'applicazione ho realizzato i seguenti layout:

activity_main.xml : contiene un holder in cui collocare i fragment selezionati scegliendo un tab dell'actionBar.
dialog_description_layout.xml : utilizzato per creare un AlertDialog in cui richiedere all'utente una descrizione testuale della foto appena scattata.
fragment_places.xml : usato dal fragment PlacesFragment contiene al suo interno un MapFragment per mostrare la google map sullo schermo.
fragment_timeline.xml : usato dal fragment TimelineFragment contiene al suo interno una ListView per mostrare tutte le fotografie.
timeline_picture_layout : usato da TimelinePicturesAdapter responsabile di mostrare ogni singola fotografia nella lista sopra descritta. Per ogni foto mostra l'immagine vera e propria, la descrizione e due pulsanti, uno per cancellare la foto e uno per condividerla.

Applicazioni Ibride e Native #4 – Realizzazione di una Applicazione Ibrida

Wed, 09 Jul 2014 14:00:39 +0200

Strumenti Utilizzati

Cordova e plugins

Per realizzare l'applicazione è stato utilizzato Cordova 3.4.1 ed i seguenti plugin:

SocialSharing-PhoneGap-Plugin: per permettere all'utente di condividere le foto scattate. Documentazione ed ulteriori informazioni sono presenti presso la repository github: https://github.com/EddyVerbruggen/SocialSharing-PhoneGap-Plugin
Cordova Camera Plugin: per avere accesso alla fotocamera del dispositivo. Documentazione e ulteriori informazioni nella pagina del plugin: http://plugins.cordova.io/#/package/org.apache.cordova.camera
Cordova Device Plugin: fornisce una descrizione dell'hardware e del software del dispositivo. Documentazione e ulteriori informazioni nella pagina del plugin: http://plugins.cordova.io/#/package/org.apache.cordova.device
Cordova File Plugin: per memorizzare nel filesystem locale le foto scattate. Documentazione e ulteriori informazioni nella pagina del plugin: http://plugins.cordova.io/#/package/org.apache.cordova.file
Cordova Geolocation Plugin: utilizzato per determinare la posizione dell'utente. Documentazione e ulteriori informazioni nella pagina del plugin: http://plugins.cordova.io/#/package/org.apache.cordova.geolocation
Cordova StatusBar Plugin: permette di avere un'integrazione con la status bar di iOS 7, in modo tale da avere stesso look and feel di una applicazione nativa. Documentazione e ulteriori informazioni nella pagina del plugin: http://plugins.cordova.io/#/package/org.apache.cordova.statusbar

Ionic

Per realizzare l'interfaccia grafica dell'applicazione è stato utilizzato Ionic un framework open source che utilizza AngularJS e fornisce agli sviluppatori componenti (HTML/CSS/Javascript) ed alcuni plugin per Cordova.

I componenti forniti hanno directive da utilizzare nelle view HTML ed API da utilizzare nei corrispondenti controller.

Ionic è un framework molto giovane e nella fase iniziale di realizzazione e diffusione. All'inizio della scrittura dell'applicazione era stata da poco pubblicata la prima beta pubblica, ad oggi è stata rilasciata l'ottava beta.

Per l'applicazione sono stati utilizzati i seguenti componenti:

ion-nav-view: componente che tiene traccia della storia di navigazione dell'utente all'interno dell'applicazione fornendo animazioni tra una view ed un altra. Utilizza UI-Router per gestire i vari stati dell'applicazione
ion-nav-bar: per gestire l'header di ogni view inserendo titoli e pulsanti personalizzati
ion-tabs: permette di utilizzare il layout a tabs ed associare ad ogni tab una diversa view
i onicModal: per la gestione di view modali
ionicPopup: per notificare l'utente

Estensioni AngularJS

Sono state utilizzate anche le seguenti estensioni per AngularJS:

Angular-google-maps : fornisce directives per utilizzare google maps all'interno di applicazioni AngularJS
Bindonce: utilizzato quando possibile per aumentare le performances

A causa del two-way data binding di AngularJS la directive ng-repeat causa dei deterioramenti di performances poiché AngularJS utilizza un meccanismo di dirty checking per controllare se sono state effettuate modifiche negli elementi. Utilizzando bindonce viene “rotto” questo two-way data binding per gli elementi specificati, e dopo aver fatto il rendering degli elementi nella view AngularJS non controllerà eventuali modifiche. Ho utilizzato bindonce nella lista di fotografie visualizzate nella timeline.

Le future versioni di AngularJS dovrebbero utilizzare il metodo Object.observe() (non ancora supportato da tutti i browser) per velocizzare queste operazioni ed il team di AngularJS ha dichiarato di avere già ottenuto un incremento delle prestazioni del 20-40%.

Struttura dell'Applicazione

Per la scrittura dell'applicazione ho realizzato tre moduli AngularJS, ed ho organizzato i file in modo da avere un componente in ogni file separato, definendo tutti i moduli nel file app.js e utilizzando il metodo getter angular.module per ottenere in ogni file il modulo desiderato per poterci definire e registrare il componente.

Services

Il modulo MyPhotoDiary.services è così definito:

angular.module('MyPhotoDiary.services',[]);

ed è richiamato in ogni file dentro la cartella scripts/services per poter definire un servizio in ogni file separato (ho fatto questa scelta perché preferisco avere più file piccoli ognuno con limitate responsabilità, poi in fase di deploy i fari file .js vengono concatenati e il file risultante viene minimizzato).

Ho realizzato i seguenti services:

CameraService: utilizza le API fornite dal plugin Cordova Camera per scattare fotografie e restituisce una promise.
GeolocationService: utilizza le API fornite dal plugin Cordova Geolocation plugin per ottenere le coordinate gps e restituisce una promise.
PicturesService: gestisce le fotografie dell'applicazione, utilizza il local storage per memorizzare la descrizione, il path su filesystem locale e le coordinate di ogni fotografia. Per l'operazione di rimozione di fotografie dal filesystem utilizza StorageSettings e restituisce una promise (le operazioni su filesystem in Javascript sono asincrone). Emette l'evento NewPicture nel rootScope ogni volta viene realizzata una nuova fotografia, in modo tale che qualunque controller possa gestire questo evento una volta sottoscritto. (AngularJS rilascia un controller se l'utente non è nella view correlata, quindi ho scelto di avere un evento globale in modo tale da poterlo gestire indipendentemente dalla view corrente dell'utente)
SettingsService: memorizza le preferenze dell'utente utilizzando il local storage.
StorageService: utilizza le API fornite dal plugin Cordova File e permette di memorizzare e cancellare le foto dal filesystem. Per le operazioni restituisce una promise.

Controllers

Il modulo MyPhotoDiary.controllers è così definito:

angular.module('MyPhotoDiary.controllers',['MyPhotoDiary.services']);

e come già spiegato per il modulo relativo ai services è richiamato all'interno di ogni file dentro la cartella scripts/controllers.

Sono stati realizzati i seguenti controllers:

MainNavBarController: gestisce la navigation bar presente in ogni view dove è situato un pulsante per scattare una nuova fotografia. Utilizza i services CameraService, GeolocationService, PicturesService e StorageService per catturare e memorizzare la nuova foto. Usa anche ionicModal per mostrare all'utente una view modale per confermare o scartare la nuova fotografia, e ionicPopup per visualizzare eventuali errori.
PlacesController: responsabile della creazione dei marker da visualizzare sulla mappa. Utilizza GeolocationService per centrare la mappa nella posizione corrente dell'utente e PicturesService per recuperare le foto da mostrare. Gestisce l'evento NewPicture reindirizzando l'utente alla view timeline.
SettingsController: permette di scegliere di quante foto effettuare il prefetch per essere visualizzate nella timeline e di eliminare tutte le foto dell'applicazione. Usa PicturesService per calcolare quante fotografie sono attualmente memorizzate e SettingsService per memorizzare le preferenze utente. Anche questo controller gestisce l'evento NewPicture reindirizzando l'utente alla view timeline.
TimelineController: gestisce la condivisione e l'eliminazione della foto selezionata nella corrispettiva view. Inoltre carica ulteriori foto e le aggiunge alla view non appena l'utente raggiunge il limite inferiore dello scroll della view, infatti per motivi di performances non vengono immediatamente caricate tutte le foto nella view. Utilizza PicturesService per richiedere le foto memorizzate mano a mano che l'utente scorre la view e SettingsService per sapere di quante foto effettuare il prefetch. Gestisce l'evento NewPicture aggiungendo la nuova foto in cima alla view e tornando all'inizio della lista di fotografie.

Modulo Principale

Il modulo MyPhotoDiary è così definito:

angular.module('MyPhotoDiary', ['ionic', 'MyPhotoDiary.controllers', 'MyPhotoDiary.services', 'google-maps', 'pasvaz.bindonce'])

Ed è configurato nel file app.js specificando per ogni stato dell'applicazione (usando UI-router) il rispettivo nome, url, template e controller.

Gli stati sono:

tabs: stato astratto con template tabs.html. Uno stato astratto non può mai essere direttamente attivato, sarà attivato uno dei suoi stati figli.
tabs.places: mappato su url /places utilizza il template places.html ed il controller PlacesController.
tabs.timeline: mappato su url /timeline utilizza il template timeline.html ed il controller TimelineController.
tabs.settings: mappato su url /settings utilizza il template settings.html ed il controller SettingsController.

All'avvio dell'applicazione viene impostato lo stato tabs.timeline.

Views

I template di ogni view sono salvati all'interno della cartella templates e sono:

confirmPhoto: una view modale che visualizza la foto appena scattata e permette di confermarne il salvataggio oppure di scartarla. E' gestita da MainNavController.
places: contiene una google map e un marker per ogni foto nella posizione in cui è stata scattata. Utilizza la direttiva <google-map> fornita da Angular-google-maps.
settings: attraverso uno slider permette all'utente di scegliere il numero di fotografie di cui fare il prefetch nella timeline ed ha un pulsante per eliminare tutte le foto memorizzate.
tabs: visualizza tre tab, uno per lo stato tabs.timeline, uno per lo stato tabs.places e uno per lo stato tabs.settings.
timeline: mostra in una lista in ordine cronologico le fotografie memorizzate e sotto ognuna di essa due pulsanti, uno per eliminare ed uno per condividere la foto.

Tools

Per velocizzare il workflow sono stati utilizzati alcuni tool open source, ne riporto in seguito una breve descrizione per ognuno.

Grunt

Grunt è un task runner scritto in Javascript con molti tool e plugin resi disponibili dalla comunità, tra i plugin che ho utilizzato segnalo bower-install che inietta le dipendenze gestite con bower nell'HTML, concat che concatena diversi fine in uno unico, ngmin, cssmin che comprime i file CSS, uglify per minimizzare il codice Javascript e htmlmin che minimizza il codice HTML.

È installabile attraverso npm (package manager di node.js).

Bower

Bower è un package manager per componenti web. Per l'applicazione ho specificato come dipendenze AngularJS, Ionic, angular-google-maps e angular-bindonce. Bower provvede a scaricare in locale l'ultima versione (o la versione specificata) delle dipendenze, in modo tale che facendone il deploy sul dispositivo non sia necessaria alcuna connettività di rete.

Anche bower è reperibile attraverso npm.

Yeoman

Yeoman è un tool che automatizza il setup degli strumenti precedentemente descritti grazie a generator resi disponibili dalla comunità (attualmente ci sono più di 700 generators).

Per lo sviluppo di questa applicazione ho utilizzato il generator chiamato generator-ionic disponibile in maniera open source all'indirizzo https://github.com/diegonetto/generator-ionic.

Anche yeoman è reperibile con npm.

Applicazioni Ibride e Native #3 – AngularJS

Wed, 02 Jul 2014 14:00:58 +0200

I hereby declare AngularJS to be MVW framework – Model-View-Whatever. Where Whatever stands for "whatever works for you

Igor Minar

AngularJS è un framework per applicazioni web “single page” sviluppato da Google.

Si differenzia dai framework precedenti come jQuery nei quali lo sviluppatore doveva avere una conoscenza completa del DOM per poi manipolarlo scrivendo la logica in javascript, ad esempio:

var btn = $("<button>Hi</button>");

btn.on('click', function(evt) { console.log("Clicked button") });

$("#checkoutHolder").append(btn);

AngularJS invece aumenta il potere espressivo dell'HTML fornendo agli sviluppatori nuovi tag built-in e la possibilità di crearne degli altri.

Inoltre la libreria è di dimensioni veramente ridotte, appena 9KB (la versione minimizzata) ed è disponibile open source.

Data Binding

I framework web classici come Rails a partire da dati del modello producono una view per l'utente, generando una view “single-way”che riflette i dati del modello solo al momento al momento dell'istanziazione.

AngularJS invece adotta un approccio unico, creando dei live templates come view che sono sempre aggiornati rispetto ai dati del modello. Questo ci permette di scrivere nell'HTML

<input ng-model="name" type="text" placeholder="Your name">

<h1>Hello </h1>

Le doppie parentesi graffe indicano un'espressione AngularJS, il framework valuterà l'espressione per effettuare il rendering del contenuto.

Senza scrivere nessuna riga di codice in Javascript abbiamo ottenuto un two-way data binding direttamente nella view.

In questo esempio, ogni volta che cambierà il valore del tag <input> verrà aggiornato anche il contenuto del tag <h1> sottostante.

Scopes

Gli scopes sono componenti core di ogni applicazione AngularJS, vengono utilizzati come glue tra i controller e le view. Grazie al live binding di AngularJS unoscope è immediatamente aggiornato se l'utente interagisce con la view, e viceversa la view è immediatamente aggiornata se modifichiamo lo scope eseguendo qualche operazione nel codice Javascript.

AngularJS gestisce i diversi scope di una applicazione attraverso una relazione gerarchica che rispetta la composizione del DOM, all'avvio dell'applicazione viene infatti creato un rootScope e tutti gli altri scope discendono da questo.

L'oggetto scope è un plain old Javascript object, possiamo quindi aggiungere tutte le proprietà di cui necessitiamo. Esso funge da data model e tutte le sue proprietà sono automaticamente accessibili dalla view:

<div ng-app="myApp"> <h1>Hello </h1>

</div>

angular.module('myApp', []) .run(function($rootScope) {

$rootScope.name = "World";

});

Controllers

I controllers in AngularJS sono funzioni definite dallo sviluppatore per aggiungere funzionalità allo scope della view. Attraverso la Dependency Injection AngularJS passa automaticamente lo scope associato ad ogni controller al relativo costruttore. Nel costruttore può essere configurato lo stato iniziale dello scope, lo sviluppatore si deve preoccupare solamente di scrivere la funzione costruttore, poiché l'instanziazione dei controller è a carico del framework.

Ad esempio:

function FirstController($scope) {

$scope.message = "hello";

}

Per creare delle azioni invocabili dalle view basterà creare delle funzioni sullo scope associato e poi effettuare il binding, ad esempio sfruttano la built-in directive ng-click che gestisce l'evento click del browser. Quindi volendo fare un esempio leggermente più complesso avremo nella view:

<div ng-controller="FirstController">

<h4>Il mio contatore</h4>

<button ng-click="add(1)">Add</button>

<a ng-click="subtract(1)">Subtract</a>

<h4>Valore : </h4>

</div>

E nel relativo controller:

app.controller('FirstController', function($scope) {

$scope.counter = 0;

$scope.add = function(amount) { $scope.counter += amount; };

$scope.subtract = function(amount) { $scope.counter -= amount; };

});

Sia il bottone che il link sono collegati ad una azione definita nello scope, per cui quando verranno premuti/selezionati AngularJS chiamerà i rispettivi metodi.

Come si può notare nei controllers scritti dal programmatore non c'è una modifica manuale del DOM, il tutto viene gestito automaticamente da AngularJS.

Tutti gli scope che sono creati con ereditarietà prototipale, hanno cioè accesso agli scope “avi”. Quindi ogni qual volta AngularJS non riesce a trovare una proprietà richiesta nello scope corrente risalirà questa catena di ereditarietà fino al rootScope associato all'applicazione.

È importante sapere che per motivi di gestione ottimale della memoria e di performances i controllers sono instanziati solo quando sono necessari, e deallocati quando non lo sono più. Per cui ogni volta che cambia lo stato di una applicazione o ricarichiamo una view, i controller correnti vengono deallocati e instanziati i nuovi controller.

Directives

AngularJS fornisce molte built-in directives che servono ad aumentare l'espressività dell'HTML.Le directives built-in sono tag che iniziano con il prefisso ng, per un elenco dettagliato si rimanda alla documentazione di AngularJS.

Inoltre AngularJS permette di definire nuove directive agli sviluppatori con le funzionalità desiderate e di unire diverse directive attraverso un processo chiamato composizione.

Per creare una nuova directive bisogna definirla come segue:

angular.module('myApp', []) .directive('myDirective', function() {

return {

restrict: 'E',

template: '<a href="http://google.com"> Click me to go to Google</a>'

} });

Nell'esempio sono state utilizzate solo la proprietà restrict e template per semplicità, per l'elenco esaustivo si rimanda alla documentazione di AngularJS su come creare directives custom.

Avendo definito questa directive, ogni qual volta nell'HTML verrà incontrata la directive AngularJS invocherà la funzione associata. Possiamo quindi scrivere nella nostra view

<my-directive></my-directive>

e AngularJS provvederà a inserire nel DOM un tag <a> con link a google.

Per poter passare dello stato ad una custom directive attraverso gli attributi:

<my-directive my-url="http://google.com" my-link-text="Click me to go to Google">

</my-directive>

definendo opportunamente la directive:

angular.module('myApp', []) .directive('myDirective', function() {

return {

restrict: 'E',

replace: true,

scope: {

myUrl: '@', // binding strategy

myLinkText: '@' // binding strategy

},

template: '<a href="">' + '</a>'

} })

Così facendo la directive avrà uno scope interno contenente l'url e il testo del link. Ci sono diverse strategie di binding tra attributi passati nella view e lo scope interno, nell'esempio è stata utilizzata la strategia @ che copia il valore dell'attributo nella corrispondente proprietà dello scope.

Views

In applicazioni “single page” la navigazione da una view ad un altra è un aspetto critico, vogliamo mostrare del nuovo contenuto all'utente senza forzarlo ad aspettare l'apertura di un altra pagina HTML. AngularJS per ottenere questo risultato permette di scrivere diversi templates, per poi mostrare il contenuto di interesse in base allo “stato” dell'applicazione.

AngularJS fornisce il modulo ngRoute (da scaricare ed includere manualmente) che realizza la direttiva ng-view utilizzata come placeholder per il contenuto della view dinamico, ad esempio:

<header>

<h1>Header</h1>

</header>

<div class="content">

<ng-view></ng-view>

</div>

<footer>

<h5>Footer</h5>

</footer>

Così facendo l'header e il footer della pagina rimarranno sempre gli stessi, mentre il contenuto verrà aggiornato (senza ricaricare l'intera pagina) in base al valore corrente dell'URL.

Per configurare quali template caricare e in che circostanza occorre configurare routeProvider come segue:

angular.module('myApp', []). config(['$routeProvider', function($routeProvider) {

$routeProvider

.when('/', {

templateUrl: 'views/home.html',

controller: 'HomeController'

});

}]);

Si specifica l'url (“/” nell'esempio) e che template e controller verranno utilizzati. Per semplicità sono stati riportati solamente alcune proprietà esprimibili, per un elenco esaustivo si rimanda alla documentazione di ngRoute.

Passando degli argomenti (con “:” ) attraverso l'URL, AngularJS provvederà ad effettuare il parsing e a creare un array chiamato routeParams utilizzabile dal controller che gestisce la view. E poiché l'utente deve solamente scrivere la funzione costruttore del controllore basterà inserirlo tra gli argomenti e AngularJS si preoccuperà di iniettarlo:

$routeProvider

.when('/inbox/:name', {

controller: 'InboxController',

templateUrl: 'views/inbox.html'

})

app.controller('InboxController', function($scope, $routeParams) {

// Qui è abbiamo accesso all'array $routeParams

});

UI-Router

UI-Router è una libreria che ci permette di organizzare l'interfaccia in stati invece che semplici url, questo ci da la possibilità di avere view innestate usando la directive ui-view invece che ng-view.

Infatti come accade usando ngRoute, il template definito per lo stato corrente verrà utilizzato per visualizzare il contenuto all'utente, ma usando ui-route i template possono a loro volta includere altre ui-view.

La configurazione è leggermente diversa, poiché si usa la keyword “state” invece di “when”.

$stateProvider

.state('inbox', {

url: '/inbox/:inboxId',

template: '<div><h1>Welcome to your inbox</h1>\

<a ui-sref="inbox.priority">Show priority</a>\

<div ui-view></div>\

</div>',

controller: function($scope, $stateParams) { $scope.inboxId = $stateParams.inboxId;

} })

.state('inbox.priority', {

url: '/priority',

template: '<h2>Your priority inbox</h2>'

});

Abbiamo uno stato figlio (specificato usando il “.”) chiamato inbox.priority. La ui-view dentro la view padre verrà quindi popolata con il template di inbox.priority.

Quando abbiamo più ui-view innestate possiamo dare un nome ad ognuna e collegare ad ognuna di esse un template diverso. Ad esempio:

<div>

<div ui-view="filters"></div>

<div ui-view="mailbox"></div>

</div>

E ogni sub-view può avere il suo template e controller:

$stateProvider

.state('inbox', {

views: {

'filters': {

template: '<h4>Filter inbox</h4>',

controller: function($scope) {} },

'mailbox': {

templateUrl: 'partials/mailbox.html'

}

});

Dependency Injection

AngularJS permette agli sviluppatori di utilizzare il pattern dependency injection e specificare le dipendenze di ogni componente senza preoccuparsi di come reperire quest'ultime. A runtime l'injector di AngularJS si occuperà di reperire le dipendenze specificate e se necessario instanziare i componenti richiesti. Possiamo ad esempio definire un servizio e poi specificare ad AngularJS che un controller ne avrà bisogno a runtime:

angular.module('myApp', [])

.factory('greeter', function() {

return {

greet: function(msg) { alert(msg); }

} })

.controller('MyController', function($scope, greeter) {

$scope.sayHello = function() { greeter.greet("Hello!");

};

});

Nel costruttore del controller “MyController” è specificata la dipendenza dal servizio “greeter”.

Annotazione Con Inferenza

AngularJS assume che i nomi degli argomenti siano i nomi delle risorse da reperire o instanziare a runtime, e per questo motivo questo approccio può funzionare solo con codice Javascript non minimizzato e non offuscato, poiché AngularJS ha bisogno di effettuare il parsing degli argomenti immutati.

Annotazione Esplicita

Si possono comunque indicare manualmente i nomi delle dipendenze, per poter minimizzare il codice e non avere problemi specificando la proprietà $inject di una funzione (che corrisponde ad un controller o un servizio).

var aControllerFactory =

function aController($scope, greeter) {

console.log("LOADED controller", greeter);

// ... Controller

};

aControllerFactory.$inject = ['$scope', 'greeter'];

In questo approccio diventa però importante l'ordine con il quale vengono specificati i parametri della funzione, che deve coincidere con l'ordine delle dipendenze specificate nell'array $inject.

Annotazione Inline

Questo tipo di annotazione è equivalente alla precedente ma permette di definire l'array di dipendenze inline alla definizione della funzione:

angular.module('myApp')

.controller('MyController',

['$scope', 'greeter', function($scope, greeter) {

}]);

NgMin

NgMin è un tool che sgrava lo sviluppatore dal definire le dipendenze in maniera esplicita e poter comunque minimizzare il codice, trasforma il seguente codice:

angular.module('myApp', [])

.controller('IndexController', function($scope, $q) {

});

automaticamente in questo:

angular.module('myApp', [])

.controller('IndexController', [ $scope', '$q',

function ($scope, $q) {

} ]);

Services

Prima di introdurre i services vale la pena ricordare che i controllers sono volativi (e lo sviluppatore non ne controlla il ciclo di vita), quindi non idonei a contenere lo stato dell'applicazione. Per questo motivo, e per fornire una modalità di scambio di dati in maniera consistente esistono i services.

I services sono oggetti singleton instanziati dall'injector di AngularJS e lazy-loaded. Come per le directives AngularJS fornisce molti services built-in (ad esempio $http) e permette agli sviluppatori di crearne di personalizzati.

Per usare un service è sufficiente elencarlo nelle dipendenze del controller, directive o altro service che vuole invocarlo.

Factory

Il modo più semplice per creare e registrare (per essere trovato dall'injector) un nuovo service è utilizzare l'API .factory di angular.module.

angular.module('myApp', []) .

factory('UserService', function($http) {

var current_user;

return {

getCurrentUser: function() {

return current_user; },

setCurrentUser: function(user) {

current_user = user;

} }

La funzione factory ha due argomenti: il primo specifica il nome del servizio, il secondo è una funzione che verrà eseguita da AngularJS una volta soltanto per instanziare il service

Service

La funzione service di angular.module è simile alla funzione factory, ed ha come quest'ultima due argomenti, dei quali il primo indica il nome mentre il secondo è una funzione costruttore, che verrà invocata da AngularJS usando la keyword new.

Provider

Tecnicamente le funzioni factory e service sono solo delle “scorciatoie” per la funzione provider che è la vera responsabile per la creazione e registrazione dei vari “services”.

Utilizzando però direttamente provider è possibile configurare dall'esterno il servizio che si sta definendo attraverso la funzione config, iniettando alcuni valori.

Eventi

Per ottenere un accoppiamento più debole tra i diversi componenti dell'applicazione AngularJS mette a disposizione un meccanismo di creazione e propagazione di eventi.

Rispecchiando la gerarchia degli scope, le due operazioni basilari di propagazione degli eventi sono $emit per risalire la catena di scope dai figli al rootScope e $broadcast con funzionamento opposto, da uno scope ai suoi scope figli.

Quando si scatena un evento è possibile specificare oltre al nome anche degli argomenti.

Per registrarsi ad un evento si utilizza la funzione $on specificando il nome dell'evento di interesse e una funzione di gestione. Un gestore di un evento può anche decidere di interrompere la propagazione dell'evento.

Anche in questo caso AngularJS ha diversi eventi built-in, degno di nota è l'evento $destroy che viene emesso sullo scope prima che venga distrutto e permette di pulire l'ambiente (ad esempio distruggendo un timeout che si era registrato). Per un elenco dettagliato degli eventi built-in si rimanda alla documentazione.

Attraverso questo meccanismo è inoltre possibile emettere eventi “globali” poiché ogni componente dell'applicazione AngularJS può richiedere di farsi iniettare il rootScope e poi utilizzarlo con la funzione di $broadcast.

Moduli

In Javascript non è mai una buona idea utilizzare l'ambiente globale e per questo motivo AngularJS permette di dividere l'applicazione in moduli, nei quali racchiudere le funzionalità.

Quando vogliamo definire un nuovo modulo dobbiamo usare la funzione angular.module a due argomenti, il primo specifica il nome del modulo, mentre il secondo è una lista di dipendenze da iniettare.

Per ottenere invece il riferimento ad un modulo utilizziamo la funzione angular.module ad un solo parametro, il nome del modulo. Ottenuto il modulo possiamo definire i nostri componenti per quel modulo (controller/service/directive).

Promises

Una promise è un oggetto che rappresenta il valore di ritorno o un eccezione di di una funzione, può essere vista come un proxy per un oggetto.

Storicamente in Javascript sono state utilizzate funzioni di callback per poter lavorare con dati non disponibili in maniera sincrona, come i dati ottenuti da una richiesta XHR, con le promises possiamo invece interagire con i dati, supponendo che siano già stati restituiti.

Le promises permettono di far sembrare funzioni asincrone come se fossero sincrone, permettendoci di catturare sia i valori di ritorno che le eventuali eccezioni, ma sono sempre eseguite in maniera asincrona, per cui possono essere usate senza preoccuparsi del fatto che possano bloccare l'esecuzione.

AngularJS fornisce il service $q per semplificare la gestione delle promises, una volta creata un promise con il metodo $q.defer() possiamo utilizzare il metodo resolve(value) nel caso l'esecuzione sia andata come previsto e il metodo reject(reason) per notificare invece l'errore. Un ulteriore metodo è notify(value) che permette di mandare una notifica (ad esempio se l'esecuzione richiede un tempo lungo potremmo notificare il progresso attraverso questo metodo). Sia nel caso di successo che nel caso di errore la funzione ritornerà la promise creata al chiamante che può interagire con il risultato attraverso la funzione then().

La funzione then() accetta tre parametri, le funzioni che saranno eseguite in caso di successo, errore e ricezione di notifica. È importante notare che le funzioni di successo o fallimento saranno invocate in maniera asincrona appena la promise è risolta, (solamente una delle due) e con un singolo parametro che indica il risultato in un caso o il motivo del fallimento nell'altro. Mentre la funzione di notifica può essere invocata anche più volte.

Le promises sono profondamente integrate in AngularJS, infatti anche i services built-in come $http le utilizzano per restituire i risultati ai chiamanti.