Framework per il backend di app in ambiente iOS: Cloudkit e Firebase - Felice Francesco Tufano Matr. N46002153 Candidato - Ingegneria Informatica

Elaborato finale in Reti di Calcolatori 1

Framework per il backend di app in ambiente iOS:
Cloudkit e Firebase

Relatore: Stefano Avallone

Anno accademico 2018/2019

Candidato
Felice Francesco Tufano
Matr. N46002153

CLOUDKIT E FIREBASE                                !1

Indice

1 Introduzione………………………………………
1.1 Cos’è il “backend as a Service” (Baas)…………….
1.2 Vantaggi dell’utilizzo di un Baas…………………..
1.3 Svantaggi dell’utilizzo di un Baas………………….

2 CloudKit…………………………………………….
2.1 Cos’è Cloudkit………………………………………
2.2 Organizzazione dei dati…………………………….
2.3 Gestione dei dati…………………………………….

3 Firebase……………………………………………..
3.1 Cos’è Firebase………………………………………
3.2 Gestione degli utenti………………………………..
    3.2.1 Gestione degli utenti in iOS………………….
3.3 Gestione dei dati…………………………………….
    3.3.1 Gestione dei dati in iOS……………………..

4 Conclusioni…………………………………………

CLOUDKIT E FIREBASE                                !2

1. Introduzione
1.1 Cos’è il “backend as a Service” (Baas)
Il back-end come servizio, in inglese “back-end as a Service” (Baas), è un
modello per fornire a sviluppatori di app web o mobile un modo per collegare le
loro applicazioni a un back-end cloud Storage e API esposte da applicazioni
back-end, fornendo allo stesso tempo funzioni quali la gestione degli utenti, le
notifiche push, e l'integrazione con servizi di social networking. Questi servizi
sono forniti attraverso l'uso di kit di sviluppo software personalizzato (SDK) e
interfacce di programmazione delle applicazioni (APIs). Baas è uno sviluppo
relativamente recente nel cloud computing, con la maggior parte delle
startup Baas risalente dal 2011 in poi. Anche se è un settore piuttosto nascente,
le tendenze indicano che questi servizi stanno guadagnando rilevanza e
popolarità con i consumatori aziendali.
Un fornitore di BaaS tende a ricadere in una di queste due categorie: un
consumatore BaaS o un BaaS aziendale. Il primo si concentra principalmente
sulle app di marca "più leggere" (e giochi), mentre il secondo punta a mobilitare
sensibilizzare dati aziendali critici sistemi aziendali. Anche se questo settore è
ancora nelle sue fasi iniziali, la tendenza mostra che questo servizio sta iniziando
a guadagnare trazione generale e continuerà ad aumentare popolarità nei
prossimi anni.

1.2 Vantaggi dell'utilizzo di un Baas
I servizi riutilizzabili forniti da BaaS daranno diversi vantaggi rispetto ai
tradizionali sviluppo front-end, che non fornirà solo un ulteriore livello di
sicurezza durante scambio di informazioni, ma consentono uno sviluppo rapido
delle applicazioni . Alcuni dei vantaggi dell'utilizzo di un Baas includono:

1. Consentire una maggiore accessibilità

CLOUDKIT E FIREBASE                                                                !3

Se ogni applicazione in fase di sviluppo ha la stessa struttura sottostante, allora
un BaaS ha il potenziale per collegare facilmente le app attraverso le
piattaforme. Questo può contribuire a molti vantaggi, dalla più semplice
condivisione dei dati alla migliore accessibilità per lo storage cloud, un tempo di
avviamento più veloce e un'esperienza utente complessivamente migliore.
2. Fornisce risultati diversi da un modello
Pensando a un BaaS come a una "casa di partenza", ogni utente inizia con la
stessa base elementi e continua ad aggiungere a quegli elementi per creare il
proprio prodotto personalizzato.

3. Interrompe lo sviluppo dello stack non necessario
Un servizio BaaS può fornire gran parte dei sottostanti requisiti di elaborazione
per un'applicazione. Il problema principale sarebbe quindi la connessione a
un’API, invece di passare ore a sviluppare stack personalizzati che devono poi
essere ricreati, modificati e riassemblati per adattarsi alle esigenze di ogni diversa
applicazione piattaforma. Lo sviluppatore può concentrarsi sulla costruzione di
ciò di cui ha bisogno in aggiunta all’esistente strutture, invece di ricominciare da
capo ogni volta.

Le possibilità offerte da un BaaS variano a seconda dei diversi fornitori di
piattaforme, ma molti di loro condividono gli stessi blocchi di costruzione
comune che sono emersi dai numerosi fornitori di BaaS nel settore attuale.
Il BaaS è la naturale risposta allo sviluppo del software orientato nel cloud, e il
disaccoppiamento di risorse comuni in API individuali.
Le tendenze di sviluppo attuali richiedono piattaforme di sviluppo e scalabilità
nei cloud, portando le risorse appropriate in insiemi significativi in grado di
creare applicazioni in modo efficiente senza doverle distribuire separatamente
attorno al web e altri repository di informazioni.

1.3 Svantaggi dell'utilizzo di un Baas

Sebbene i vantaggi dell'utilizzo di un servizio BaaS possano essere
incredibilmente utili, in particolare verso gli sviluppatori, ci sono alcuni
problemi chiave che devono essere considerati prima implementare o utilizzare
un sistema BaaS.

CLOUDKIT E FIREBASE                                                                  !4

1. API e SDK costruite devono essere uniformi

