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