# Comprendiendo el Patrón del Repositorio 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`. - 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` 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` y cómo interpretar sus diferentes ramas, consulta **`Conceptos clave / Gestionar respuestas y errores`** y **`Referencia / Códigos de respuesta y error`**.