Per chi sviluppa prodotti BaaS, l'obiettivo principale dovrebbe essere la
continuità nelle API e negli SDK consumabili. Questo significa che ognuno
dovrebbe essere in grado di essere utilizzato ripetutamente nello stesso modo,
attraverso il back-end. Ciò crea meno confusione a consumatori, in quanto
possono apprendere i modelli e il codice una sola volta per il consumo di
qualsiasi API dell’utente fornire, invece di dover imparare regole diverse per
ogni prodotto.

2. Le applicazioni front-end dovrebbero essere "in grado di adattarsi”

A differenza di uno sviluppo mobile-first (Platform-as-a-Service o PaaS), un
BaaS è focalizzato più verso i sistemi sottostanti di un back-end. Richiede che le
applicazioni web siano sviluppato attorno alla funzionalità di quel sistema,
piuttosto che costruire uno stack personalizzato per ogni app. Gli sviluppatori
mobili dovrebbero tenerne conto nella loro progettazione e utilizzo delle API e
degli SDK in una soluzione BaaS.

3. Il dato è la cosa più importante

In un modello BaaS, un backend API è prima i dati, poi il codice. L'API che
fornisce questi dati dovrebbe essere il centro dello sviluppo dell'applicazione.
Molte decisioni dovranno essere prese intorno ai dati, come chi può accedervi e
come l'app gestirà i dati.
Questo può mettere a dura prova la sicurezza di un'app, quindi è necessario
prendere delle precauzioni per essere sicuri che i dati non solo sono accessibili,
ma anche crittografati e protetti correttamente.

4. La logica e la sicurezza sono più focalizzate sul cliente

L'utilizzo di un servizio BaaS in genere comporta la spinta di un più grande
responsabilità verso il cliente. Di solito questo è adattato avendo un server molto
sottile e delegando la maggior parte della logica possibile ai clienti. Più che con

CLOUDKIT E FIREBASE                                                               !5

un normale API, gli utenti devono essere iper-vigili sul fatto che i clienti a volte
operano in un ambiente non affidabile.

Le applicazioni, in particolare le app mobili, sono in genere basate su due livelli
interconnessi, dove ogni strato gioca un ruolo importante. Questi due ruoli
includono un lato client comunemente chiamato front-end, composto da
elementi UI / UX, e dove tutto l’interfaccia utente-macchina è fatto.
Il lato server comunemente chiamato back-end, composto da database display,
gestione utenti, e elaborazione dei dati. Questo livello include l'infrastruttura
cloud come il server bilanciamento del carico, tabella del database, notifica
push, memorizzazione dei dati master e slave, recupero e misure di sicurezza
come OAuth.

Usando un BaaS / MBaaS, gli sviluppatori possono concentrarsi sul livello lato
client, mentre il server side / backend sarà gestito dal provider, rendendolo la
piattaforma ideale per entrambi sviluppatori e utilizzo aziendale.

CLOUDKIT E FIREBASE                                                                !6

2. Cloudkit
2.1 Cos’è Cloudkit
CloudKit è un backend-as-a-service proprietario di Apple. La sua fama è la sua
perfetta integrazione con l'ecosistema di sviluppo Apple. Il modello di prezzo
che offre regola i limiti gratuiti in base al numero di utenti attivi di
un’app. CloudKit è eccellente se la persistenza dei dati è la priorità principale.
Nessuna funzionalità esiste per l'implementazione della logica lato server.
Un inconveniente è che gli utenti devono essere registrati su iCloud quando
salvano i dati.
Esso è un framework disponibile solo per app che sono sull’App store.

2.2 Organizzazione dei dati
Diverse app e sviluppatori hanno accesso ad iCloud, ma i dati in esso contenuti
sono segregati e incapsulati in partizioni chiamate “containers”. I container che
appartengono ad un’app non possono essere accedute da applicazioni di un
altro sviluppatore, però un’app può condividere i suoi container. Diverse app
possono condividere lo stesso container, e un’app può usare diversi container.
C’è un container di default per ogni app , il suo identificatore corrisponde al
boundle ID dell’app stessa. Gli altri ID dei container che si creano devono
essere unici tra tutti gli account degli sviluppatori.
Un’app ha accesso sia a pubblici che privati database in ogni container.

CLOUDKIT E FIREBASE                                                              !7

Il database pubblico serve per memorizzare i dati di utenti e app che sono
condivisi tra tutte le istanze dell'app. Per impostazione predefinita, tutti gli utenti
possono leggere il database pubblico, ma devono inserire le credenziali iCloud
per scrivere nel database pubblico. Esiste un database privato per ogni utente
dell’app, ma l'app ha accesso solo al database privato dell'utente corrente.
L'utente deve inserire le credenziali di iCloud affinché l'app possa leggere e
scrivere nel database privato.
CloudKit offre una dashboard per gestire lo schema e i record contenuti. Lo
schema descrive l'organizzazione di record, campi e relazioni in un database.
Quando si salvano oggetti record in un database, i tipi di record associati e i
relativi campi vengono creati automaticamente. Questa feature è chiamata just-
in-time schema.
Uno schema CloudKit è costituito da uno o più tipi di record con nome, campi
e altri metadati.
Prima di salvare un record occorre selezionare un database, tra quello pubblico,
privato e personalizzato, su cui salvarlo.
Se il tipo di record non esiste, CloudKit lo crea in automatico con i campi
impostati dallo sviluppatore.

