Getnet DocsGetnet Docs

Comprendiendo el Patrón del Repositorio

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

El Get Smart SDK (redsys-tpv-business-lib) está diseñado en torno al Patrón Repository, un estándar en el desarrollo moderno de Android que encaja de forma natural en proyectos MVVM y Clean Architecture.

En lugar de exponer llamadas de servicio de bajo nivel directamente a tus Activities o Fragments, el SDK agrupa las operaciones en interfaces de repositorio enfocadas (p. ej., InitializationRepository, PaymentRepository, RefundRepository, TransactionRepository).

Arquitectura de alto nivel

El repositorio actúa como una capa de abstracción segura entre tu aplicación y el Get Smart SDK Payment Service (el servicio en segundo plano que se ejecuta en el dispositivo).

A alto nivel, cada repositorio:

  • Envuelve toda la comunicación con el Get Smart SDK Payment Service instalado en el dispositivo.
  • Expone funciones suspend de Kotlin que siempre devuelven un wrapper RepositoryResult<T>.
  • Mueve automáticamente la ejecución a Dispatchers.IO, manteniendo el hilo principal libre de operaciones de E/S bloqueantes.
  • Mantiene tu capa de UI y UseCases independientes de la implementación subyacente.

Beneficios para tu arquitectura

El uso de repositorios de esta manera ofrece varias ventajas concretas:

  • Desacoplamiento: Tu aplicación depende solo de las interfaces de los repositorios (contratos), no de las clases de implementación concretas ni del protocolo del servicio.
  • Listo para Inyección de Dependencias: Los repositorios están diseñados para ser proporcionados como singletons a través de Dagger Hilt (o manualmente mediante RepositoryProvider), manteniendo limpia la raíz de composición de tu proyecto.
  • Testabilidad: Debido a que el SDK se basa en interfaces, puedes reemplazar los repositorios reales por fakes o mocks en tus pruebas unitarias sin necesidad de un TPV físico o del Servicio de Pago.
  • Seguridad de hilos (Thread safety): Dado que todas las operaciones son funciones suspend que delegan en dispatchers de segundo plano seguros, no es necesario gestionar hilos o callbacks manualmente.

Flujo de uso típico

En una configuración MVVM típica:

  1. Tu contenedor de DI (por ejemplo, un módulo Hilt) crea una única instancia de RepositoryProvider con el Context de la aplicación.
  2. El proveedor expone instancias de repositorios concretos como initializationRepository, paymentRepository, transactionRepository, etc.
  3. Los ViewModels reciben estos repositorios mediante inyección de constructor y llaman a sus funciones suspend desde corrutinas.
  4. Cada llamada devuelve un RepositoryResult<T> que el ViewModel convierte en estado de UI.

Para más detalles sobre cómo conectar los repositorios a tu grafo de DI, consulta Primeros pasos / Configurar Inyección de Dependencia. Para conocer la semántica del wrapper RepositoryResult<T> y cómo interpretar sus diferentes ramas, consulta Conceptos clave / Gestionar respuestas y errores y Referencia / Códigos de respuesta y error.