| Log in | easy way

 

Benvenuti, oggi andremo a realizzare un log in molto semplice utilizzando sia TinyDb che Firebase, il primo servirà per velocizzare e ricordare i dati in app mentre il secondo ci permetterà di non perdere i dati visto che non subisce modifiche se l'utente cancella i dati dell'app. (Prima di provare l'app vi consiglio di aggiornare token e URL di firebase inserendo quelli del vostro account).

Partiamo con la lista della spesa, ci serviranno le variabili data_user come lista, utente come testo vuoto, punteggio inizializzato a zero come anche id, response come testo vuoto; componenti da aggiungere invece sono Firebase, TinyDb e un Notifier. Lavoreremo anche questa volta con kodular e vi lascerò l'aia per poter visionare meglio il tutto.

QUI invece troverete il file pdf con il diagramma di flusso del codice che andremo a utilizzare , spero vi sia utile per capire i vari passaggi, nel frattempo ho provato questo programma on line per la creazione dei diagrammi ( QUI il link se volete provarlo )

Come abbiamo anticipato lavoreremo con entrambi i database uno per le azioni rapide (TinyDb) e l'altro per salvaguardare i dati (Firebase) ed infatti il nostro primo blocco andrà proprio ad interagire con TinyDb al momento dell'apertura dell'app. Lo scopo di questa operazione per esempio è salvare in locale le info dell'utente per poterle caricare automaticamente dal secondo avvio in poi, diciamo una specie di spunta "remember me", per evitare l'inserimento dei dati ad ogni accesso. La prima cosa che dovremo fare all'avvio è quella di controllare se all'interno del nostro TinyDb esistono già dei dati salvati oppure no, il componente in questione ci permette di impostare anche un valore da restituire nel caso di tag assente ( value If Tag Not There) che noi andremo ad impostare su true. In questo modo il valore true ci farà accedere al primo blocco se non ci sono dati salvati. La scelta sarà gestita da un semplice if then else che ci permetterà di differenziare il caso di dati già presenti oppure no, se i dati richiamati dal db tramite call Get Value sono uguali a true (il valore introdotto su tag assente) facciamo subito partire una notifica che chiede all'utente di inserire il proprio username, questo caso si può verificare o al primo accesso (nuovo utente) oppure se per qualche motivo sono stati cancellati i dati dell'app e vedremo come agire. In caso contrario , quindi il tag utente è presente, andiamo a richiamare i dati tramite call Get Value e tag utente e li salviamo nella variabile data_user. Inserirò tutti i passaggi per rendere la procedura più comprensibile ma per i più bravi potete tranquillamente ottimizzare omettendo i passaggi ridondanti. Se avete già sbirciato  i passaggi successivi avrete notato che per riempire le variabili utente e punteggio utilizziamo i blocchi lista. Si, infatti i dati che abbiamo salvato all'interno del TinyDb sono sotto forma di lista dove sotto il primo indice troviamo il nome dell'utente e nel secondo il punteggio , due valori presi come esempio ma possiamo salvare qualsiasi informazione. Non ci resta che prelevare il primo elemento dalla lista global data_user e salvarlo nella variabile utente e il secondo elemento per salvarlo nella variabile punteggio, poi diamo il benvenuto al nostro utente. Così facendo i dati sono già pronti per essere portati a spasso nella nostra app, magari per settare il nome in una label e il punteggio in un' altra, richiamare altri dati , volendo si potrebbe integrare la richiesta di una password. Ma cosa succede invece se i dati non sono presenti, già abbiamo anticipato che ci sono almeno due possibili strade , nuovo utente o dati cancellati, e qui ci viene in soccorso Firebase, ed è per questo motivo che abbiamo dovuto chiedere il nome utente che useremo per le nostre verifiche. Il componente Show Text Input Dialog di kodular è molto personalizzabile , dall'impostazione dell'icona che appare nella notifica fino ai pulsanti da visualizzare, al testo usato come hint nella texbox e il suo colore, e cosa molto importante un numero identificativo ID 1 della notifica che appare. Questo blocco lavoro in 

simbiosi con un altro che si attiva nel momento in cui l'utente dà l'ok dopo l'inserimento del testo, when Got Text Input From Dialog *vedere edit a fine pagina* restituisce sia l'ID che lo ha attivato sia il response che ha ricevuto, in questo caso ci darà ID = 1 e response = nome utente, che per praticità salveremo all'interno delle rispettive variabili che con tanta fantasia ho chiamato uguali. Mi raccomando scegliamo bene il componente Got perché ce ne sono veramente tanti ed ognuno di loro ha il suo compagno fedele. Adesso che abbiamo tutte le info necessarie andiamo a chiamare la lista dei tag (Get Tag List) da firebase per controllare se l'utente è nuovo , quindi non lo troveremo nel db, oppure i dati sono stati cancellati dal  db locale. Inizialmente avevo introdotto anche un controllo nel caso di lista vuota restituita da firebase (quindi nessun utente ancora registrato nel db) ma continuava a non funzionare (non so il motivo se qualcuno ha idee mi aggiorni) quindi ho pensato di superare il problema inserendo un utente zero che faccia da apri pista 😂 vi consiglio di fare lo stesso così saltiamo anche molti blocchi.*vedere edit a fine pagina* La richiesta della lista di tag a firebase fa attivare il blocco when Tag List restituendo un value che altro non è che la lista con tutti i tag presenti nella posizione in cui siamo , il famoso bucket, che per semplicità abbiamo impostato ad inizio app su utenti.  

Qui dobbiamo dividere quello che avviene nel caso di ID = 1 oppure ID = 3 , il primo percorso si attiverà sempre su risposta alla notifica numero 1 mentre il secondo si attiverà su notifica avente ID 3, veramente comodo la presenza di questi ID nel momento in cui le informazioni da gestire arrivano in un blocco differente da quello in cui arrivano i dati inseriti dall'utente nella notifica. Andiamo a vedere cosa succede dopo la notifica numero 1. Ancora un bivio gestito dal nostro if then else e andiamo a controllare se nella lista value (lista tag con tutti i nomi utenti salvati su  firebase) is in list? thing è presente il nostro response (il nome utente salvato dopo la notifica), se il nome è presente vuol dire che effettivamente i dati sono stati cancellati dal db locale e l'utente esiste , dobbiamo solo richiamare i dati e salvarli in app. Get value tag (di firebase) manderà i dati in when Got Value per poterli salvare nelle rispettive variabili (utente---> tag e punteggio---> value) e aggiornare i dati nel TinyDb così da riaverli al prossimo accesso e seguiremo il primo percorso spiegato, diamo il benvenuto all'utente.

Nel caso invece il nome utente non è presente si attiverà la notifica numero 2 che porterà con se due scelte: l'utente ha sbagliato a digitare il nome e quindi gli diamo la possibilità di Riprovare oppure l'utente è nuovo e deve creare l'account. A seconda della scelta effettuata avremo due azioni differenti che verranno gestite dal blocco when Got Custom Choose Dialog che al suo interno riceve l'ID della notifica e la scelta effettuata (choice). La scelta Riprova ci porta semplicemente al punto di partenza mandando di nuovo la notifica numero 1 che porterà con se tutto quello visto fin ora, la scelta Crea account invece attiva la notifica con ID = 3, ecco dove compare il numero 3 che già abbiamo trovato all'interno della ricezione della lista dei tag. Entrambe le notifiche infatti devono passare per il loro blocco associato when Got Text Input From Dialog dove salviamo ID e response e chiamiamo la lista dei tag, è tutto un girare su alcuni punti di snodo per poi arrivare all'autenticazione dell'utente.  La scelta Riprova abbiamo visto dove porta, la scelta Crea account dopo aver ricevuto il nome utente arriva al blocco di firebase con l' ID =3 quindi andiamo a vedere il codice relativo alla condizione if ID = 3.

Anche qui dobbiamo controllare se il nome inserito dall'utente non è già in uso da un' altra persona e quindi solito bivio if then else dove se il nome è nella lista tag (is in list? thing) creiamo una notifica nuova con ID = 2 dove diamo la possibilità di Riprovare (edit: non deve riprovare ma creare un nuovo account quindi il testo da visualizzare dovrà essere Crea account . Con riprova invece torniamo alla notifica numero 1 che serviva per identificare l'utente ) con un nuovo nome oppure eventualmente di uscire se lo desidera. Se il nome non è presente nel nostro firebase allora l'username è libero e possiamo salvare i dati nelle variabili , nel TinyDb e in Firebase e diamo il benvenuto. L'ultima scelta possibile è Esci che captata nel blocco when Got Custom Choose Dialog ci permette di usare il blocco close application per chiudere l'app. Cosa ne pensate di questo doppio salvataggio? Vi lascio una buona notte e il link per scaricare l'aia e vedere le varie personalizzazioni anche delle notifiche. 👉 File .aia 👈

*EDIT*

Per l'inserimento dell'utente zero basta anche inserire uno store value ad inizializzazione dello screen, in questo modo eviteremo problemi strani e il tag verrà sempre  sovrascritto quindi non ci saranno doppioni.

Scusate per la distrazioni ma ho dimenticato un'operazione molto importante e cioè il controllo sull'inserimento di un campo vuoto, ringrazio molto della segnalazione M@x@M del gruppo telegram  Italy Kodular & Mit App Inventor Community .

Prima verifica da fare quindi è controllare se il campo è vuoto altrimenti possiamo raggiungere agilmente i vecchi blocchi già visti che ci permettono di proseguire con la registrazione utente.

La verifica la possiamo fare tranquillamente introducendo nell' if then else un is empty e leggere il contenuto di response per capire se è vuoto.
Nel caso il campo fosse vuoto dobbiamo fare un'altra differenziazione perché abbiamo due notifiche con introduzione testo, sia per la ricerca di utente già registrato sia per la ricerca di utente nuovo, quindi abbiamo bisogno di un altro if then else. 

Abbiamo sempre ID che ci permette di discriminare i vari casi , infatti, avremo che se ID=1 quindi la notifica iniziale su eventuale utente già esistente ma con database locale cancellato possiamo personalizzare il messaggio invitando a correggere o volendo uscire dall'app. Vi ricordo che queste due scelte già sono settate all'interno del nostro codice quindi si allineano perfettamente al codice esistente. Altro caso invece è su ID=3 quindi utente nuovo in registrazione e anche qui ci allineiamo ai vecchi controlli in when Got Text Input From Dialog. Mi raccomando di continuare con la numerazione degli ID ogni volta che serve una nuova notifica. 

 Se hai apprezzato il mio lavoro offrimi un bel caffè 😍