3
respostas

Visualizando a mudança na noticia

Professor Alex Felipe, quando vi a atividade 5 da Aula 4 fiquei um pouco confuso com a sua abordagem para atualizar a visualização, então tentei fazer da minha maneira e acho que encontrei uma forma mais fluida de atualizar a tela de visualização.

repository.buscaPorId(noticiaId)

meu busca por ID ficou da seguinte maneira no repository

fun buscaPorId(
            noticiaId: Long
    ): LiveData<Noticia?> {
        BaseAsyncTask(quandoExecuta = {
            dao.buscaPorId(noticiaId)
        }, quandoFinaliza = {
            noticiaEncontrada.value = it
        }).execute()
        return noticiaEncontrada
    }

repara que quando eu acho a noticia eu atualizo a property "noticiaEncontrada". E quando eu executo o remove(), eu uso essa instancia de "noticiaEncontrada" que esta salva no repository para remover. Dessa maneira nao preciso passar nada para o remove, para ele saber quem ele deve remover.

fun remove(): LiveData<Resource<Void?>> {
        val liveData = MutableLiveData<Resource<Void?>>()
        noticiaEncontrada.value?.let {
            removeNaApi(it, quandoSucesso = {
                liveData.value = Resource(null)
            }, quandoFalha = { erro ->
                liveData.value = Resource(null, erro)
            })
        }
        return liveData
    }

Acredito que seja uma abordagem mais interessante e um pouco menos confusa. Gostaria de saber sua opiniao

3 respostas

Oi Flávio, tudo bem?

Sobre o uso de property, ela se torna interessante quando manter o valor do que já foi buscado uma vez é desejado, ou seja, se alguém já buscou a notícia 1 e acontece uma rotação, não é necessário buscar novamente.

Porém, se alguém pedir para buscar a notícia 2 sendo que uma vez já foi feita a busca da notícia 1 ela corre o risco de apresentar o conteúdo da notícia 1, dado que a busca da notícia 2 é assíncrona e pode não terminar rapidamente, por esse motivo usar a property pode ser arriscado para buscas que envolve filtros.

Em outras palavras, vale mais a pena criar um LiveData em buscas por filtro. Isso também vale para a remoção! Principalmente por ser um caso mais perigoso que pode apagar um dado inesperado, considerando esse cache quando usamos properties.

Portanto, considere o uso de uma property para LiveData em buscas genéricas, como é o caso da busca por todos registros ou buscas que envolvem paginações que tem a característica de apresentar um conjunto de dados que pode ser atualizado a qualquer momento e é um comportamento esperado.

Também concluímos que, sempre envie o valor para filtro via parâmetro da função, ou receba via construtor do ViewModel e garanta que ele não seja alterado para evitar inconsistências em chamadas que precisam dessa referência (busca argumentos, inserção, edição e remoção).

[]s

Sim, estou passando o id via constructor. Entendi, realmente é bem perigoso caso a execução assíncrona demore muito, mas eu não consegui entender onde nossas implementações se diferem. No caso da aula, uma instancia foi segurada dentro do viewModel, não cairíamos assim, no mesmo problema? Pois o buscaPorId poderia demorar também e o valor do noticia Encontrada ainda referenciar o id antigo?

Quando você se cria um LiveData a cada chamada da função, não se mantém o valor anterior, pois a cada chamada sempre vai criar um novo LiveData sem nenhum valor.

No caso de properties, o valor é mantido, por isso do problema. Inclusive, você pode fazer o teste colocando um log para a chamada liveData.value que apresenta o valor contido no LiveData, faça o teste quando é uma property e quando é criado dentro de uma função.

Confira se o da property mantém o valor anterior e confira se o LiveData criado dentro da função retorna null.

[]s

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software