Realtime Databases — Part 1

Depois de ter falado sobre alguns dos serviços super interessantes que o Firebase oferece no último post, chegou a altura de colocar a mão na massa e explorar cada um deles começando pela realtime database.

Antes de entrar a fundo no tópico deste post, devo dizer que esta série falará em detalhes sobre os serviços do firebase tendo foco em como interligar os mesmo com o Android :). Sendo assim, conhecimento de desenvolvimento de apps será necessário e como nunca e tarde para começar uma nova aventura, sugiro que comecem por AQUI.

Como escrevi no POST anterior, Realtime databases é um serviço oferecido no Firebase que nos oferece mecanismos para guardar dados e automaticamente o poder de sincronizar a informação para todos os clientes que estejam a obter dados dela em “tempo real” :) sem ter de pensar em Services, SyncAdapters, JobSchedulers, GCMNetworkManager ou outras API’s em outras plataformas(iOS & Web) que iriam aumentar o tempo de desenvolvimento e muita dor de cabeça.

Boa parte da magia deste serviço esta concentrada no facto dos dados serem gravados como objectos utilizando a Java Script Object Notation ou como é normalmente conhecida JSON.

O JSON como o nome diz e uma notação muito utilizada na comunicação entre diferentes sistemas e as mensagens são enviadas em “texto puro” como uma string formatada com um conjunto de chaves para valores específicos como mostra a imagem abaixo de um JSON poderia ser utilizado para representar uma lista de pessoas.

Na realtime database, toda nossa informação é armazenada em um árvore que pode ter uma profundidade de ate 32 sub-árvores.

Para melhor explicar o que acabei de escrever teremos de criar o nosso primeiro projecto no Firebase e aprender fazendo.

1. Nevegue para o CONSOLE do firebase e crie um novo projecto.

2. No console, seleccione Database das opções disponíveis a esquerda.

A janela ilustrada na figura acima contém 2 tabs onde a primeira é para que possamos visualizar ou modificar os dados que estão na base de dados e a segunda(terá um post dedicado mais a frente) para que possamos configurar e simular várias regras de acesso a base de dados que definam aspectos como permissões para escrever para um certo no, validação dos dados entre outras.

Como mencionei acima sobre a nossa base de dados ser como uma árvore, a raiz desta árvore encontra-se no link demonstrado na imagem e a medida que a informação for adicionada um novo no será criado e o link da raiz vai tornando-se mais especifico para cada informação que adicionamos.

Tomemos como exemplo para esta série, uma app que permite que pessoas que estejam para se casar encontrem “salões” adequados para realizar o casamento.

Apesar de não ser aconselhado e não ser como as coisas vão acontecer na realidade, o console nos permite que possamos adicionar ou modificar qualquer dado na base de dados.
Mas antes de começar a escrever qualquer tipo de informação, o passo mais importante é definir como a informação estará estruturada, isto é, se pensarmos em base de dados relacionais (MySQL que muitos conhecem) seria equivalente a dizer que temos de definir que tabelas teremos e como elas estarão relacionadas.

Porque não temos aqui nenhuma base de dados relacional, ao invés de pensar em tabelas, temos de pensar nos objectos que queremos representar, os seus atributos e uma forma de relacionar(veremos quando for pertinente).

A princípio fica difícil de entender a ideia de não ter tabelas mas ao longo do tempo ira mostrar-se algo fácil e interessante pois e fácil de se habituar pois iremos guardar sem ter de preocupar em fazer parse de/para JSON e para o caso do android como veremos a frente transformar estes objectos ao equivalente em Java é tão natural quanto escrever uma classe e simplesmente criar as variáveis com os mesmos nomes que os atributos.

A figura acima mostra como podemos guardar a lista de salões para a pequena app que será construída durante esta serie. Para chegar a uma estrutura similar a da imagem acima é importante pensar:

1. Quais são os atributos importantes/necessários que devemos ter no objecto salão?
2. Qual e o atributo que poderia ser utilizado para identificar de forma unívoca um salão?

Estas duas perguntas são importantes pois, a primeira nos ajuda a responder sobre que informação iremos precisar mostrar no nosso cliente ou será importante guardar e a segunda ira ajudar a definir a melhor forma de organizar esta informação na base de dados.

Olhando atentamente para imagem, para criar a lista de salões, depois da raiz, foi criado um novo nó ou sub-árvore salões que por sua vez tem filhos cada um identificado por um id(Neste caso são os números mas poderia ser qualquer outro valor que nos definimos ou gerado automaticamente pelo Firebase), que por sua vez tem informação e sub árvores no nosso caso “location”.

Dada esta estrutura, para aceder ao objecto do salão 2 percorreríamos a árvore e ficaríamos com a seguinte url https://wedding-93044.firebaseio.com/salons/2 como mostra a imagem abaixo ao clicar por cima do id do salão 2.

E com este exemplo chegamos ao fim deste primeiro post que tinha como objectivo principal, introduzir ao console e explicar sobre como guardar e estruturar dados na realtime database.
Entender todo o conceito a volta da estruturação de dados, pode levar algum tempo para digerir, principalmente para desenvolvedores com background em base de dados relacionais e a melhor solução para superar esta barreira é simplesmente colocar a mão na massa e a partir do console ir criando a estrutura de um projecto que deseja trabalhar ou fazer modificações ou adicionar propriedades a estrutura que utilizaremos nesta serie.

Caso encontrem alguma dificuldade em alguns dos pontos acima, nao hesitem em deixar um comentário que ficarei feliz em responder as questões :)

Porque este post foi focado em aprender como estruturar e guardar os dados na realtime database, o próximo post iremos fazer a conexão desta realtime database com o android para que seja possível visualizar a lista dos salões na aplicação :).

Ate a próxima,

DM