Quais padrões de arquitetura são usados ​​no Android? [fechadas]

Estou fazendo uma pequena pesquisa em plataformas móveis e gostaria de saber quais padrões de design são usados ​​no Android?

por exemplo, no iOS, o Model-view-controller é muito usado em conjunto com delegação e outros padrões.

Quais padrões e onde, em particular, o Android usa?

EDITAR

Não estou solicitando padrões de design usados ​​profundamente no kernel, dalvik e assim por diante, mas sobre padrões que um desenvolvedor de aplicativos encontrará ao desenvolver um aplicativo.

Tentei usar os padrões de arquitetura model-view-controller (MVC) e model-view-apresentador para desenvolver o android. Minhas descobertas são de que o modelo-visualização-controlador funciona bem, mas existem alguns "problemas". Tudo se resume a como você percebe a Activityclasse Android . É um controlador ou é uma visão?

A Activityclasse real não estende a Viewclasse do Android , mas, no entanto, lida com a exibição de uma janela para o usuário e também com os eventos dessa janela (onCreate, onPause, etc.).

Isso significa que, quando você estiver usando um padrão MVC, seu controlador será realmente um pseudo-controlador de exibição. Como ele está manipulando a exibição de uma janela para o usuário, com os componentes de exibição adicionais adicionados a você com setContentView, e também manipulando eventos para pelo menos os vários eventos do ciclo de vida da atividade.

No MVC, o controlador deve ser o principal ponto de entrada. O que é um pouco discutível se esse for o caso ao aplicá-lo ao desenvolvimento do Android, pois a atividade é o ponto de entrada natural da maioria dos aplicativos.

Por isso, eu pessoalmente acho que o padrão de modelo-visualização-apresentador é o ajuste perfeito para o desenvolvimento do Android. Como o papel da visualização nesse padrão é:

• Servindo como ponto de entrada
• Componentes de renderização
• Roteando Eventos do Usuário para o Apresentador

Isso permite que você implemente seu modelo da seguinte maneira:

Ver - contém os componentes da interface do usuário e lida com eventos para eles.

Apresentador - isso manipulará a comunicação entre seu modelo e sua visualização, veja-a como uma porta de entrada para seu modelo. Ou seja, se você tem um modelo de domínio complexo representando, Deus sabe o que, e sua visão precisa apenas de um subconjunto muito pequeno desse modelo, o trabalho dos apresentadores é consultar o modelo e atualizar a visão. Por exemplo, se você tem um modelo que contém um parágrafo de texto, um título e uma contagem de palavras. Mas em uma determinada exibição, você só precisa exibir o título na exibição. Em seguida, o apresentador lerá os dados necessários no modelo e atualizará a visualização de acordo.

Modelo - este deve ser basicamente o seu modelo de domínio completo. Espero que ajude a tornar seu modelo de domínio mais "rígido" também, já que você não precisará de métodos especiais para lidar com casos, como mencionado acima.

Ao desacoplar o modelo da visualização todos juntos (através do uso do apresentador), também se torna muito mais intuitivo testar seu modelo. Você pode ter testes de unidade para o seu modelo de domínio e testes de unidade para seus apresentadores.

Experimente. Eu, pessoalmente, acho uma ótima opção para o desenvolvimento do Android.

Atualização novembro 2018

Depois de trabalhar e escrever blogs sobre MVC e MVP no Android por vários anos (veja o corpo da resposta abaixo), decidi capturar meu conhecimento e entendimento de uma forma mais abrangente e de fácil digestão.

Então, lancei um curso em vídeo completo sobre a arquitetura de aplicativos Android. Portanto, se você estiver interessado em dominar os padrões arquiteturais mais avançados no desenvolvimento do Android, confira este curso abrangente aqui .

Esta resposta foi atualizada para permanecer relevante em novembro de 2016

Parece que você está procurando padrões de arquitetura em vez de padrões de design .

Os padrões de design visam descrever um "truque" geral que o programador pode implementar para lidar com um conjunto específico de tarefas recorrentes de software. Por exemplo: No OOP, quando há a necessidade de um objeto notificar um conjunto de outros objetos sobre alguns eventos, o padrão de design do observador pode ser empregado.

Como os aplicativos Android (e a maioria do AOSP) são escritos em Java, que é orientado a objetos, acho que é difícil procurar um único padrão de design OOP que NÃO seja usado no Android.

Os padrões arquiteturais , por outro lado, não abordam tarefas específicas de software - eles visam fornecer modelos para a organização de software com base nos casos de uso do componente de software em questão.

Parece um pouco complicado, mas espero que um exemplo esclareça: Se algum aplicativo for usado para buscar dados de um servidor remoto e apresentá-los ao usuário de maneira estruturada, o MVC poderá ser um bom candidato a ser considerado. Observe que eu não disse nada sobre tarefas de software e fluxo de programa do aplicativo - acabei de descrevê-lo do ponto de vista do usuário e surgiu um candidato a um padrão arquitetural.

Como você mencionou o MVC em sua pergunta, eu acho que os padrões arquiteturais são o que você está procurando.

Historicamente, não havia diretrizes oficiais do Google sobre arquiteturas de aplicativos, o que (entre outros motivos) levou a uma bagunça total no código-fonte dos aplicativos Android. De fato, ainda hoje a maioria dos aplicativos que eu vejo ainda não segue as práticas recomendadas de OOP e não mostra uma organização lógica clara do código.

Hoje, porém, a situação é diferente - o Google lançou recentemente a biblioteca Data Binding , totalmente integrada ao Android Studio e, inclusive, lançou um conjunto de projetos de arquitetura para aplicativos Android .

