Há uns dias atrás me questionei sobre o uso do MVC no desenvolvimento de uma aplicação Android, pois percebi que a forma como eu e muitos outros programadores temos usado esse padrão está conceitualmente errado. Uma das classes principais, se não posso ser ousado ao dizer que é a mais importante, a Activity, torna o MVC inviável no desenvolvimento Android. Deixe-me explicar melhor. O entry-point ou a primeira camada que o usuário terá contato para iniciar um processo em um software segundo o MVC é o Controller, e se formos olhar para a estrutura do Android, a classe que estaria atuando no entry-point seria a Activity. Sendo assim, obrigatoriamente, pelo conceito de MVC, a Activity deve atuar como Controller. Porém, em um desenvolvimento Android, lidamos com ListViews, Fragments e outras classes que resultam em elementos visuais e que são classes que normalmente serão manipuladas pelas Activities.
As activities podem trocar os fragments exibidos ao virar a tela, tornando a aplicação mais dinâmica e muito comum em Tablets, e muitas atuações que são destinadas a View. Temos a classe Activity lidando o tempo todo com a parte lógica do processo ao mesmo tempo de estar se envolvendo com a criação das views, projeção e posicionamento de fragments e etc. O que eu quero dizer é que a Activity, obrigatoriamente um Controller no MVC devido ao conceito desse padrão, acaba atuando também como View por imposição da API, sendo assim inviável.
Temos uma disputa da imposição da API vs obrigação conceitual. Sendo assim, comecei a pesquisar e a acreditar que o MVP seria uma melhor padrão no desenvolvimento, já que o entry-point no MVP é a camada View, sendo perfeito que as Activities atuem como Views, criando classes separadas para atuarem como Presenter sem problema algum. Sendo assim, é mais fácil negar o conceito do padrão, ao não usá-lo, do que ir contrário as imposições da API.
Tássio Auad 