Introdução
Nesta leitura, exploramos como criar, gerenciar e evoluir dependências em aplicações móveis usando padrões de injeção de dependência (DI) e IoC. A conversa aborda desde a história das opções disponíveis no ecossistema .NET para mobile até um exemplo prático de trocar uma implementação de agendamento (Chronos) por outra (NCRON Tab) sem mexer na lógica de negócio. O objetivo é mostrar que, mesmo em cenários móveis, onde lifecycles e concorrência importam, é possível manter o código flexível, testável e com menor acoplamento.
Resumo
- O vídeo começa discutindo as dificuldades históricas do mobile com DI: a ausência de um contêiner de injeção de dependências robusto, o uso de service locator e a ênfase nos lifecycles. A ideia central é que, no mobile, o ciclo de vida das telas e a necessidade de criar novas instâncias (transient) fazem o uso de certos padrões fazer sentido para manter o app estável e previsível. A conversa também menciona a diferença entre plataformas (Android vs iOS) e como isso influencia decisões de design, incluindo a observação de que a startup angle entre as plataformas nem sempre é o fator determinante; o que vale é entender os lifecycles e as necessidades de isolamento de componentes.
- Em seguida, é apresentado um scaffold de aplicativo onde serviços básicos, como conectividade e info do dispositivo, são registrados como dependências, com foco em injetar implementações da camada Essentials (ou a evolução para MA). O uso de transients para registrar telas (páginas) e view models é discutido, reforçando a ideia de que abrir uma nova tela implica novas instâncias. O diálogo também ressalta que isolar as implementações facilita testes de unidade e futuras mudanças de implementação sem tocar na lógica de negócio.
- O debate aprofunda o tema de abstração: mesmo quando o código usa extensões do framework, manter interfaces para as dependências permite mudar a implementação por motivos de teste, refatoração ou substituição de bibliotecas, sem impacto direto no restante do código. Isso leva ao conceito de Open/Closed (Open/Closed Principle) aplicado a DI: o sistema pode evoluir mantendo contratos estáveis.
- A parte prática culmina na demonstração de trocar Chronos (uma biblioteca de cron/tempo) por NCRON Tab. O apresentador mostra como criar uma implementação que segue o mesmo contrato (interface) e como ajustar a expressão de recorrência para se adaptar aos dois formatos. A mensagem central é que, com DI, basta registrar a nova implementação e o contêiner resolve o restante, permitindo evoluir a aplicação sem refatoração massiva. O diálogo encerra com reflexões sobre futuras integrações (por exemplo, Open Telemetry) e a importância de manter o código aberto para mudanças futuras.
Opinião e Análise
Sem opiniões explícitas no vídeo.
Insights e Pontos Fortes
- Em mobile, registrando view models/views como transit, garantimos que cada tela tenha seu estado isolado, facilitando a compreensão do fluxo de navegação e o debugging.
- Isolar dependências (ex.: conectividade, device info) por meio de interfaces facilita testes de unidade e permite substituir implementações sem impactar a lógica de negócio.
- A troca de bibliotecas (Chronos ↔ NCRON Tab) mostra o poder da DI: mudar a implementação concreta sem alterar o contrato ou o restante do código, acelerando evoluções técnicas.
- O Open/Closed Principle aparece como guardião da evolução: com contratos bem definidos, você estende o comportamento sem tocar nas classes existentes.
- Em cenários mobile com concorrência e multitarefa, usar padrões de injeção e escopos apropriados ajuda a evitar condições de corrida e estados compartilhados entre componentes.