Getnet DocsGetnet Docs

Entendendo o Padrão Repository

View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page
Connect to CursorUse these docs in CursorConnect to VS CodeUse these docs in VS Code

O Get Smart SDK (redsys-tpv-business-lib) é projetado em torno do Padrão Repository, um padrão essencial no desenvolvimento Android moderno que se integra naturalmente em projetos MVVM e Clean Architecture.

Em vez de expor chamadas de serviço de baixo nível diretamente para suas Activities ou Fragments, o SDK agrupa as operações em interfaces de repositório focadas (ex: InitializationRepository, PaymentRepository, RefundRepository, TransactionRepository).

Arquitetura de Alto Nível

O repositório atua como uma camada de abstração segura entre sua aplicação e o Get Smart SDK Payment Service (o serviço de segundo plano executado no dispositivo).

Em alto nível, cada repositório:

  • Encapsula toda a comunicação com o Get Smart SDK Payment Service instalado no dispositivo.
  • Expõe funções suspend do Kotlin que sempre retornam um wrapper RepositoryResult<T>.
  • Move automaticamente a execução para o Dispatchers.IO, mantendo sua thread principal livre de operações de E/S bloqueantes.
  • Mantém sua camada de UI e UseCases independentes da implementação subjacente.

Benefícios para sua arquitetura

O uso de repositórios desta forma oferece várias vantagens concretas:

  • Desacoplamento: Seu app depende apenas das interfaces dos repositórios (contratos), não das classes de implementação concretas ou do protocolo do serviço.
  • Pronto para Injeção de Dependência: Os repositórios são projetados para serem fornecidos como singletons via Dagger Hilt (ou manualmente via RepositoryProvider), mantendo a raiz de composição do seu projeto limpa.
  • Testabilidade: Como o SDK é baseado em interfaces, você pode facilmente substituir os repositórios reais por fakes ou mocks em seus testes unitários, sem precisar de um TPV físico ou do Serviço de Pagamento.
  • Segurança de Threads (Thread safety): Como todas as operações são funções suspend que delegam para dispatchers de segundo plano seguros, você não precisa gerenciar threads ou callbacks manualmente.

Fluxo de uso típico

Em uma estrutura MVVM típica:

  1. Seu container de DI (por exemplo, um módulo Hilt) cria uma única instância de RepositoryProvider com o Context da aplicação.
  2. O provedor expõe instâncias de repositórios concretos, como initializationRepository, paymentRepository, transactionRepository, entre outros.
  3. Os ViewModels recebem esses repositórios via injeção de construtor e chamam suas funções suspend a partir de corrotinas.
  4. Cada chamada retorna um RepositoryResult<T> que o ViewModel converte em estado de UI.

Para mais detalhes sobre como conectar os repositórios ao seu grafo de DI, consulte Primeiros Passos / Configurar Injeção de Dependência. Para entender a semântica do wrapper RepositoryResult<T> e como interpretar seus diferentes ramos, consulte Conceitos Principais / Tratar Respostas e Erros e Referência / Códigos de Resposta e Erro.