CloudKit offre due tipi di ambienti per la gestione del database: il development
environment e il production environment. Il primo viene utilizzato durante la
fase di sviluppo dell’app, e viene usato per creare uno schema e per aggiungere
record per il test. In particolare in questo ambiente CloudKit crea
automaticamente lo schema in base ai record salvati nel database. Questa
funzione consente di ripetere e perfezionare lo schema senza crearlo
esplicitamente.
Il production environment è l’ambiente a cui può accedere un’app una volta che
è stata caricata sullo store. In particolare la prima volta che si distribuisce uno
schema, esso viene copiato nell’ambiente di produzione. Alla successiva
distribuzione dello schema, esso viene unito allo schema di produzione. Per
evitare conflitti, non è possibile eliminare campi o tipi di record in uno schema
di sviluppo precedentemente distribuito nell'ambiente di produzione.
Nell'ambiente di produzione, non è possibile modificare lo schema ma è
possibile aggiungere, modificare ed eliminare record nel database pubblico.

CLOUDKIT E FIREBASE                                                                   !8

2.3 Gestione dei dati

Una volta salvati i record, CloudKit offre vari meccanismi per recuperarli
attraverso le interrogazioni. In particolare è possibile recuperare un singolo
record se si conosce il suo ID, oppure è possibile reperire molti record
utilizzando un predicato, ossia condizioni logiche per la ricerca di quel dato.
Tra i vari campi indicizzabili per la ricerca di un dato, CloudKit offre anche la
possibilità di reperire dati da una certa area geografica attraverso il campo
“Location”.
Le query all’interno del codice Swift sono oggetti della classe “CKQuery”. Un
esempio di query è riportato dal seguente codice:
In questo esempio vengono recuperate tutte le immagini con un titolo
specificato.

Il 14/01/2019 è stata rilasciata “FoundationDB Record Layer” che fornisce la
semantica relazionale su FoundationDB. FoundationDB è un database NoSQL
open-source sviluppato da Apple. Questo nuovo livello include la gestione dello
schema, le funzioni di indicizzazione e un ricco set di funzionalità di
query. Record Layer viene utilizzato in produzione presso Apple per supportare
applicazioni e servizi per centinaia di milioni di utenti. Insieme Record Layer e
FoundationDB formano la spina dorsale di CloudKit .

CLOUDKIT E FIREBASE                                                             !9

I campi “reference” sono utilizzati nello schema per rappresentare le relazioni
tra gli oggetti del modello.
A livello di codice, un campo di riferimento è un oggetto CKReference che
incapsula l'ID del record per un record di destinazione e viene aggiunto al
record di origine. Per rappresentare una relazione uno a uno nello schema,
bisogna aggiungere un campo di riferimento al tipo di record di origine.
Per rappresentare una relazione uno-a-molti tra gli oggetti del modello, è più
efficiente se il riferimento proviene dal record figlio al record padre, ovvero
aggiunge un campo di riferimento al record figlio. Il record figlio è l'origine e il
record padre è il target.
Per rappresentare queste relazioni nello schema, occorre aggiungere un campo
di riferimento ad record corrispondente chiamato. Questo campo di riferimento
conterrà l'ID del record.

Allo stesso modo, per rappresentare le relazione uno-a-molti nel modello a
oggetti, bisogna aggiungere un campo di riferimento per ottenere il record
riferito. Dopo aver recuperato questi record, si creano le relazioni uno-a-uno e
uno-a-molti appropriate tra gli oggetti del modello.

Durante la fase di sviluppo, bisogna salvare i record contenenti i campi di
riferimento per generare lo schema. Per rappresentare una relazione uno-a-uno,
nello schema occorre aggiungere un oggetto CKReference al record sorgente.
CloudKit garantirà che i record di destinazione vengano salvati prima dei
record di origine.
• Per le relazioni uno-a-uno, occorre ottenere il campo di riferimento dal record
  di origine e recuperare il record di destinazione associato.
• Per le relazioni uno-a-molti, occorre recuperare tutti i figli di un record padre
  usando un predicato. È possibile recuperare tutti i record che hanno il padre
  come record di destinazione.

CloudKit offre la possibilità di eliminare automaticamente i record correlati.
È possibile specificare se un record sorgente di un riferimento viene cancellato
quando il suo record di destinazione viene cancellato. Ad esempio, è possibile
che i figli di una relazione uno-a-molti vengano eliminati quando si elimina il
genitore. Il record padre possiede i record figli. Se i figli possiedono altri record,
verranno eliminati, causando una cascata di cancellazioni. Si specifica l'azione
di eliminazione quando si crea l'oggetto di riferimento.

CLOUDKIT E FIREBASE                                                                 !10

CloudKit cancella il record sorgente quando viene eliminato il primo record di
destinazione di un riferimento. Se un record sorgente ha più riferimenti, può
essere eliminato anche se esistono alcuni dei suoi altri record di destinazione, il
che porta a un modello di dati incoerente.

È inefficiente per un’ app ripetere una query quando i risultati sono per lo più
identici all'ultima. È possibile, invece, sottoscrivere le modifiche e lasciare che il
server esegua la query in background. Sarà il server a notificare l’app in
occasione di qualche modifica. In codice, un oggetto sottoscrizione è un’istanza
della classe CKSubcription.
Il salvataggio dei subscribe al database non configura automaticamente l’app
per ricevere notifiche quando viene attivato un oggetto subscribe.
CloudKit utilizza gli APN (Apple Push Notification Service) per inviare notifiche
di subscribe all’app, quindi l’app deve registrarsi per ricevere notifiche push.
Dopo aver finalizzato lo schema e testato l’app nell'ambiente di sviluppo, si è
pronti per distribuire lo schema alla produzione.
La distribuzione promuove lo schema nell'ambiente di produzione, ma non
copia i record dell'ambiente di sviluppo in quello di produzione. Pertanto, dopo
la distribuzione, occorre aggiornare l'ambiente di produzione con i record
necessari.
È possibile continuare ad apportare modifiche allo schema nell'ambiente di
sviluppo, ma dopo aver distribuito lo schema, si è limitati alla creazione di tipi di
record e aggiunta di campi. Gli indici fanno parte dello schema, quindi devono
essere distribuiti in modo simile alle modifiche del tipo di record. Alla successiva
distribuzione dello schema di sviluppo, le modifiche verranno unite allo schema
di produzione. Dopo aver distribuito lo schema nell'ambiente di produzione,
non è possibile eliminare tipi di record e campi distribuiti nell'ambiente di
sviluppo.

