É possível implementar o padrão model-view-controller em Java para Android?
Ou já está implementado por meio de atividades? Ou existe uma maneira melhor de implementar o padrão MVC para Android?
É possível implementar o padrão model-view-controller em Java para Android?
Ou já está implementado por meio de atividades? Ou existe uma maneira melhor de implementar o padrão MVC para Android?
Respostas:
No Android, você não possui MVC, mas possui o seguinte:
Não há um padrão MVC universalmente exclusivo. MVC é um conceito e não uma estrutura de programação sólida. Você pode implementar seu próprio MVC em qualquer plataforma. Contanto que você se atenha à seguinte idéia básica, estará implementando o MVC:
Pense também desta maneira: quando você programa seu modelo, ele não precisa se preocupar com a renderização (ou código específico da plataforma). O modelo diria para a visualização: não me importo se sua renderização for Android ou iOS ou Windows Phone, é isso que preciso que você renderize. A visualização trataria apenas o código de renderização específico da plataforma.
Isso é particularmente útil quando você usa o Mono para compartilhar o modelo e desenvolver aplicativos de plataforma cruzada.
As ações, visualizações e atividades no Android são a maneira prática de trabalhar com a UI do Android e são uma implementação do padrão MVVM (model-view-viewmodel) , que é estruturalmente semelhante (na mesma família que) à visualização de modelo -controlador.
Que eu saiba, não há como sair desse modelo. Provavelmente, isso pode ser feito, mas você provavelmente perderia todos os benefícios que o modelo existente possui e teria que reescrever sua própria camada de interface do usuário para fazê-lo funcionar.
Após algumas pesquisas, a resposta mais razoável é a seguinte:
O MVC já está implementado no Android como:
Button
internas como derivadas android.view.View
.(A propósito, isso não implica lógica de domínio de aplicativo na atividade.)
O mais razoável para um pequeno desenvolvedor é seguir esse padrão e não tentar fazer o que o Google decidiu não fazer.
PS Observe que, às vezes, a atividade é reiniciada, portanto, não há lugar para os dados do modelo (a maneira mais fácil de causar uma reinicialização é omitir android:configChanges="keyboardHidden|orientation"
o XML e ativar o dispositivo).
EDITAR
Podemos estar falando sobre MVC , mas será o caso de FMVC , Framework - Model - View - Controller . O Framework (o sistema operacional Android) impõe sua idéia do ciclo de vida dos componentes e eventos relacionados e, na prática, o Controller ( Activity
/ Service
/ BroadcastReceiver
) é o primeiro responsável por lidar com esses eventos impostos pelo Framework (como onCreate () ). A entrada do usuário deve ser processada separadamente? Mesmo que deva, você não pode separá-lo, os eventos de entrada do usuário também vêm do Android.
De qualquer forma, quanto menos código não for específico do Android você colocar no seu Activity
/ Service
/ BroadcastReceiver
, melhor.
Button
conhecedor do Controlador ? Parece mais lógico que o Views saiba apenas sobre a exibição de coisas. E levando em conta que o Model conhece apenas a natureza dos dados, é por isso que o Controller é necessário: algo deve conhecer tanto o Model quanto a View .
Service
s estão sob a égide do controlador também
Não há um padrão único de MVC ao qual você possa obedecer. O MVC apenas afirma mais ou menos que você não deve misturar dados e visualizações, de modo que, por exemplo, as visualizações sejam responsáveis por manter dados ou classes que estão processando dados, afetando diretamente a visualização.
Mas, no entanto, da maneira como o Android lida com classes e recursos, às vezes você é forçado a seguir o padrão MVC. Mais complicadas, na minha opinião, são as atividades que às vezes são responsáveis pela visão, mas, no entanto, atuam como controladoras ao mesmo tempo.
Se você definir suas visualizações e layouts nos arquivos XML, carregue seus recursos da pasta res e se evitar mais ou menos misturar essas coisas no seu código, estará seguindo um padrão MVC.
Você pode implementar o MVC no Android, mas ele não é "suportado nativamente" e exige algum esforço.
Dito isso, eu pessoalmente tendem ao MVP como um padrão arquitetural muito mais limpo para o desenvolvimento do Android. E dizendo MVP, quero dizer o seguinte:
Também publiquei uma resposta mais detalhada aqui .
Depois de brincar com as várias abordagens para a implementação do MVC / MVP no Android, criei um padrão de arquitetura razoável, que descrevi neste post: MVP e MVC Architectural Patterns no Android .
O melhor recurso que encontrei para implementar o MVC no Android é este post :
Eu segui o mesmo design para um dos meus projetos e funcionou muito bem. Eu sou iniciante no Android, então não posso dizer que esta é a melhor solução.
Fiz uma modificação: instanciei o modelo e o controlador para cada atividade na classe de aplicativo para que eles não sejam recriados quando o modo paisagem-retrato é alterado.
Eu concordo com o JDPeckham e acredito que apenas o XML não é suficiente para implementar a parte da interface do usuário de um aplicativo.
No entanto, se você considerar a Atividade como parte da visualização, a implementação do MVC é bastante direta. Você pode substituir o Aplicativo (conforme retornado por getApplication () na Atividade) e é aqui que você pode criar um controlador que sobrevive por toda a vida útil do seu aplicativo.
(Como alternativa, você pode usar o padrão singleton conforme sugerido pela documentação do aplicativo)
Arquitetura MVC- no Android É melhor seguir qualquer MVP do que MVC no Android. Mas ainda de acordo com a resposta à pergunta, isso pode ser solução
Descrição e Diretrizes
Controller -
Activity can play the role.
Use an application class to write the
global methods and define, and avoid
static variables in the controller label
Model -
Entity like - user, Product, and Customer class.
View -
XML layout files.
ViewModel -
Class with like CartItem and owner
models with multiple class properties
Service -
DataService- All the tables which have logic
to get the data to bind the models - UserTable,
CustomerTable
NetworkService - Service logic binds the
logic with network call - Login Service
Helpers -
StringHelper, ValidationHelper static
methods for helping format and validation code.
SharedView - fragmets or shared views from the code
can be separated here
AppConstant -
Use the Values folder XML files
for constant app level
NOTA 1:
Agora, aqui está a peça de mágica que você pode fazer. Depois de classificar o trecho de código, escreva uma classe de interface básica como IEntity e IService. Declarar métodos comuns. Agora crie a classe abstrata BaseService e declare seu próprio conjunto de métodos e faça uma separação de código.
NOTA 2: Se sua atividade estiver apresentando vários modelos, em vez de escrever o código / lógica na atividade, é melhor dividir as visualizações em fragmentos. Então é melhor. Portanto, no futuro, se for necessário exibir mais modelo na exibição, adicione mais um fragmento.
NOTA 3: A separação do código é muito importante. Todo componente da arquitetura deve ser independente, sem lógica dependente. Se por acaso você tiver alguma lógica dependente, escreva uma classe de lógica de mapeamento no meio. Isso o ajudará no futuro.
A criação da interface do usuário do Android usando layouts, recursos, atividades e intenções é uma implementação do padrão MVC. Consulte o link a seguir para obter mais informações sobre isso - http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf
O padrão MVC do Android é (mais ou menos) implementado com suas classes de adaptadores . Eles substituem um controlador por um "adaptador". A descrição para o adaptador declara:
Um objeto Adapter atua como uma ponte entre um AdapterView e os dados subjacentes para essa exibição.
Estou apenas pesquisando isso para um aplicativo Android que lê de um banco de dados, então ainda não sei como ele funciona. No entanto, parece um pouco com a arquitetura Model-View-Delegate da Qt, que eles afirmam ser um passo acima do padrão tradicional do MVC. Pelo menos no PC, o padrão do Qt funciona bastante bem.
Embora este post pareça antigo, gostaria de adicionar os dois a seguir para informar sobre o desenvolvimento recente nessa área para Android:
android-binding - Fornece uma estrutura que enraíza a ligação dos widgets da visualização android ao modelo de dados. Ajuda a implementar padrões MVC ou MVVM em aplicativos Android.
roboguice - o RoboGuice elimina as suposições do desenvolvimento. Injete seu modo de exibição, recurso, serviço do sistema ou qualquer outro objeto e deixe o RoboGuice cuidar dos detalhes.
Descrição:
O padrão MVC é essencialmente este:
Recurso importante do MVC: Podemos modificar o modelo, a visualização ou o controlador ainda não afetando os outros
Eu acho que a explicação simplificada mais útil está aqui: http://www.cs.otago.ac.nz/cosc346/labs/COSC346-lab2.2up.pdf
De tudo o que vi e li aqui, implementar todas essas coisas torna mais difícil e não se encaixa bem com outras partes do Android.
Ter uma atividade implementando outros ouvintes já é a maneira padrão do Android. A maneira mais inofensiva seria adicionar o Java Observer como os slides descrevem e agrupar o onClick e outros tipos de ações em funções que ainda estão na Atividade.
A maneira do Android é que a Atividade faça as duas coisas. Lutar contra isso não facilita a extensão ou a codificação futura.
Eu concordo com o segundo post . Já está implementado, mas não do jeito que as pessoas estão acostumadas. Esteja ou não no mesmo arquivo ou não, já existe separação. Não é necessário criar uma separação extra para ajustá-lo a outros idiomas e sistemas operacionais.
Foi surpreendente ver que nenhuma das postagens aqui respondeu à pergunta. Eles são muito gerais, vagos, incorretos ou não abordam a implementação no Android.
No MVC, a camada Exibir sabe apenas como mostrar a interface do usuário (UI). Se algum dado for necessário para isso, ele será obtido na camada Modelo . Mas o View NÃO solicita diretamente ao modelo que encontre os dados, ele o faz através do Controller . Portanto, o Controlador chama o Modelo para fornecer os dados necessários para a Visualização . Quando os dados estiverem prontos, o Controlador informará à Visualização que os dados estão prontos para serem adquiridos do Modelo . Agora o View pode obter os dados do modelo .
Esse fluxo pode ser resumido como abaixo:
É importante notar que o View pode saber sobre a disponibilidade dos dados no Modelo através do Controller - também conhecido como Passive MVC - ou observando os dados no Model registrando observáveis nele, que é o Active MVC .
Na parte de implementação, uma das primeiras coisas que vem à mente é que qual componente do Android deve ser usado para o View ? Activity
ou Fragment
?
A resposta é que isso não importa e ambos podem ser usados. O modo de exibição deve poder apresentar a interface do usuário (UI) no dispositivo e responder à interação do usuário com a interface do usuário. Ambos Activity
e Fragment
fornecem os métodos necessários para isso.
No aplicativo de exemplo usado neste artigo , usei Activity
a camada View , mas Fragment
também pode ser usada.
O aplicativo de exemplo completo pode ser encontrado na ramificação 'mvc' do meu repositório GitHub aqui .
Eu também lidei com os prós e contras da arquitetura MVC no Android através de um exemplo aqui .
Para os interessados, eu comecei uma série de artigos sobre arquitetura android aplicativo aqui em que eu comparar as diferentes arquiteturas, ou seja, MVC, MVP, MVVM, para desenvolvimento de aplicativos Android através de um aplicativo de trabalho completo.
Cansado do desastre do MVx no Android, criei recentemente uma pequena biblioteca que fornece fluxo de dados unidirecional e é semelhante ao conceito de MVC: https://github.com/zserge/anvil
Basicamente, você tem um componente (atividade, fragmento e grupo de visualizações). Dentro de você define a estrutura e o estilo da camada de vista. Além disso, você define como os dados devem ser vinculados às visualizações. Por fim, você pode vincular ouvintes no mesmo local.
Depois, quando seus dados forem alterados - o método global "render ()" será chamado e suas visualizações serão atualizadas de maneira inteligente com os dados mais recentes.
Aqui está um exemplo do componente que tem tudo para compactação de código (é claro que Model e Controller podem ser facilmente separados). Aqui "count" é um modelo, o método view () é uma view e "v -> count ++" é um controlador que escuta o botão clica e atualiza o modelo.
public MyView extends RenderableView {
public MyView(Context c) {
super(c);
}
private int count = 0;
public void view() {
frameLayout(() -> { // Define your view hierarchy
size(FILL, WRAP);
button(() -> {
textColor(Color.RED); // Define view style
text("Clicked " + count); // Bind data
onClick(v -> count++); // Bind listeners
});
});
}
Com o modelo e o controlador separados, seria semelhante a:
button(() -> {
textColor(Color.RED);
text("Clicked " + mModel.getClickCount());
onClick(mController::onButtonClicked);
});
Aqui em cada botão, o número será aumentado, então "render ()" será chamado e o texto do botão será atualizado.
A sintaxe se torna mais agradável se você usar o Kotlin: http://zserge.com/blog/anvil-kotlin.html . Além disso, há uma sintaxe alternativa para Java sem lambdas.
A biblioteca em si é muito leve, não possui dependências, não usa reflexão, etc.
(Aviso: sou o autor desta biblioteca)
De acordo com a explicação que a equipe do Xamarin explicou (no iOS MVC "eu sei que parece estranho, mas espere um segundo"):
Eu posso dizer o seguinte:
O modelo no Android é simplesmente o objeto parcelável. A visualização é o layout XML e o controlador é a (atividade + seu fragmento).
* Esta é apenas a minha opinião, não de qualquer recurso ou livro.
Não existe uma arquitetura MVC implementada, mas existe um conjunto de bibliotecas / exemplos para implementar uma arquitetura MVP (model-view-apresentador).
Por favor, verifique estes links:
O Google adicionou um exemplo de MVP de arquitetura Android:
Vi que muitas pessoas estão dizendo que o MVC já está implementado no Android, mas não é verdade. O Android não segue MVC por padrão.
Como o Google nunca impõe com força as restrições de uma implementação MVC como o iPhone, mas depende dos desenvolvedores quais padrões ou técnicas eles desejam em seu projeto. Em aplicativos pequenos ou simples, o uso do MVC não é necessário, mas como o aplicativo cresce e se torna complicado e exige modificações de seu código nos últimos anos, então é necessário o padrão MVC no Android.
Ele fornece uma maneira fácil de modificar o código e também ajuda na redução de problemas. Se você deseja implementar o MVC no Android, siga este link abaixo e aproveite a implementação do MVC em seu projeto.
http://www.therealjoshua.com/2011/11/android-architecture-part-1-intro/
Mas hoje em dia acho que o MVP, juntamente com o Android Architectural Pattern, é uma das melhores opções que os desenvolvedores devem usar para aplicativos Android limpos e robustos.
Quando aplicamos o MVC, MVVM ou Modelo de Apresentação a um aplicativo Android, o que realmente queremos é ter um projeto estruturado claro e, mais importante, mais fácil para testes de unidade.
No momento, sem uma estrutura de terceiros, você normalmente possui muitos códigos (como addXXListener (), findViewById () etc.), que não agregam valor comercial.
Além disso, você precisa executar testes de unidade Android em vez de testes JUnit normais, que levam anos para serem executados e tornam os testes unitários um pouco impraticáveis. Por esses motivos, alguns anos atrás, começamos um projeto de código aberto, RoboBinding - Uma estrutura de modelo de apresentação de ligação de dados para a plataforma Android.
O RoboBinding ajuda a escrever um código de interface do usuário mais fácil de ler, testar e manter. O RoboBinding elimina a necessidade de código desnecessário, como o addXXListener , e muda a lógica da interface do usuário para o Presentation Model, que é um POJO e pode ser testado através de testes JUnit normais . O próprio RoboBinding vem com mais de 300 testes JUnit para garantir sua qualidade.
No meu entendimento, a maneira como o Android lida com o padrão MVC é como:
Você tem uma atividade, que serve como controlador. Você tem uma classe cuja responsabilidade é obter os dados - o modelo e, em seguida, a classe View, que é a visualização.
Ao falar sobre a visualização, a maioria das pessoas pensa apenas na parte visual definida no xml. Não devemos esquecer que o View também possui uma parte do programa com seus construtores, métodos e etc, definidos na classe java.