Diseño arquitectonico 2 - sjfuentes-uniandes/ing-sw-app-moviles GitHub Wiki
Diagramas de arquitectura
Para el Sprint 2, se presentan los mismos diagramas de clases y componentes que en el Sprint anterior, esto debido a que las clases no han cambiado ni se han incrementado, por lo tanto no se considera necesario una adaptación más profunda en los diagramas. Sin embargo, en el detalle de cada una de las capas, se incrementa el detalle de lo realizado durante este sprint.
Diagrama de clases
Diagrama de componentes
Diagrama de paquetes
Capas
Model Layer (Modelo)
Responsabilidad: Gestión de datos, persistencia y lógica de negocio
Componentes:
Album.kt- Entity class con anotaciones Room para álbumCollector.kt- Entity class con anotaciones Room para coleccionistaArtist.kt- Entity class con anotaciones Room para artistasNetworkServiceAdapter.kt- Servicio para comunicación con API RESTVinilosRoomDatabase.kt- Base de datos local RoomAlbumsDao.kt- Interface DAO para operaciones de álbumesCollectorsDao.kt- Interface DAO para operaciones de coleccionistasArtistsDao.kt- Interface DAO para operaciones de artistas.
Repository Layer (Repositorio)
Responsabilidad: Coordinación entre fuentes de datos locales y remotas
Componentes:
AlbumRepository.kt- Gestiona cache local y sincronización de álbumesCollectorRepository.kt- Gestiona cache local y sincronización de coleccionistasArtistsRepository.kt- Gestiona cache local y sincronización de artistas
ViewModel Layer (Modelo de Vista)
Responsabilidad: Lógica de presentación y comunicación entre View y Repository
Componentes:
AlbumViewModel.kt- Gestiona lista de álbumes, estados de carga y errores de redCollectorViewModel.kt- Gestiona lista de coleccionistas, estados de carga y errores de redArtistsViewModel.kt- Gestiona lista de artistas, estados de carga y errores de redHomeViewModel.kt- ViewModel básico con texto estáticoDashboardViewModel.kt- ViewModel básico con texto estáticoNotificationsViewModel.kt- ViewModel básico con texto estático
View Layer (Vista)
Responsabilidad: Interfaz de usuario y presentación
Componentes:
MainActivity.kt- Actividad principal con navegación bottom navigationHomeFragment.kt- Fragmento de página principal con botones de navegaciónAlbumsFragment.kt- Fragmento que muestra lista de álbumes con pull-to-refreshAddAlbumsFragment.kt- Fragmento que muestra el formulario para crear un albumAlbumDetailFragment.kt- Fragmento que muestra el detalle de un albumCollectorsFragment.kt- Fragmento que muestra lista de coleccionistas con pull-to-refreshArtistsFragment.kt- Fragmento que muestra la lista de artistas con pull-to-refreshArtistDetailFragment.kt- Fragmento que muestra el detalle de un artistaDashboardFragment.kt- Fragmento básico para artistas (placeholder)NotificationsFragment.kt- Fragmento básico para usuarios (placeholder)AlbumsAdapter.kt- Adaptador RecyclerView con data binding para álbumesCollectorsAdapter.kt- Adaptador RecyclerView con data binding para coleccionistasArtistsAdapter.kt- Adaptador RecyclerView con data binding para artistas
Interfaces y Componentes Intermedios
UI ↔ ViewModel
- LiveData: Observable data streams para cambios reactivos
- ViewBinding: Binding automático de componentes UI
- Factory Pattern: Creación de ViewModels con dependencias
- Observer Pattern: Observación de cambios en LiveData
ViewModel ↔ Repository
- Repository Pattern: Abstracción de fuentes de datos
- Result: Wrapper para operaciones success/failure
- Coroutines: Manejo asíncrono con suspend functions
- ViewModelScope: Lifecycle-aware coroutine scope
Repository ↔ Data Sources
- DAO Interfaces: Abstracción de operaciones de base de datos
- NetworkServiceAdapter: Wrapper para llamadas HTTP
- Dispatchers.IO: Threading para operaciones I/O
- suspendCoroutine: Conversión de callbacks a suspend functions
Data Layer
- Room Database: ORM para persistencia local
- Entity Annotations: @Entity, @PrimaryKey, @Dao
- LiveData: Streams reactivos desde base de datos
- Volley: Cliente HTTP para API calls
Flujo de Datos Offline-First
View → ViewModel → Repository → [DAO + NetworkAdapter] → API/Database
View ← ViewModel ← Repository ← [DAO + NetworkAdapter] ← API/Database
- View solicita datos al ViewModel
- ViewModel solicita datos al Repository
- Repository retorna LiveData del DAO (datos cacheados)
- View muestra datos inmediatamente
- Repository sincroniza con API en background
- Repository actualiza DAO con datos frescos
- LiveData notifica cambios automáticamente
- View se actualiza con datos frescos
Manejo de Errores y Estados
- Sin Internet: App funciona con datos cacheados
- Error de Red: Se muestra mensaje, datos cacheados permanecen
- Cache Vacío: Se muestra loading hasta recibir datos de API
- Pull-to-Refresh: Fuerza sincronización con API
- Cache Invalidation: deleteAll() + insertAll() para datos frescos
Tecnologías
- Kotlin - Lenguaje de programación
- Android Architecture Components - LiveData, ViewModel, Navigation
- Volley - Cliente HTTP para API REST
- Glide - Carga de imágenes
- Data Binding - Vinculación de datos en layouts
- Material Design - Bottom navigation y componentes UI