Si potrebbe voler aggiungere una cache locale di record CloudKit all’app per
supportarne l’utilizzo offline o per migliorarne le prestazioni. Oppure si
potrebbe già disporre di un archivio dati per l’app e si vorrebbe aggiungere
anche il supporto per la persistenza dei dati in CloudKit.
Dopo aver configurato l’app per mantenere una cache locale, ecco il flusso
generale che la tua app seguirà:

CLOUDKIT E FIREBASE                                                                 !11

1. Quando l’app si avvia per la prima volta su un nuovo dispositivo, si iscriverà
alle modifiche nei database privati e condivisi dell'utente.
2. Quando un utente modifica i propri dati localmente sul Dispositivo A, l'app
invia tali modifiche a CloudKit.
3. L’app riceverà una notifica push sullo stesso dispositivo B dello stesso utente
che notifica che è stata apportata una modifica sul server.
4. L’app sul dispositivo B chiederà al server le modifiche apportate dall'ultima
volta in cui ha parlato con il server e quindi aggiornerà la cache locale con tali
modifiche

La logica di inizializzazione dell'app deve essere eseguita ogni volta che viene
avviata l'app. L’ app dovrebbe eseguire la cache localmente, indipendentemente
dal fatto che si abbia già creato le zone e le iscrizioni, in modo da non inviare
richieste non necessarie ad ogni avvio.
L’app deve essere iscritta alle modifiche apportate da altri dispositivi. Le
iscrizioni comunicano a CloudKit quali dati ti interessano, in modo che possano
inviare notifiche push all'app quando tali dati cambiano.
Un utente può eliminare i dati della tua app sui server CloudKit tramite
l'impostazione di iCloud. L'app deve gestirla con garbo e ricreare nuovamente la
zona e le iscrizioni sul server se non esistono. L'errore specifico restituito in
questo caso è userDeletedZone.

Il sistema di dipendenza delle operazioni descritto nel talk Advanced
NSOperations di WWDC2015 è un ottimo modo per gestire le operazioni di
CloudKit in modo tale che gli stati di account e di rete siano controllati e zone e
abbonamenti vengano creati al momento giusto.

La connessione di rete potrebbe scomparire in qualsiasi momento, quindi
bisogna assicurarsi di gestire correttamente gli errori “networkUnavailable” da
qualsiasi operazione.

CLOUDKIT E FIREBASE                                                              !12

3. Firebase
3.1 Cos’è Firebase
Firebase è una piattaforma di sviluppo di applicazioni mobile e web sviluppata
da Firebase, Inc. nel 2011, poi acquisita da Google nel 2014. A partire da
ottobre 2018.

Firebase si è evoluto da Envolve, una precedente startup fondata da James
Tamplin e Andrew Lee nel 2011. Envolve ha fornito agli sviluppatori un'API
che consente l'integrazione della funzionalità di chat online nei loro siti
web. Successivamente Tamplin e Lee hanno deciso di separare il sistema di chat
e l'architettura in tempo reale che l'ha alimentato. Hanno fondato Firebase
come società a parte nel settembre 2011 e ha lanciato al pubblico nell'aprile
2012.
Il primo prodotto di Firebase era Firebase Realtime Database, un'API che
sincronizza i dati delle applicazioni su dispositivi iOS, Android e Web e li
archivia sul cloud di Firebase. Il prodotto assiste gli sviluppatori di software nella
creazione di applicazioni collaborative in tempo reale. Nel 2014, Firebase ha
lanciato due prodotti. Firebase Hosting e Firebase Authentication. Ciò ha
posizionato la società come back-end mobile come servizio. A maggio 2016,
presso Google I / O , la conferenza annuale degli sviluppatori dell'azienda,
Firebase ha ampliato i propri servizi per diventare una piattaforma unificata per
gli sviluppatori di dispositivi mobili. Firebase ora si integra con vari altri servizi
Google, per offrire prodotti più ampi e scalabili per gli sviluppatori.
Nell'ottobre 2017, Firebase ha lanciato Cloud Firestore, un database di
documenti in tempo reale come prodotto successore del database originale
Firebase Realtime
I servizi offerti da Firebase sono:
• Analytics

Firebase Analytics è una soluzione di misurazione delle app gratuita che fornisce
informazioni sull'utilizzo delle app e sul coinvolgimento degli utenti.

CLOUDKIT E FIREBASE                                                                 !13

• Sviluppo

1. Firebase Cloud Messaging
Precedentemente noto come Google Cloud Messaging (GCM), Firebase Cloud
Messaging (FCM) è una soluzione multipiattaforma per messaggi e notifiche
per applicazioni Android , iOS e Web , che a partire dal 2016 possono essere
utilizzate gratuitamente. [18]

