
O MVC é uma abordagem limpa no Android, guardando vistas do controlador. O controlador é responsável apenas pela atualização dos modelos, depois que o modelo é atualizado, ele pode notificar as visualizações e, em seguida, a visualização pode ser atualizada usando retornos de chamada adequados. MVC tradicional é onde há um
Modelo : atua como o modelo para dados
Visualização : lida com a visão do usuário, o que pode ser a interface do usuário
Controlador : controla a interação entre modelo e visualização, onde a exibição chama o controlador para atualizar o modelo. Uma visualização pode chamar vários controladores, se necessário ..
Algumas desvantagens do MVC podem ser superadas usando a abordagem MVP. O apresentador no MVP contém toda a lógica de negócios e essa classe está longe do contexto do Android ou dependências relacionadas ao Android, que fornecem flexibilidade para enviar a lógica de negócios simplesmente usando a classe de apresentador nos módulos de teste. Dependências relacionadas ao Android criam complexidade nos testes. O apresentador não possui nenhuma dependência do Android, como contexto, visualização etc. e todas as atualizações do modelo e solicitações de rede são feitas via apresentador. Depois que o modelo é atualizado ou uma solicitação de rede é concluída, a visualização é atualizada via apresentador usando retornos de chamada para visualizar do apresentador. Nenhuma solicitação de modelo e rede pode abordar diretamente as visualizações.
O MVVM envolve uma abordagem de ligação de dados para diminuir o código e reduzir o código de manuseio de visualização das classes Java. Os modelos de visualização são responsáveis por atualizar a visualização e, uma vez que um modelo de visualização esteja vinculado a uma visualização, seja notificado sobre seus eventos de atualização. Se um modelo for atualizado por um usuário, clique em Modelo, envie retornos de chamada para visualizar o modelo que atualizam a exibição automaticamente à medida que ela é vinculada às visualizações. O MVVM reduz o tamanho do código, mas a implementação do MVVM é bastante difícil e é difícil depurar grandes projetos com base no MVVM.


?
A escolha de uma arquitetura correta para o projeto envolve a compreensão dos módulos que precisam ser desenvolvidos. Algumas funcionalidades funcionam muito bem no MVC, outras com MVP e outras com MVVM. É muito difícil depurar os projetos feitos no MVVM, especialmente aqueles que não possuem fluxo de dados unilaterais devido à ligação de dados e dados ao vivo. Se um aplicativo receber um fluxo de dados contínuo de uma fonte, precisar de uma atualização regular da interface do usuário e possui maior (80-90%) de comunicação unilateral (por exemplo: um dispositivo eletrônico enviando logs para um aplicativo Android), como aplicativos de células solares, aplicativos de inversores ou o monitoramento de status de qualquer outro dispositivo pode funcionar bem com MVV devido a dados ao vivo -atualizações de dados da UI. A depuração desses aplicativos MVVM pode ser fácil, pois o grande fluxo de dados é unilateral .
O MVP é uma boa abordagem para escrever projetos do Android quando estamos preocupados em testar os testes de unidade WRT da lógica de negócios via Java Test Frameworks (não Android). Como a estrutura de teste Java resolverá apenas as dependências Java e uma camada de apresentador limpa é livre de dependências relacionadas ao Android, como contexto, SharedPreferences ou qualquer outro com.android. * pacote. A desvantagem do MVP é que ele acaba escrevendo 20-25% de código extra com a mesma funcionalidade escrita em MVC ou MVVM. O MVP é bom se você estiver realmente interessado em casos de teste e no teste de unidade de módulos. Para o MVP usando kits de teste Java, basta criar a instância do apresentador e executar funções de teste.
Por exemplo: novo apresentador (). TestsomeFunction () .
O MVC é uma técnica amplamente utilizada no Android. O próprio Google escreveu seus repositórios no MVC por muitos anos. Hoje em dia, o Google está adotando o MVVM para os repositórios do GitHub, pois esses repositórios são pequenos e são as amostras. O aplicativo MVC pode ser testado através de estruturas de teste Android, não com ferramentas de teste específicas de Java devido à falta de dependências do com.android. * Pacotes na ferramenta específica de Java.
Exemplo :
NOTA : Não existe uma arquitetura única que seja o melhor de tudo. Se houvesse um, não haveria necessidade de aprender outras arquiteturas. A escolha da arquitetura correta depende de vários fatores, como requisitos iniciais, fluxo de dados, escalabilidade, manutenção, atualizações (CRS), requisitos de teste.
Exceto essas três arquiteturas Android, há mais uma arquitetura chamada "MVI - Model View Intent". Isso não é muito popular entre os desenvolvedores do Android. Por favor, verifique este link se você estiver interessado no MVI .
https://github.com/saksham24/android-simple-mvi-pattern-with-mvp-mvvm-colaboration