Dois anos atrás, era muito difícil encontrar informações sobre MVC ou MVP no Android. Hoje, MVC, MVP e MVVM se tornaram "palavras-chave" na comunidade Android, e estamos cercados por inúmeros especialistas que constantemente tentam nos convencer de que o MVx é melhor que o MVy. Na minha opinião, discutir se o MVx é melhor que o MVy é totalmente inútil, porque os termos em si são muito ambíguos - basta olhar para as respostas a essa pergunta e você perceberá que pessoas diferentes podem associar essas abreviações a construções completamente diferentes.

Devido ao fato de ter sido oficialmente iniciada uma busca pelo melhor padrão arquitetural para Android, acho que estamos prestes a ver várias outras idéias surgindo. Nesse ponto, é realmente impossível prever quais padrões (ou padrões) se tornarão os padrões do setor no futuro - precisaremos esperar e ver (acho que é questão de um ano ou dois).

No entanto, há uma previsão que posso fazer com um alto grau de confiança: O uso da biblioteca de Ligação de Dados não se tornará um padrão do setor. Estou confiante em dizer isso porque a biblioteca Data Binding (em sua implementação atual) fornece ganhos de produtividade a curto prazo e algum tipo de diretriz de arquitetura, mas tornará o código não sustentável a longo prazo. Depois que os efeitos a longo prazo desta biblioteca surgirem, ela será abandonada.

Agora, embora tenhamos hoje algum tipo de diretrizes e ferramentas oficiais, eu, pessoalmente, não acho que essas diretrizes e ferramentas sejam as melhores opções disponíveis (e elas definitivamente não são as únicas). Nos meus aplicativos, uso minha própria implementação de uma arquitetura MVC. É simples, limpo, legível e testável, e não requer nenhuma biblioteca adicional.

Esse MVC não é apenas cosmeticamente diferente dos outros - é baseado em uma teoria de que as atividades no Android não são elementos da interface do usuário , o que tem tremendas implicações na organização do código.

Portanto, se você estiver procurando por um bom padrão de arquitetura para aplicativos Android que siga os princípios do SOLID , poderá encontrar uma descrição de uma no meu post sobre padrões de arquitetura MVC e MVP no Android .

Quando chego a este post, ele realmente me ajuda a entender padrões com exemplo, por isso criei a tabela abaixo para ver claramente os padrões de Design e seu exemplo no Android Framework

Espero que você ache útil.

• Alguns links úteis para referência:
  

  1. Padrões de design comuns para Android com Kotlin

  2. Introdução aos padrões de design do Android

  3. Padrões de design

Existem vários padrões usados ​​na estrutura do Android, como:

• O receptor de transmissão usa o padrão Observer
• A chamada de serviço do Remoter usa o padrão Proxy
• Exibir e exibir grupos usa padrão Composto
• A estrutura de mídia usa o padrão Facade

Aqui está um ótimo artigo sobre Common Design Patterns para Android :

Padrões criacionais:

• Construtor (por exemplo, AlertDialog.Builder )
• Injeção de Dependência (por exemplo, Adaga 2 )
• Singleton

Padrões estruturais:

• Adaptador (por exemplo, RecyclerView.Adapter )
• Fachada (por exemplo, Retrofit )

Padrões comportamentais:

• Comando (por exemplo, EventBus )
• Observador (por exemplo, RxAndroid )
• Model View Controller
• Model View ViewModel ( semelhante ao padrão MVC acima )

As seguintes classes do Android usam padrões de design

1) View Holder usa Singleton Design Pattern

2) Intenção usa Padrão de Design de Fábrica

3) O adaptador usa o Padrão de Design do Adaptador

4) O Broadcast Receiver usa o Observer Design Pattern

5) View usa Composite Design Pattern

6) O Media FrameWork usa o Padrão de design de fachada

No caso Notificações , o Padrão do ConstrutorNotificationCompat.Builder usa

gostar,

mBuilder = new NotificationCompat.Builder(this)
                    .setSmallIcon(R.drawable.ic_stat_notification)
                    .setContentTitle(getString(R.string.notification))
                    .setContentText(getString(R.string.ping))
                    .setDefaults(Notification.DEFAULT_ALL);

O Android também usa o padrão de design do ViewHolder.

É usado para melhorar o desempenho de um ListView enquanto o rola.

O padrão de design do ViewHolder permite acessar cada exibição de item de lista sem a necessidade de pesquisa, economizando valiosos ciclos do processador. Especificamente, evita chamadas freqüentes de findViewById () durante a rolagem do ListView, e isso facilitará.

Todos esses padrões, MVC, MVVM , MVP e modelo de apresentação , podem ser aplicados a aplicativos Android, mas sem uma estrutura de terceiros, não é fácil obter uma estrutura bem organizada e um código limpo.

O MVVM é originário do PresentationModel. Quando aplicamos MVC, MVVM e 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ê geralmente 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.

Gostaria de adicionar um padrão de design que foi aplicado no Android Framework. Esse é o padrão Half Sync Half Async usado na implementação do Asynctask. Veja minha discussão em

https://docs.google.com/document/d/1_zihWXAwgTAdJc013-bOLUHPMrjeUBZnDuPkzMxEEj0/edit?usp=sharing

No Android, o padrão "processador da fila de trabalho" é comumente usado para descarregar tarefas do encadeamento principal de um aplicativo.

Exemplo: O design da classe IntentService.

O IntentService recebe os Intents, inicia um thread de trabalho e interrompe o serviço conforme apropriado. Todas as solicitações são tratadas em um único thread de trabalho.

O Fichário usa "Padrão do Observador" para notificações de Destinatário da Morte.