2. Firebase Auth
Firebase Auth è un servizio che può autenticare gli utenti usando solo il codice
lato client. Supporta i provider di accesso social Facebook, GitHub, Twitter e
Google (e Google Play Games ). Inoltre, include un sistema di gestione degli
utenti in base al quale gli sviluppatori possono abilitare l'autenticazione utente
con login e-mail e password archiviati con Firebase.

3. Database in tempo reale
Firebase fornisce un database e un back-end in tempo reale come servizio. Il
servizio fornisce agli sviluppatori di applicazioni un'API che consente di
sincronizzare i dati delle applicazioni tra i client e memorizzati nel cloud di
Firebase. L'azienda fornisce librerie client che consentono l'integrazione
con Android , iOS , JavaScript , Java , Objective-
C , Swift e Node.js applicazioni.
4. Firebase Storage
Firebase Storage fornisce caricamenti e download di file sicuri per le app
Firebase, indipendentemente dalla qualità della rete. Lo sviluppatore può
utilizzarlo per memorizzare immagini, audio, video o altri contenuti generati
dagli utenti. Storage di Firebase è supportato da Google Cloud Storage . [24]

5. Firebase Hosting
Firebase Hosting è un servizio di hosting web statico e dinamico lanciato il 13
maggio 2014. Supporta l'hosting di file statici come CSS , HTML , JavaScript e
altri file, oltre al supporto tramite le funzioni cloud.

CLOUDKIT E FIREBASE                                                             !14

6. Kit ML
ML Kit è un sistema di apprendimento automatico per dispositivi
mobili lanciato l'8 maggio 2018 in versione beta durante l' I / O 2018 di
Google. Le API di ML presentano una varietà di funzioni tra cui
riconoscimento del testo, rilevamento di volti, scansione di codici a barre,
etichettatura di immagini e riconoscimento di punti di riferimento. È
attualmente disponibile per glisviluppatori iOS o Android .

• Stabilità
1. Crashlytics
Crash Reporting crea report dettagliati degli errori nell'app.
2. Performance
Firebase Performance fornisce approfondimenti sulle prestazioni di
un'applicazione e sulle latenze che gli utenti dell'applicazione hanno.

3. Firebase Test Lab per Android e iOS
Firebase Test Lab per Android e iOS fornisce un'infrastruttura basata su cloud
per testare app Android e iOS.

3.2 Gestione degli utenti
Firebase Authentication fornisce servizi di back-end, SDK facili da usare e
librerie UI già pronte per autenticare gli utenti nell’app. Supporta
l'autenticazione utilizzando password, numeri di telefono, provider di identità
federati popolari come Google, Facebook e Twitter e altro ancora.
È possibile accedere agli utenti di un’ app Firebase utilizzando FirebaseUI come
soluzione completa di autenticazione drop-in o utilizzando l'SDK di
autenticazione Firebase per integrare manualmente uno o più metodi di accesso
nell’app (email e identificazione basata su password, identificazione con provider
di identità federati, autenticazione del numero di telefono, Integrazione del
sistema di autenticazione personalizzata, Autenticazione anonima).

CLOUDKIT E FIREBASE                                                             !15

FirebaseUI è un set di librerie open source per Firebase che consente di
collegare rapidamente elementi di interfaccia utente comuni al database
Firebase per l'archiviazione dei dati, consentendo di aggiornare le viste in tempo
reale mentre cambiano e fornendo semplici interfacce per attività comuni come
la visualizzazione di elenchi o collezioni di oggetti. Inoltre, FirebaseUI
semplifica l'autenticazione di Firebase fornendo metodi di autenticazione facili
da utilizzare che si integrano con provider di identità comuni come Facebook,
Twitter e Google, oltre a consentire agli sviluppatori di utilizzare un'interfaccia
utente integrata per semplificare lo sviluppo. Il componente Auth di FirebaseUI
implementa le best practice per l'autenticazione su dispositivi mobili e siti Web,
in grado di massimizzare la conversione di accesso e registrazione per la tua
app. Gestisce anche i casi limite come il recupero dell'account e il collegamento
degli account che possono essere sensibili alla sicurezza e soggetti a errori nella
gestione corretta.

Un oggetto Utente Firebase rappresenta l'account di un utente che si è iscritto a
un'app nel progetto Firebase. Le app di solito hanno molti utenti registrati e
ogni app in un progetto Firebase condivide un database utente. Un’istanza
utente Firebase è indipendente da un'istanza Auth Firebase. Ciò significa che è
possibile avere diversi riferimenti a diversi utenti all'interno dello stesso contesto
e chiamare ancora uno dei loro metodi.

Un utente Firebase ha un set fisso di proprietà di base: un ID univoco, un
indirizzo email primario, un nome e un URL di foto, memorizzati nel database
dell'utente del progetto, che possono essere aggiornati dall'utente. Non è
possibile aggiungere direttamente altre proprietà all'oggetto User di Firebase.
La prima volta che un utente accede all’app, i dati del profilo dell'utente
vengono compilati utilizzando le informazioni disponibili.

Una volta creato un account utente, è possibile ricaricare le informazioni
dell'utente per incorporare eventuali modifiche che l'utente potrebbe aver
apportato su un altro dispositivo.

CLOUDKIT E FIREBASE                                                                 !16

È possibile accedere agli utenti delle app di Firebase utilizzando diversi metodi:
indirizzo email e password, provider di identità federati e sistema di
autenticazione personalizzato. È possibile associare più di un metodo di accesso
a un utente: ad esempio, un utente può accedere allo stesso account utilizzando
un indirizzo email e una password o utilizzando l'accesso a Google.

