Observable Binding Para Atualização na UI Android

Observable Binding
Para Atualização na
UI Android
thiengo.com.br

Para que os tipos observáveis de Data Binding?
Quando trabalhando em projeto Android quase sempre temos de ter o trecho de
código responsável por atualizar as visualizações em tela, isso, pois os objetos
com os dados referenciados nas visualizações já foram atualizados e essa
atualização precisa ser refletida ao usuário do aplicativo.
Com os tipos observáveis da biblioteca Data Binding nós, desenvolvedores, não
mais precisamos nos preocupar com essa parte do fluxo: invocações de métodos e
visualizações para refletir a atualização de objetos também em tela.
Há três categorias de classes observáveis dentro da Data Binding API:
• Observáveis de campo (propriedade);
• Observáveis de coleções;
• Observáveis de objetos.
Já lhe adianto que os observáveis de campo quase sempre serão os utilizados em
desenvolvimento. Com isso podemos partir para os códigos de exemplo.

Instalação da biblioteca
No Kotlin a configuração de instalação da biblioteca Data Binding exige as
seguintes referências no Gradle App Level, ou build.gradle (Module: app):
Até o momento da construção deste conjunto de slides a versão estável mais atual
da com.android.databinding era a 3.1.4.

A versão da biblioteca é a mesma versão do plugin do Gradle, logo, no Gradle
Project Level, ou build.gradle (Project: NomeApp), podemos ter:
E então no Gradle App Level teríamos a atualização da referência
'com.android.databinding:compiler':

Saiba que se você estivesse utilizando a linguagem Java somente o código a seguir, no
Gradle App Level, é que seria necessário para liberar o trabalho com a Data Binding API:

Classes de domínio e layout ainda sem tipos observáveis
A seguir alguns protótipos de classes e layout ainda sem uso dos tipos
observáveis, mas já trabalhando a sintaxe Data Binding.
Primeiro a classe Brand:
Então a classe Car:

Então o layout car.xml:
Todos os códigos apresentados funcionam sem problemas, mas em caso de
alguma das propriedades tanto de Brand quanto de Car ser atualizada, ainda é
preciso acessar a View a qual o propriedade está vinculada e então colocar o novo
valor nela para termos o reflexo da atualização também em tela.

Tipos observáveis de campo
Os tipos observáveis de campo são os seguintes:
• ObservableBoolean;
• ObservableByte;
• ObservableChar;
• ObservableShort;
• ObservableInt;
• ObservableLong;
• ObservableFloat;
• ObservableDouble;
• ObservableParcelable;
• ObservableField.
O termo "observáveis de campo" até mesmo aparenta que estaremos com um código
listener para dados de entrada do usuário, em um EditText, por exemplo. Mas na verdade
não, o "campo" é de propriedade, ou variável de instância.

Colocando tipos observáveis de campo no código de
exemplo
Para que as atualizações em objetos dos tipos Brand e Car sejam refletidas também
em tela sem a necessidade de códigos de acesso a Views por parte do desenvolvedor
poderíamos primeiro ter a seguinte nova classe Brand:
E então a seguinte nova classe Car:
A documentação de tipos observáveis Data Binding informa para sempre definirmos
esses tipos como somente de leitura, val. Poderemos utilizar o método set() para
atualizar o valor dentro do tipo observável. Se um novo objeto observável for setado na
propriedade, a igualdade de referência em layout será perdida e assim a atualização
não ocorrerá em tela, pois a propriedade em código dinâmico e a referência em layout
não mais apontam para o mesmo objeto observável.

Agora um pequeno algoritmo de atualização de dados em objetos, somente para teste
de atualização também em tela:

Note que quando trabalhando em código dinâmico, para acessar os valores dos
tipos observáveis temos de utilizar os métodos get() e set(), respectivamente para
acesso e atualização de valores.
No layout XML tudo continua do mesmo jeito, não há necessidade de invocar nem
mesmo o método get().
Executando o projeto com os novos códigos observáveis, temos:
Clique aqui para ativar a animação.

Coleções observáveis: ObservableArrayMap
Há dois tipos de coleções observáveis, vamos iniciar com a ObservableArrayMap. A seguir um
código trabalhando com uma coleção de objetos do tipo Car:

Então o layout car.xml atualizado:

No layout anterior é possível notar que há diferentes modos de acesso aos dados,
podemos trabalhar com o modelo convencional,
map["chave_de_acesso_ao_valor"], ou no modelo também aceito pela sintaxe
Data Binding, map.chave_de_acesso_ao_valor.
Também note a representação de ObservableArrayMap<String, Car> em sintaxe
Data Binding: ObservableArrayMap<String, Car>. Isso, pois os sinais > e <
não são aceitos como valores na sintaxe desta biblioteca.
Executando o projeto com o código anterior, temos:

Coleções observáveis: ObservableArrayList
O outro tipo de coleção observável é o ObservableArrayList, um tipo mais próximo do que poderíamos
utilizar, por exemplo, junto a um adaptador de framework de lista, framework como o RecyclerView. A
seguir um código com um objeto ObservableArrayList sendo utilizado para conter um objeto Car:

Assim o layout car.xml atualizado:

