Entendento Arquitetura MVI + Flow
•Transferir como PPTX, PDF•
1 gostou•350 visualizações
Existem diversas arquiteturas no mundo Android hoje em dia, a mais vista entre elas é a MVVM que utiliza programação imperativa. Nessa palestra vamos falar sobre MVI e como criar uma arquitetura reative utilizando um fluxo unidirecional entre as ações do usuário e os diferentes estados apresentados na tela.
Recomendados
Mais conteúdo relacionado
Semelhante a Entendento Arquitetura MVI + Flow
Semelhante a Entendento Arquitetura MVI + Flow (20)
Último
Último (8)
Entendento Arquitetura MVI + Flow
- 1. MVI + Flow Uma arquitetura reativa com fluxo unidirecional 1
- 2. • Roque Buarque Junior • Desenvolvedor Android • Berlim - Alemanha • Sharenow • Twitter @roqbjr Sobre mim :) 2
- 3. O que esperar? • Entender a arquitetura MVI • Visão geral de outras arquiteturas • Como lidar com estados e eventos • Exemplo de código com Flow • Implementar uma feature juntos 3
- 4. O que não esperar? • Coroutines Scopes/Jobs • Testes integrados 4
- 5. O que é MVI? M Model estado imutável, única fonte de verdade. 5
- 6. O que é MVI? V View que representa a UI. 6
- 7. O que é MVI? I Intent, não é do Android, representa a intenção de performar uma ação do usuário ou do app. 7
- 9. Case • Eventos/Intent • Incrementar • Decrementar • Estados • Loading • Content • Message 9
- 12. INTENT Jogo de palavras MODEL VIEW MODEL STATEPRESENTER INTERACTOR USE CASE 12
- 13. O que as arquiteturas tem em comum? MVP MVVM MVI Model 13
- 14. class CounterPresenter { private lateinit var view: CounterView private val repository = CounterRepository fun start(view: CounterView) { … } fun increase() { view.loading(true) repository.increase(object : CounterCallback{ override fun onSuccess(value: Int) { view.loading(false) view.updateCounter(value) } override fun onError(throwable: Throwable) { view.loading(false) view.error(throwable.message ?: "error") } }) } fun decrease(){ … } } Presenter 14
- 15. override fun updateCounter(value: Int) { txtCounter.text = value.toString() } override fun loading(isLoading: Boolean) { progressBar.isVisible = isLoading } override fun error(msg: String) { txtCounter.text = msg } View 15
- 16. MVP - Stateless ModelPresenterView Input Modify Update 16
- 17. ViewModel class CounterViewModel: ViewModel() { private val repository = CounterRepository val error = MutableLiveData<String>() val loading = MutableLiveData<Boolean>() val content = MutableLiveData<Int>() fun increase(){ loading.value = true repository.increase(object : CounterCallback{ override fun onSuccess(counter: Counter) { loading.value = false content.value = counter.value } override fun onError(throwable: Throwable) { loading.value = false error.value = throwable.message ?: "error" } }) } } 17
- 18. View class CounterViewModel: ViewModel() { private val repository = CounterRepository val error = MutableLiveData<String>() val loading = MutableLiveData<Boolean>() val content = MutableLiveData<Int>() fun increase(){ loading.value = true repository.increase(object : CounterCallback{ override fun onSuccess(counter: Counter) { loading.value = false content.value = counter.value } override fun onError(throwable: Throwable) { loading.value = false error.value = throwable.message ?: "error" } }) } } private fun setupObserver() { viewModel.content.observe(this, Observer { txtCounter.text = it.toString() }) viewModel.error.observe(this, Observer { txtCounter.text = it }) viewModel.loading.observe(this, Observer { progressBar.isVisible = it }) } 18
- 19. MVVM - Stateful Model View Model ViewState View Input Modify Observe/Notify 19
- 20. O que é o Model? data class CounterModel( val value: Int?= null, val isLoading: Boolean, val msg: String? = null ) 20
- 22. Como lidar com estados? 22
- 23. Quais são os desafios? Mutabilidade Múltiplos estados Sincronização 24
- 24. Mutabilidade 25
- 25. ViewModel class CounterViewModel : ViewModel() { private val repository = CounterRepository private val _model = MutableLiveData<CounterModel>() val model: LiveData<CounterModel> = _model fun increase() { _model.value = CounterModel(isLoading = true) repository.increase(object : CounterCallback { override fun onSuccess(counter: Counter) { _model.value = CounterModel(isLoading = false, value = counter.value) } override fun onError(throwable: Throwable) { _model.value = CounterModel( isLoading = false, msg = throwable.message ?: "error" ) } }) } } 28
- 26. View private fun setupObserver() { viewModel.model.observe(this, Observer { model -> progressBar.isVisible = model.isLoading val count = model.value?.toString() ?: "" txtCounter.text = count model.msg?.let { txtCounter.text = it } }) } 29
- 28. O que aconteceria? CounterModel( value: Int? = 2, //Mostrar text com contador isLoading:Boolean = true, //Mostrar loading msg: String? = “Algo deu MUITO errado!” //Mostrar erro ) 31
- 30. Data class único Imutabilidade, uma fonte da verdade. Maneira mais simples Tudo dentro de uma classe única Regra na View Múltiplos estados override fun render(model: CounterModel) { progressBar.isVisible = model.isLoading val count = model.value?.toString() ?: "" txtCounter.text = count model.msg?.let { txtCounter.text = it } } 34
- 31. Hierarquia de sealed class Imutabilidade, uma fonte de verdade. Cada classe representa uma implementação do estado Cada item pode ter seus próprios campos Utiliza object evitando criar mais de uma instância Evita enviar o mesmo estado mais de uma vez no caso de object sealed class CounterState { data class Content( val value: Int ) : CounterState() object Loading : CounterState() data class Error( val msg: String ) : CounterState() } 35
- 32. View private fun setupObserver() { viewModel.state.observe(this, Observer { state -> render(state) }) } private fun render(state: CounterState) { when (state) { is CounterState.Loading -> progressBar.isVisible = true is CounterState.Content -> { progressBar.isVisible = false txtCounter.text = state.value.toString() } is CounterState.Error -> { progressBar.isVisible = false txtCounter.text = state.msg } } } 36
- 33. ViewModel class CounterViewModel : ViewModel() { private val repository = CounterRepository private val _state = MutableLiveData<CounterState>() val state: LiveData<CounterState> = _state fun increase() { _state.value = CounterState.Loading repository.increase(object : CounterCallback { override fun onSuccess(counter: Counter) { _state.value = CounterState.Content(counter.value) } override fun onError(throwable: Throwable) { _state.value = CounterState.Error( throwable.message ?: "error" ) } }) } } 37
- 36. State Machine/ Máquina de estado Jogando ParadoAcabado Pause ResumeComeçar Morreu 40
- 37. Consegue quebrar uma tela em vários estágios Quando? Onde? Como? Visão do fluxo inteiro Fácil de identificar qual estágio é responsável por cada requisição Testável Sustentável/Maintainable Estável 41 State Machine/ Máquina de estado
- 38. State Machine/ Máquina de estado Loading Message Content Error Success ??? Action/AçãoState/Estado Executing Even t 42
- 41. Components Event Action State SyncState Intent do MVI, Uma intenção do usuário ou do app, e.g. click no botão. A ação que minha view deve executar, por exemplo execution/loading Combinação entre meu retorno/data da API com o meu SyncState Estado atual da minha view/tela 45
- 42. Components Action Creator Reducer Guard Recebe um evento, conecta meu repositório e cria uma ação para o meu reducer transformar em novo estado Recebe o estado atual da view e uma nova ação e devolve um novo estado dependendo do guard Valida o boolean recebido do reducer para decidir se vai prosseguir 46
- 43. MVI Event New State Action Creato r Event/Increase Api Action/Executing Reduc er (Event) -> Action (CurrentState, Action) -> NewState Guard Content/Execution Loading 49
- 44. State Machine/ Máquina de estado Loading Message Content Error Success ??? Action/AçãoState/Estado Executing Even t 50
- 45. MVI Event New State Action Creato r Event/Increase Api Request Result Action/Success Reduc er (Event) -> Action (CurrentState, Action) -> NewState Guard Message/Success 51
- 46. State Machine/ Máquina de estado Loading Message Content Error Success ??? Action/AçãoState/Estado Executing Even t 52
- 47. Reducer • Concentra as mudanças de estado em somente um lugar • Fácil de debugar • MUITO fácil de testar • Vai concatenar seu estado atual no seu novo estado. 54
- 48. Como lidar com eventos? 55
- 50. Eventos View Repo 1 2 Incrementar Decrementar 1 0 2 1 1 + 1 = 2 2 - 1 = 1 1 - 1 = 0 0 + 1 = 1 Esperado Encontrado 57
- 51. Maneira mais fácil de enfileirar eventos 58
- 52. Caso real 59
- 53. 60
- 56. Fluxo unidirecional Event Process State Repository ViewModel View Action Creator Reducer Guard (Event) -> Action (State, Action) -> State 64
- 57. Flow 67
- 58. Emitir e Coletar flow<Event> { emit(CounterEvent.Increase) } scope.launch { state.collect { state -> render(state) } } 70
- 59. Flow outros operadores fun getActionFlow(): LiveData<CounterAction> = fetchAsFlow() .flatMapLatest { secondNetworkCallThatDependsOnFirst() } .map { CounterAction.Error("deu ruim") } .onEach { } .take(2) .filter { } .catch { emit(CounterAction.Error("erro inesperado") } .onCompletion { } .flowOn(Dispatchers.IO) .asLiveData() 80
- 60. State flow State-Holder que emite o valor atual MutableStateFlow para alterar o valor Pede um valor inicial Muito util deixar na view model para sobreviver a mudanças de configuração HOT - Diferente de um flow builder o StateFlow vai continuar emitindo 81
- 61. Shared flow Compartilhar emissões entre mais de um coletor É um hot flow Guarda um cache Da um replay desse cache para novos coletores Substitui o BroadcastChannel 82
- 62. Ligando os pontos Reducer State SyncState Action Creator Event Guard 84
- 63. Cadeia Event/Increase Action/Executing State/Loading ViewModel - Process View Action Creator Reducer/Guard Content StateFlow CacheRepositório Novo Estado 95
- 64. Evento e Estado private val event = MutableSharedFlow<Event>() val state: StateFlow<State> = toState() 96
- 65. Evento e Estado private val event = MutableSharedFlow<Event>() val state: StateFlow<State> = toState() suspend fun process(event: Flow<Event>) { event.collect { this.event.emit(it) } } 97
- 66. toState private fun toState(): StateFlow<State> { } 98
- 67. Evento private fun toState(): StateFlow<State> { return event .onEach { Log.d(TAG, "Event $it") } } 99
- 68. Action private fun toState(): StateFlow<State> { return event .onEach { Log.d(TAG, "Event $it") } .flatMapConcat { event-> action(event) } .distinctUntilChanged() .onEach { Log.d(TAG, "Action $it") } } 100
- 69. Reducer/New State private fun toState(): StateFlow<State> { return event .onEach { Log.d(TAG, "Event $it") } .flatMapConcat { event-> action(event) } .distinctUntilChanged() .onEach { Log.d(TAG, "Action $it") } .map {action-> reducer(state.value, action) } .onEach { Log.d(TAG, "State $it") } } 101
- 70. State flow private fun toState(): StateFlow<State> { return event .onEach { Log.d(TAG, "Event $it") } .flatMapConcat { event-> action(event) } .distinctUntilChanged() .onEach { Log.d(TAG, "Action $it") } .map {action-> reducer(state.value, action) } .onEach { Log.d(TAG, "State $it") } .onCompletion { Log.d(StateViewModel::class.java.name, "onCompletion for $state") } .stateIn(viewModelScope, SharingStarted.Lazily, initialState) } 102
- 72. Deu para entender um pouco de MVI? 104
- 75. Obrigado! 107
Notas do Editor
- 2 anos com MVI Experiencia do service App Interagir
- Even MVI is very powerful to write integration test this will be for next time Por mais que vamos ver escopo no código, nao eh o foco dessa palestra entrar no assunto
- Model/State immutable, like this we can have only on source of true
- Pretty much the same, it represents UI
- THIS IS NOT ANDROID INTENT In order to help us to better understand I will call intent as event
- Aqui podemos ver um versão mais base do MVI Muitas arquitetura MVVM chegam perto ou são implementadas dessa mesma maneira No exemplo dessa talk vamos ter alguns outros componentes para construir nossa arquitetura MVI Que sao o Action Creator e o Reducer, vou explicar sobre eles mais pra frente, mas ja guardem esse nome
- Essa eh a nossa aplicação Vamos desenvolver juntos a funcionalidade de decrementar Deixar mais claro ou rodar o app
- Trazendo mais uma visualização do MVI dessa vez matematicamente v(m(I())) eh uma função composta por outras funções Funçao equivalente, com multiplos inputs tem apenas um output Math might not be everyone’s cup of tea, but a mathematician doesn’t know what a bug is. Software Engineers do.
- Mau implementados podem te dar muita dor de cabeça Tratado com carinho sao as soluções de todos os seus problemas MVI faz isso muito bem
- Ficamos 3 horas para decidir oq nossa view model era responsável Agora lancei mais duas novas palavras ActionCreator e o Reducer e Guard
- View que ja sabemos = UI Model Separar O que eh o Model?
- Alguem consegue ver oq eh o model aqui? repository? Interface view? Loading/updateCounter/error?
- E aqui na minha view, quando, onde e como? Eu posso falar que chegou apenas 1 output igual a gente view na função no slide anterior?
- Esse eh o comportement do MVP, nao possui nenhum estado Por sua vez o MVP controla o estado da view, em relação a mostrar ou esconder algo.
- Mesmas perguntas aqui Onde esta o model?
- Cade o model?
- Diferente do presenter o viewmodel tem estado e por sua vez sempre que esse estado eh alterado ele notifica a view que esta observando esse estado
- Vamos pensar no model dessa maneira, um data class que contem todos os meus views states.
- De forma mais grafica seria mais ou menos isso Model contem oq vem da minha API e contem os estados que minha view vai ter
- Mutabilidade, onde diferentes lugares podem alterar o seu model/state Multiplos estados, nao somente estados da view, mas um estado da sua requisição por exemplo, estado do seu view model e estado da sua view que seria isEnable, isVisible entre outros. Por que devemos sincronizar? Evitar suposição do estado atual para enviar o proximo.
- Criando nosso model e colocando os states dentro do model a gente traz um pouco de imutabilidade, enviando cada vez um estado para nossa view. Loading Counter Error Todos vao através do render function da minha interface
- Que por sua vez, recebe em um soh lugar os estado. Parte ruim de colocar tudo em um data class eh que eu preciso colocar alguns items como opcional Porem a gente ve que recebemos em apenas um lugar, um output igual a função matemática que a gente view. Uma unica fonte da verdade de onde vai chegar o meu state.
- Mutable live data
- Apenas 1 uma fonte de vdd na minha view
- O que aconteceria se eu tivesse isso como output? Opcionais mas eu to recebendo :/
- Nesse exemplo que aconteceu comigo eu tive o seguinte fluxo Recebi uma notificação como pode ver que ta com o marcador Abri a tela e recebi um empty state E meu loading ficou infinito Aqui podemos ver dois problemas 1 - Multiplos estados 2 - Estados nao estao sincronizados, pq eu consigo enviar meus novos estados mas na vdd nao deveria, pois isso ira gerar um estado estranho na minha view. Ja viu isso acontecer com algum app que vc usa?
- Vantagens e desvantagens de usar um data class único
- Podemos ver que agora minha classe virou um state, onde o model esta dentro do content, o valor que vem do repositorio sera inserido ali dentro. Nao vejo desvantagens, se alguém ve me fala depois quero saber de vdd :)
- Agora na minha view eu nao preciso mais tratar opcional, pq cada classe tem o seu campo. Porem a parte de sincronização ainda nao foi solucionada, eh ai que entra o MVI.
- Nao corrige o problema de sincronização Nada tecnicamente Assumir que posso enviar um novo estado sem saber qual estado ja foi enviado Notification e depois um empty???
- Ta tudo certo ai galera? Deu pra entender o problema que ficou em aberto? Vc ja parou pra pensar que rolam outros estados alem do viewModel na sua aplicação? 1 - Estado da sua requisição 2 - Estado da view model que estamos mais acostumados 3 - Estado da view, que embora a gente pense que eh o estado do view model por exemplo o loading, na vdd o estado da view se refere a view por si mesmo, como isEnable, isVisible, core de texto o próprio texto e outros muito possíveis estados que a view pode ter. Compose vai melhorar muito isso.
- Pra melhor exemplificar essa sincronização de estados, vou explicar sobre maquina de estados
- Jamais parado em cima do acabado
- Muitos apps tem os estados, mas a gente nao tem ideia da maquina de estado Isso tem que estar visível todo o tempo, principalmente quando vc vai alterar o código
- Evento e acoes sao coisas diferentes Evento = Intent do usuario ou do app em fazer algo Acao = Seria o trigger para um novo estado Acoes que nao podem acontecer de jeito nenhum
- Evento + Acao + Estado
- O que acontece nessa transição para garantir que eu posso enviar um estado de loading? Action Creator Reducer Guard
- Esse e o proximo slide são muito importantes pra vc entender o restante Se vc ta mexendo no celular, deixa de lado um pouquinho e foca aqui
- Classes Action = (Event) -> Action Reducer = (CurrentState, Action) -> NewState Guard = Boolean
- toState eh uma cadeia que recebe um evento do usuário e devolve o novo estado, lembrem desse nome toState pois vamos ver essa cadeia inteira no código escrito com flow. Falar q entende que eh o primeiro contato, vamos ver muito mais exemplos.
- Deixar claro que intent=event Varias coisas acontecem
- Uma mensagem importante para mostrar para o usuário esta na tela, ele esta lendo, nao posso sobrepor com um conteúdo
- Vamos dizer que temos um event do usuário, uma intent como a gente viu. No final isso ira refletir em um novo estado.
- Essa parte de concatenar eh um ganho muito grande
- Problema similar MVI + Flow ajuda
- Vamos imaginar o seguinte cenário Na minha view eu tenho 2 tipos eventos que podem acontecer distintivamente em momentos separados Vamos dar nome aos bois
- Regra no 2 Nunca vai descobrir
- Desabilitar Travar a tela Encerra comunicação Loading tempo, 15s? Pessima experiencia Informar, Cancelar
- Substituir Usar para contar 5s botao desabilitado esperando resultado???
- Bonito mas nao funciona N tratar eventos
- Agora temos a mesma situação mas com eventos enfileirados O MVI vai me ajudar muito com isso, principalmente com o flow.
- Como falei no começo o propósito dessa palestra eh que vc entenda a arquitetura MVI e para isso utilizaremos flow para construir um fluxo unidirecional. Antes de ver o fluxo inteiro do MVI gostaria de granular em pequenas partes que existem, para assim melhor entender o contexto geral de MVI. Debugavel
- Process mesmo tipo
- Action creator Reducer Guard
- Producer - emission Intermediary - transformação Consumer - coleta o dado
- Controla simultaneidade com fluxos Flows são COLD
- O que vamos ver agora eh o MVI tratando esses dois caras
- The flow builder is executed within a coroutine. Thus, it benefits from the same asynchronous APIs, but some restrictions apply: Flows are sequential. As the producer is in a coroutine, when calling a suspend function, the producer suspends until the suspend function returns. In the example, the producer suspends until the fetchLatestNews network request completes. Only then is the result emitted to the stream. With the flow builder, the producer cannot emit values from a different CoroutineContext. Therefore, don't call emit in a different CoroutineContext by creating new coroutines or by using withContext blocks of code. You can use other flow builders such as callbackFlow in these cases.
- Eh um dos operadores terminais do flow tais como single, reduce, toList e launchIn
- Na minha opniao nao vejo flow contra livedata ou vice versa. Os dois trabalham muito bem juntos no que sabem fazer de melhor Existem algumas maneiras de coletar flow na view, porem existem algumas diferenças e nao vou entrar nesse assunto agora Pra mim converter flow para livedata na view e observar ficou muito bem atrelado ao view scope LD hold value Sao diferentes
- Vamos falar que a gente quer enviar 1 + n eventos Por exemplo, enviar o loading e o resultado da minha api
- Rever
- Rever
- Stream/Criaçao de uma cadeia, ajudando muito no momento de enfileirar eventos
- Livedata com os intermediarios do flow para transformação
- Igual o state flow Quantas vezes emitir Bom para eventos
- Bagunça Como ta ai pessoal? ActionCreator, Reducer, Guard??
- + MVI Cadeia Exemplo Meu projeto
- SharedFlow event Channel State flow toState
- Falar sobre o process que vem da view os eventos Btn click 1 flow merge
- Curaçao Event -> State Cadeia
- Todos os eventos recebidos da view vao passar aqui
- Vou chamar meu action (Event) -> Action que sera executada pela view Increase = Evento Action = Executing/Success/Error
- (currentState,Action) -> NewState
- Logando quando completar Convertendo de flow para stateflow Dando o scope do viewmodel para sobreviver a rotação Lazily para enviar somente quando alguém estiver coletando E inicial estado Guard ta dentro do meu reducer
- Me de algum feedback, algo que talvez nao esta tao claro para eu mostrar agora no código. Roteiro do live code 1- setOnClickListenerFlow 2- Criar o evento Decrease 3 - implementar o btnDecrease 4 - Action Creator, deixar o TODO para ver o erro, depois implementar. 5 - CounterState 6 - Reducer 7 - Guard(Explicar o assert, mostrar o guard dando erro e fazer o catch do erro no view model nos próximos estados) 8 - View Model(View model fica bem genérico, fácil implementação) 9 - State view model(falar que pode ser mais granulado, ter um cara para despachar minhas acoes, chamar de store e etc) mostrar o chain linha por linha 10 - Testes Unitarios(runblocking os caras vão querer me matar haha) 11 - Testar o app 11.1 - Rotacao(1 evento rotaciona depois mais 1 evento) 11.2 - Mudar de app, falar sobre o render state
- Eu espero muito que vc conseguiu entender um pouco de MVI e seus benefícios. Nao estou aqui para falar que MVI eh a melhor arquitetura e seu código eh ruim, existem diferentes necessidades para diferentes casos. Tbm existem outras implementações para MVI, outras nomenclaturas e etc, faça do jeito que for melhor para o seu projeto.
- Pelo Mundo Associate Android Developer