Un'istanza utente Firebase tiene traccia di ogni fornitore collegato all'utente. Ciò
consente di aggiornare le proprietà del profilo vuoto utilizzando le informazioni
fornite da un provider. Quando un utente si registra o effettua l'accesso,
quell'utente diventa l'utente corrente dell'istanza Auth. L'istanza Auth Firebase
mantiene lo stato dell'utente, in modo che l'aggiornamento della pagina (in un
browser) o il riavvio dell'applicazione non perda le informazioni dell’utente.
Quando l'utente si disconnette, l'istanza Auth smette di mantenere un
riferimento all'oggetto User e non persiste più nel suo stato; non c'è un utente
corrente. Tuttavia, l'istanza utente continua a essere completamente funzionale:
se si mantiene un riferimento ad esso, è ancora possibile accedere e aggiornare i
dati dell’utente. Il metodo consigliato per tenere traccia dello stato corrente
dell'istanza Auth Firebase è utilizzando gli ascoltatori “listner”. Un listener di
Auth viene avvisato ogni volta che succede qualcosa di rilevante all'oggetto
Auth.

3.2.1 Gestione degli utenti in iOS
Per integrare FirebaseUI all’interno dell’app occorre aggiungere Firebase al
progetto iOS, e aggiungere FirebaseUI al podfile, dove un Cocoapod
(abbreviato pod) è un termine generale per una libreria o un framework che
viene aggiunto al progetto usando CocoaPods, ossia il gestore delle dipendenze
per i progetti in Swift.

CLOUDKIT E FIREBASE                                                               !17

3.3 Gestione dei dati
Firebase offre due soluzioni database basate su cloud e accessibili ai client che
supportano la sincronizzazione dei dati in tempo reale:

  •   Realtime Database è il database originale di Firebase. È una soluzione
      efficiente e a bassa latenza per le app mobili che richiedono lo stato
      sincronizzato tra i client in tempo reale.

  •   Cloud Firestore è il nuovo database di punta di Firebase per lo sviluppo di
      app per dispositivi mobili. Migliora i successi del Realtime Database con
      un nuovo modello di dati più intuitivo. Cloud Firestore offre anche query
      e scale più ricche e veloci meglio del Realtime Database.
Firebase Realtime Database è un database ospitato nel cloud. Real-time
database funziona anche quando l’app è offline, quando ad esempio perde la
connessione, il database SDK usa la cache locale sul dispositivo per
memorizzare ed effettuare cambiamenti, quando l’utente torna on-line i
cambiamenti sono automaticamente sincronizzati.

Le funzionalità chiave sono:
.Realtime: Invece delle tipiche richieste HTTP, Firebase Realtime Database
utilizza la sincronizzazione dei dati: ogni volta che i dati cambiano, ogni
dispositivo connesso riceve quell'aggiornamento in pochi millisecondi.

.Offline: Le app Firebase rimangono reattive anche quando sono offline, poiché
l'SDK di Firebase Realtime Database persiste i tuoi dati su disco. Una volta
ristabilita la connettività, il dispositivo client riceve tutte le modifiche perse,
sincronizzandole con lo stato attuale del server.

.Accessibile dai dispositivi client: è possibile accedere al database in tempo reale
di Firebase direttamente da un dispositivo mobile o da un browser web; non c'è
bisogno di un server delle applicazioni. La sicurezza e la convalida dei dati sono
disponibili tramite le regole di sicurezza del database in tempo reale di Firebase,
regole basate sull'espressione che vengono eseguite quando i dati vengono letti o
scritti.

CLOUDKIT E FIREBASE                                                               !18

.Scala su più database: Con Firebase Realtime Database si può supportare le
esigenze dei dati della tua app su larga scala suddividendo i tuoi dati su più
istanze di database nello stesso progetto Firebase. Il database Realtime fornisce
un linguaggio di regole flessibile basato su espressioni, chiamato Firebase
Realtime Database Security Rules, per definire come devono essere strutturati i
dati e quando è possibile leggere o scrivere i dati. Una volta integrato con
l'autenticazione Firebase, gli sviluppatori possono definire chi ha accesso a quali
dati e come possono accedervi.
Il database Realtime è un database NoSQL e in quanto tale ha diverse
ottimizzazioni e funzionalità rispetto a un database relazionale. L'API Realtime
Database è progettata per consentire solo operazioni che possono essere eseguite
rapidamente. Ciò ti consente di creare una grande esperienza in tempo reale
che può servire milioni di utenti senza compromettere la reattività. Per questo
motivo, è importante pensare a come gli utenti devono accedere ai dati e quindi
a strutturarli di conseguenza. In particolare Realtime database è un database
progettato in una struttura JSON. È possibile pensare a questo database come a
un albero ospitato nel cloud. A differenza di un database SQL, non ci sono
tabelle o record. Quando aggiungi dati all'albero JSON, diventa un nodo nella
struttura JSON esistente con una chiave associata. È possibile fornire le proprie
chiavi, come ID utente o nomi semantici.

Un esempio di gestione dei dati mediante la struttura JSON è riportato nella
seguente figura.

CLOUDKIT E FIREBASE                                                              !19

Cloud Firestore è un database NoSQL, orientato ai documenti. I dati si
archiviano nei documenti , che sono org anizzati in raccolte.
Ogni documento contiene un insieme di coppie chiave-valore. Cloud Firestore è
ottimizzato per l'archiviazione di grandi raccolte di piccoli documenti. Tutti i
documenti devono essere archiviati in collezioni. I documenti possono
contenere sottoraccolte e oggetti nidificati, entrambi possono includere campi
primitivi come stringhe o oggetti complessi come gli elenchi. Collezioni e
documenti sono creati implicitamente in Cloud Firestore. Esso assegna
semplicemente i dati a un documento all'interno di una raccolta. Se la raccolta o
il documento non esiste, Cloud Firestore lo crea. Quindi in Cloud Firestore,
l'unità di archiviazione è il documento. Un documento è un record leggero che
contiene campi, che si associano ai valori. Ogni documento è identificato da un
nome.

