Uma típica aplicação para dispositivo móvel – App – tem, em geral, uma configuração cliente-servidor em uma estrutura de múltiplas camadas, sendo geralmente apresentada de negócios e de serviços de dados, semelhante às aplicações de sistemas desktop. Qual a afirmação correta sobre as APPs?

Alternativa D

Análise Detalhada

A questão aborda conceitos fundamentais de arquitetura de software para dispositivos móveis, especificamente sobre camadas de aplicação, tipos de clientes e otimização de rede.

Por que a Alternativa D é correta?

Em ambientes móveis, a eficiência é um recurso escasso (bateria, CPU, memória). Protocolos de comunicação modernos (como HTTP/2, gRPC ou MQTT) são projetados para otimizar exatamente esses fatores:

• Velocidade: Redução de latência na troca de dados.
• Consumo de energia: Menos tempo de rádio ligado significa menos gasto de bateria.
• Granularidade: Troca de dados menores e mais precisos (ex: JSON vs XML, formatos binários).

Mesmo com boa largura de banda, essas otimizações são essenciais para garantir uma experiência fluida e duradoura do dispositivo.

Por que as outras estão incorretas?

• Alternativa A (Incorreta): Viola o princípio de Separação de Responsabilidades (Single Responsibility Principle). Em uma arquitetura de múltiplas camadas (ex: MVC ou N-Tier):
• A camada de Apresentação cuida da Interface do Usuário (UI).
• A camada de Lógica de Negócios cuida das regras e processos.
• Misturar essas funções torna o sistema difícil de manter e testar.
• Alternativa B (Incorreta): Embora muitos apps compartilhem o mesmo backend (servidor), eles não são compatíveis entre si em nível de aplicação. Um aplicativo feito para Android (.apk) não roda nativamente em um Desktop Windows, pois possuem sistemas operacionais e interfaces diferentes.
• Alternativa C (Incorreta): Há uma inversão conceitual aqui.
• Thin Client (Cliente Fino): Depende quase inteiramente do servidor para processamento. Falha sem conexão.
• Thick Client (Cliente Grosso): Realiza processamento local e armazena dados no dispositivo. É o modelo ideal para cenários offline ou intermitentes.
• Alternativa E (Incorreta): É uma generalização perigosa. Mesmo aplicativos que funcionam "stand alone" (offline) geralmente precisam de mecanismos para lidar com sincronização, atualizações de licença ou configurações iniciais, o que envolve preocupação com problemas de conexão.

Conclusão

A alternativa D é a única que descreve corretamente as boas práticas de engenharia de software para ambientes móveis, focando na otimização de recursos de rede e energia através de protocolos adequados.