Android Architecture Guidelines
When implementing Android features, follow these patterns:
State Management (MVI)
- •Use single immutable state object per screen
- •State class should contain: data, isLoading, error, and any UI-relevant fields
- •Actions represent user intents (sealed interface)
- •Events for one-time effects like navigation or toasts (use Channel)
Repository Pattern
- •Interface in domain layer, implementation in data layer
- •Repository is the single source of truth
- •Use suspend functions for one-shot operations (API calls)
- •Use Flow only when observing changes over time (Room, WebSocket)
ViewModel
- •Expose state via StateFlow
- •Handle actions via onAction() method
- •Use viewModelScope for coroutines
- •Never expose MutableStateFlow directly
Data Layer
- •DTOs for API responses (@Serializable)
- •Entities for Room database (@Entity)
- •Domain models for business logic
- •Mappers: toEntity(), toDomain(), toDto()
Dependency Injection
- •Use Hilt for DI
- •Provide APIs via @Provides in NetworkModule
- •Provide DAOs via @Provides in DatabaseModule
- •Bind repositories with @Binds