Com ObservableArrayList podemos acessar os valores por meio do método get()
ou utilizando [].
Você não precisa utilizar números ou valores de chave diretamente em código XML
como fizemos no exemplo anterior e no exemplo com ObservableArrayMap. Você
pode colocar as chaves como valores estáticos de uma classe e então acessar
essas chaves com os rótulos definidos em classe, assim o código fica até mais
simples de entender.
Executando o projeto com o novo código, temos:

Objeto observável
A outra maneira de se trabalhar com um tipo observável é herdando da classe
BaseObservable e então implementando as propriedades observáveis da maneira correta. A
seguir a atualização da classe Car:

Note a necessidade de marcar a entidade observável com a anotação @get:Bindable.
Depois, seguindo a sintaxe Kotlin, temos de sobrescrever o método set() de cada propriedade
que terá a característica de ser observável. Logo, aqui os campos têm de ser mutáveis, var.
field representa a propriedade do método set(), regra de sintaxe do Kotlin.
A classe BR é criada pela própria biblioteca Data Binding para conter a propriedade que
deverá ser notificada quando houver um novo valor para ela.
Pode ser necessário um "Build" e "Rebuild Project" para que a classe BR surja já com as
propriedades corretas.
O método notifyPropertyChanged() dispensa comentários, faz exatamente o que o rótulo
dele indica: notifica uma mudança em propriedade.
Note que com este modelo de tipo observável, apesar de termos de colocar mais códigos,
nós temos maior controle sobre quando notificar uma mudança.
Seguramente poderíamos colocar o método notifyPropertyChanged() dentro de
condicionais de avaliação para definir quando ele deve ou não ser invocado.
Uma última observação. A propriedade brand não precisa ter nenhum tipo observável nela.
Aqui vamos aproveitar a classe Brand já atualizada e então prosseguir assim. O trabalho com
o bloco init{} também não é obrigatório, aqui o fiz para manter a igualdade de inicialização de
objeto Car por meio do construtor, como fizemos nos outros slides.

Com isso podemos partir para um código de exemplo com a nossa nova versão de
Car:

Executando o projeto com os novos códigos, temos:

Tipos observáveis em adaptadores de listas
É importante falar também dos tipos observáveis em adaptadores de lista, pois a
principio o que pensamos é que as coleções observáveis nos permitem a fácil
inclusão / remoção de itens e atualização de qualquer um deles.
Na verdade a atualização de qualquer um dos itens já em lista realmente vai ser
refletida também em tela, assumindo que os objetos em lista têm suas
propriedades observáveis.
Mas mesmo quando trabalhando com uma coleção observável, adicionar ou
remover um item não tem efeito algum em tela.
Para que a adição (ou remoção) de um item tenha efeito visual, ainda é preciso
também invocar algum dos métodos de notificação de atualização de lista:
notifyDataSetChanged() ou notifyItemChanged().
Ou seja, ao menos para frameworks de lista, para termos efeito visual na adição,
remoção ou atualização de posição de item, os códigos permanecem os mesmos
quando não utilizando tipos observáveis.

Pontos negativos
• Os tipos de coleções observáveis têm o exato mesmo efeito em classe
adaptadora que qualquer outro tipo de coleção mutável. O processo de
adição, remoção e atualização de posição de item ainda exige a invocação de
algum método de notificação da classe adaptadora;
• A documentação não oferece exemplos implementando a Interface
Observable.

Ponto positivo
• Permite que nós desenvolvedores Android não mais tenhamos de se
preocupar também com os códigos de atualização de dados em tela.

Conclusão
Que a biblioteca Data Binding é importante você certamente já deve estar ciente,
principalmente em contexto de mercado de trabalho.
Os tipos observáveis desta biblioteca nos dão ainda mais arsenal de
programação, também por remover de nosso tempo de desenvolvimento a
necessidade de criar códigos de atualização de dados em tela.
Mas há um custo para isso: trabalhar os tipos da API ou implementar a classe
BaseObservable, está última que exige ainda mais linhas de código e
conhecimento Kotlin.

Fontes
Conteúdo completo, em texto e em vídeo, no link a seguir:
• Observable Binding Para Atualização na UI Android.
Fontes:
• Work with observable data objects;
• Documentação oficial ObservableParcelable;
• ObservableParcelable<String> is not working - Resposta de Виталий
Махнев.

Para estudo
• Treinamento oficial:
• Prototipagem Profissional de Aplicativos Android.
• Meus livros:
• Receitas Para Desenvolvedores Android;
• Refatorando Para Programas Limpos.
• Redes:
• Udemy;
• YouTube;
• Facebook;
• LinkedIn;
• GitHub;
• Twitter;
• Google Plus.
• Blog App.

Observable Binding Para
Atualização na UI Android
thiengo.com.br
Vinícius Thiengo
thiengocalopsita@gmail.com

Observable Binding Para Atualização na UI Android

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Observable Binding Para Atualização na UI Android

Semelhante a Observable Binding Para Atualização na UI Android (20)

Mais de Vinícius Thiengo

Mais de Vinícius Thiengo (9)

Último

Último (20)

Observable Binding Para Atualização na UI Android