7 minutos de leitura
Autor(a)
Alex é instrutor e desenvolvedor e possui experiência em Java, Kotlin, Android. Atualmente cria conteúdo no canal https://www.youtube.com/@AlexFelipeDev.
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Neste artigo, vamos explorar o View Binding, uma técnica com o objetivo de substituir a forma como buscamos views no Android, seja pelo findViewById(), ou até mesmo, pelo Synthetic do Kotlin Android Extension que agora é obsoleto.
Para demonstrar os exemplos, vamos utilizar o Todo, um App capaz de cadastrar e listar tarefas:
As implementações foram feitas da seguinte maneira:
Activity com um RecyclerViewFragmentO motivo de utilizar essas entidades, é demonstrar as diferentes implementações com o View Binding.
Caso tenha interesse em acompanhar o conteúdo aplicando os exemplos, você pode acessar o repositório do projeto no GitHub.
Como vimos, o View Binding trata-se de uma alternativa para buscar Views do Android, porém, por padrão, temos acesso ao findViewById(). Então, por que deveríamos considerar o View Binding?
Os principais motivos para o uso do View Binding são:
Agora que conhecemos os motivos para utilizar o View Binding, vamos começar com a configuração.
O View Binding é configurado por módulo de um projeto Android, portanto, dentro do arquivo build.gradle do módulo App, adicionamos a seguinte instrução:
android {
...
buildFeatures {
viewBinding true
}
}
Basta sincronizar que o View Binding está configurado! Simples assim. 🙂
Após habilitar o View Binding, automaticamente, ele gerará classes que representam cada arquivo de layout do módulo no seguinte padrão: nomeDoLayoutBinding.
Dentro do projeto temos os seguintes arquivos de layout:
Isso significa que ao configurar o View Binding, ele gera as seguintes classes para os layouts:
FormularioNotaActivityBindingFormularioNotaFragmentBindingItemNotaBindingListaNotasActivityA partir dessas referências, podemos acessar as views de cada layout considerando os destaques do View Binding.
Para começar o nosso exemplo, vamos acessar a ListaNotasActivity:
class ListaNotasActivity : AppCompatActivity(R.layout.lista_notas_activity) {
// restante do código
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val recyclerView = findViewById<RecyclerView>(R.id.lista_notas_activity_recyclerview)
recyclerView.adapter = adapter
configuraFab()
}
private fun configuraFab() {
val fab = findViewById<ExtendedFloatingActionButton>(R.id.lista_notas_activity_fab)
fab.setOnClickListener {
// restante do código
}
}
}
Note que utilizamos o findViewById() para buscar o RecyclerView e o ExtendedFloatingActionButton. Dado esse exemplo, vamos adaptar o código para usar o View Binding.
Para utilizar o View Binding, primeiro precisamos realizar o processo de inflar a View. Para isso, no onCreate(), acesse a referência ListaNotasBinding e chame o método inflate() enviando o layoutInflater da Activity:
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val binding = ListaNotasActivityBinding.inflate(layoutInflater)
// restante do código
}
Observe que criamos a variável
binding, esse padrão de nomeação é comum quando realizamos o processo de binding de View com o View Binding.
A partir da variável binding, podemos acessar as views, como, por exemplo, o RecyclerView:
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val binding = ListaNotasActivityBinding.inflate(layoutInflater)
val recyclerView = binding.listaNotasActivityRecyclerview
recyclerView.adapter = adapter
configuraFab()
}
E para ter um acesso por todos os membros, podemos até mesmo tornar o binding uma property lazy:
class ListaNotasActivity : AppCompatActivity(R.layout.lista_notas_activity) {
private val binding by lazy {
ListaNotasActivityBinding.inflate(layoutInflater)
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val recyclerView = binding.listaNotasActivityRecyclerview
// restante do código
}
// restante do código
private fun configuraFab() {
val fab = binding.listaNotasActivityFab
// restante do código
}
}
Se testarmos o App apenas com essa modificação, o RecyclerView e o FAB não funcionam! Isso acontece porque precisamos vincular a View do View Binding com a Activity, para isso, podemos chamar o método setContentView() enviando o root do binding
class ListaNotasActivity : AppCompatActivity() {
private val adapter by lazy {
ListaNotasAdapter(this)
}
private val binding by lazy {
ListaNotasActivityBinding.inflate(layoutInflater)
}
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val recyclerView = binding.listaNotasActivityRecyclerview
recyclerView.adapter = adapter
configuraFab()
setContentView(binding.root)
}
// restante do código
}
A partir do momento que utilizamos o View Binding, é importante remover a referência do layout no construtor da Activity ou em um
setContentView().
Com esse ajuste, o nosso código funciona sem qualquer problema!
No ListaNotasAdapter do RecyclerView, o uso do ViewBinding é feito durante a criação do ViewHolder. A técnica é similar ao da Activity, mas seguindo os padrões de inflate do adapter:
class ListaNotasAdapter(
private val context: Context,
notas: List<Nota> = listOf()
) : RecyclerView.Adapter<ListaNotasAdapter.ViewHolder>() {
private val notas = notas.toMutableList()
override fun onCreateViewHolder(
parent: ViewGroup,
viewType: Int
): ViewHolder {
val binding = ItemNotaBinding
.inflate(
LayoutInflater.from(context),
parent,
false
)
return ViewHolder(binding)
}
// restante do código
class ViewHolder(binding: ItemNotaBinding) :
RecyclerView.ViewHolder(binding.root) {
private val titulo = binding.itemNotaTitulo
private val descricao = binding.itemNotaDescricao
fun vincula(nota: Nota) {
titulo.text = nota.titulo
descricao.text = nota.descricao
}
}
}
Observe que a grande diferença é que o ViewHolder recebe o View Binding do layout desejado, nesse caso, o ItemNotaBinding. Então, é enviada a view com o binding.root para o construtor do RecyclerView.ViewHolder() e o parâmetro binding pode ser utilizado para buscar as views desejadas.
No Fragment temos um cenário diferente. Pois, devido ao processo de recriar a View cada vez que ele é acessado, somos responsáveis em criar o View Binding e limpá-lo quando a view é destruída:
class FormularioNotaFragment : Fragment() {
private var _binding: FormularioNotaFragmentBinding? = null
private val binding: FormularioNotaFragmentBinding get() = _binding!!
override fun onCreateView(
inflater: LayoutInflater,
container: ViewGroup?,
savedInstanceState: Bundle?
): View {
_binding = FormularioNotaFragmentBinding
.inflate(
inflater,
container,
false
)
return binding.root
}
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
val botao = binding.formularioNotaBotaoSalvarFragment
botao.setOnClickListener {
salvaNota()
}
}
private fun salvaNota() {
val campoTitulo = binding.formularioNotaTituloFragment
val titulo = campoTitulo.text.toString()
val campoDescricao = binding.formularioNotaDescricaoFragment
val descricao = campoDescricao.text.toString()
val nota = Nota(titulo, descricao)
NotaDao().salva(nota)
activity?.onBackPressed()
}
override fun onDestroyView() {
super.onDestroyView()
_binding = null
}
}
Da mesma maneira que foi feito na Activity, no Fragment também é importante remover a referência de layout no construtor.
Essa possível implementação é sugerida na página da documentação, e explica que mesmo usando o null assertion operator (!!), bastante perigoso por conta de NPE, não corremos o risco de NPE se acessarmos o binding nos estados de ciclo de vida do Fragment entre onCreateView() e onDestroyView():
Com base no fluxograma, podemos acessar o binding a partir do onViewCreated(), até o onSaveInstanceState().
Por gerar código, o View Binding também custa tempo de build que, segundo a documentação, por não ter anotações durante a configuração, ele é mais rápido que alternativas como o Data Binding.
Além disso, se preferir evitar a geração de código em layouts específicos, seja pelo tempo de build ou por não usar referências do layout, como é o caso da FormularioNotaActivity, que tem apenas um container de Fragment, podemos ignorar layouts adicionando tools:viewBindingIgnore="true" no root da View do layout.
Considerando o exemplo da FormularioNotaActivity, fica da seguinte maneira:
<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".ui.activity.FormularioNotasActivity"
tools:viewBindingIgnore="true">
<androidx.fragment.app.FragmentContainerView
android:id="@+id/formulario_notas_fragment_container_activity"
android:name="br.com.alura.todo.ui.fragment.FormularioNotaFragment"
android:layout_width="0dp"
android:layout_height="0dp"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent" />
</androidx.constraintlayout.widget.ConstraintLayout>
Com esse ajuste, a classe FormularioNotaActivity não é mais gerada pelo processo de build do projeto.
O View Binding é a técnica mais recente e recomenda pela equipe do Android, portanto, se atualmente você utiliza o synthetic, o recomendado é que migre para o View Binding. Caso mantenha o uso apenas do findViewById(), você pode considerar o uso do View Binding, pois, além de facilitar a busca das views, também existe o benefício de evitar NPE ou problemas de casting.
Caso tenha interesse em consultar as mudanças do projeto, confira este commit.
Avalie este artigo