Un documento che rappresenta un utente potrebbe somigliare a questo:

Gli oggetti complessi e annidati in un documento sono chiamati mappe. Si
potrebbe notare che i documenti assomigliano molto a JSON. In realtà, lo
sono. Esistono alcune differenze (ad esempio, i documenti supportano tipi di dati
aggiuntivi e dimensioni limitate a 1 MB), ma in generale è possibile trattare i
documenti come record JSON leggeri.
Cloud Firestore è senza schemi, quindi si ha completa libertà sui campi che si
inserisce in ogni documento e su quali tipi di dati archiviano in quei campi. I
documenti all'interno della stessa collezione possono contenere diversi campi o
memorizzare tipi diversi di dati in questi campi. Tuttavia, è una buona idea
utilizzare gli stessi campi e tipi di dati su più documenti, in modo da poter
interrogare i documenti più facilmente. Una raccolta contiene documenti e
nient'altro. Non può contenere direttamente campi grezzi con valori e non può
contenere altre raccolte. I nomi dei documenti all'interno di una collezione sono
unici. È possibile fornire le proprie chiavi, come gli ID utente, oppure lasciare

CLOUDKIT E FIREBASE                                                            !20

che Cloud Firestore crei automaticamente ID casuali. Non è necessario "creare"
o "eliminare" raccolte. Dopo aver creato il primo documento in una raccolta, la
collezione esiste. Se si eliminano tutti i documenti in una raccolta, essa non
esiste più. Ogni documento in Cloud Firestore è identificato in modo univoco
dalla sua posizione all'interno del database.

Entrambi i database sono dotati di SDK in tempo reale mobili e supportano
entrambi lo storage di dati locale per le app offline.

• QUERY

Database realtime offre query profonde con funzionalità di ordinamento e
filtraggio limitate. È possibile ordinare o filtrare solo su una proprietà, non
ordinare e filtrare su una proprietà, in una singola query. Le query sono
profonde per impostazione predefinita, cioè restituiscono sempre l'intera
sottostruttura.

Cloud Firestone offre query indicizzate con ordinamento e filtraggio composti.
È possibile concatenare i filtri e combinare il filtraggio e l'ordinamento su una
proprietà in una singola query. Offre la possibilità di scrivere query superficiali
per le sottoraccolte: è possibile interrogare le sottoraccolte all'interno di un
documento invece di un'intera raccolta o anche di un intero documento. Inoltre
le query sono indicizzate per impostazione predefinita, ossia le prestazioni delle
query sono proporzionali alla dimensione del set di risultati, non al set di dati.

• OPERAZIONI DI SCRITTURA E TRANSIZIONI

Realtime Database è un prodotto maturo, infatti offre una stabilità che ci si
aspetta da un prodotto collaudato, provato e vero. Offre latenza molto bassa,
quindi è una grande opzione per la sincronizzazione dello stato frequente.Infine
i database sono limitati alla disponibilità zonale in una singola regione.

Cloud Firestore è attualmente in versione beta. La stabilità in un prodotto beta
non è sempre la stessa di quella di un prodotto completamente lanciato. Alloggia
i dati su più data center in regioni distinte, garantendo scalabilità globale e forte

CLOUDKIT E FIREBASE                                                                !21

affidabilità. Quando Cloud Firestore si è laureato in beta, avrà maggiore
affidabilità del database Realtime.

• SCALABILITÀ

Database Realtime scala fino a circa 100.000 connessioni simultanee e 1.000
scritture / secondo in un singolo database. Il ridimensionamento oltre questo
richiede la condivisione dei dati su più database.
Su Cloud Firestone Il ridimensionamento sarà automatico. Scala
automaticamente completamente (dopo la versione beta), il che significa che
non è necessario suddividere i dati su più istanze.

• SICUREZZA

Per i Realtime Database: regole a cascata che richiedono una convalida
separata.
  • Le regole del database Firebase sono l'unica opzione di sicurezza.

  •   Leggi e scrivi regole a cascata.

  •   Devi convalidare i dati separatamente usando la validateregola.

Cloud Firestone: Sicurezza più semplice e potente per gli SDK per dispositivi
     mobili, Web e server.
 • Gli SDK per dispositivi mobili e Web utilizzano le regole di sicurezza di
     Cloud Firestore . Gli SDK server utilizzano Identity and Access
     Management (IAM) .

  •   Le regole non si sovrappongono a meno che non si utilizzi un carattere
      jolly.

  •   La convalida dei dati avviene automaticamente.

  •   Le regole possono limitare le query: se i risultati di una query possono
      contenere dati a cui l'utente non ha accesso, l'intera query non riesce.

È possibile utilizzare entrambi i database all'interno della stessa app o progetto
di Firebase. Entrambi i database NoSQL possono memorizzare gli stessi tipi di
dati e le librerie client funzionano in modo simile. Se si vuole integrare Firebase

CLOUDKIT E FIREBASE                                                              !22

per la gestione dei dati nel progetto ios, occorre aggiungere Firebase/Core e
Firebase/Database al podfile.

3.3.1 Gestione dei dati in iOS
Per leggere o scrivere dati dal database, è necessaria un'istanza
di FIRDatabaseReference:

var ref : DatabaseReference ! ref = Database . database (). reference ()

I dati Firebase vengono scritti su un FIRDatabase e recuperati collegando un
listener asincrono al riferimento. Il listener viene attivato una volta per lo stato
iniziale dei dati e nuovamente ogni volta che i dati cambiano. Quando si
aggiunge dati all'albero JSON, esso diventa un nodo nella struttura JSON
esistente con una chiave associata. È possibile fornire le proprie chiavi, come ID
utente o nomi semantici. Sebbene il database utilizzi un albero JSON, i dati
memorizzati nel database possono essere rappresentati come determinati tipi
nativi che corrispondono ai tipi JSON disponibili per aiutare a scrivere un
codice più gestibile. Poiché il database in tempo reale di Firebase consente di
annidare i dati fino a 32 livelli in profondità, si potrebbe essere tentati di pensare
che questa dovrebbe essere la struttura predefinita. Tuttavia, quando si
recuperano i dati in una posizione nel database, si recuperano anche tutti i
relativi nodi figlio. Inoltre, quando si concede a qualcuno l'accesso in lettura o
scrittura a un nodo nel proprio database, si concede anche l'accesso a tutti i dati
in tale nodo. Pertanto, in pratica, è meglio mantenere la struttura dei dati
quanto più piatta possibile. Se i dati vengono invece suddivisi in percorsi
separati, chiamati anche denormalizzazione, possono essere scaricati in modo
efficiente in chiamate separate, in quanto è necessario.

CLOUDKIT E FIREBASE                                                                 !23

4. Conclusioni
È un comune malinteso che Firebase e CloudKit siano abbastanza
intercambiabili. Sebbene siano entrambe soluzioni di storage serverless, è
necessario prendere in considerazione le loro caratteristiche prima di decidere di
utilizzare l'una o l’altra. Per quanto riguarda la gestione dei dati, Firebase
disponendo di una struttura JSON ha lo svantaggio di dover gestire
manualmente i riferimenti ad altri nodi nella struttura. CloudKit, d'altra parte, è
un più tradizionale database in stile relazionale, dove gli oggetti si riferiscono ai
figli per identificatore. CloudKit ha un chiaro vantaggio su Firebase qui quando
si tratta di relazioni molti-a-molti o simili. Tuttavia, al momento della scrittura,
CloudKit è ancora nella fase iniziale e non è ancora possibile per un client
richiedere più livelli del grafo dell’oggetto. Quindi, da questo punto di vista
CloudKit ha il chiaro vantaggio di essere in grado di indirizzare facilmente i
riferimenti ovunque, ma è necessario creare una nuova richiesta HTTP per ogni
livello nel grafo degli oggetti che diventa ridondante, aumentando i punti di
errore.

Un grande punto di forza per entrambi i servizi è la loro produttività quando si
tratta di mantenere i contenuti sincronizzati su più client. Ancora una volta,
entrambi affrontano questo compito in uno stile molto diverso.
Quando si sottoscrive un nodo in un database Firebase, l'SDK stabilisce un
websocket tramite il quale tutte le modifiche che si verificano su o sotto il
nodo vengono trasmesse in streaming al client. Se un nodo figlio viene
aggiornato, Firebase offre l'accesso immediato alla struttura JSON appena
aggiornata. La console Firebase riflette anche tutti i cambiamenti in tempo
reale. CloudKit, d’altra parte, ha anche un'API per consentire aggiornamenti a
una query e ricevere una callback quando vengono modificati gli oggetti
corrispondenti. La differenza tra i due in questo caso è che CloudKit non offre
questa possibilità quando le modifiche non riguardano le sottoscrizioni
principali. Quindi in questo caso Firebase è più intuitivo e affidabile per
aggiornamenti in tempo reale.

Un’altro punto importante riguarda l’autenticazione. Firebase consente di
assegnare regole di accesso specifiche per ciascun nodo o del tutto
assenti. L'autenticazione del client può essere eseguita dietro le quinte in modo

CLOUDKIT E FIREBASE                                                                !24

che l'utente non sappia che stai utilizzando Firebase. Per quel che riguarda
CloudKit, il suo modello di autenticazione funziona molto bene su dispositivi
iOS: se l'utente è connesso a un account iCloud nelle sue Impostazioni di
sistema, non ci sono problemi. Tuttavia, se si lavora con altre piattaforme,
l'utente deve essere reindirizzato a una pagina di accesso iCloud. Quindi
Firebase può essere immediatamente accessibile senza autenticazione ma offre
anche la flessibilità necessaria per definire le proprie regole. CloudKit è
probabilmente più sicuro e può fornire un'esperienza senza problemi anche ai
tuoi utenti, ma solo se utilizzano iOS.

Per quanto riguarda il debug la console Firebase mostra l'aggiornamento del
database in tempo reale e consente di modificare i valori direttamente. La
dashboard di CloudKit ha molte più funzionalità rispetto alla console di
Firebase. Mentre è possibile modificare i valori, i dati non vengono aggiornati in
tempo reale, quindi è necessario recuperare continuamente gli oggetti per
vedere le modifiche apportate dai client. Quindi si avrà difficoltà a scrivere uno
script per precompilare i dati che possono essere utilizzati durante lo
sviluppo. Ancora una volta, Firebase è più veloce da sviluppare rispetto a
CloudKit. Se si è preoccupati che il tipo sbagliato venga scritto su un campo,
CloudKit è la strada da percorrere

CLOUDKIT E FIREBASE                                                             !25