Skip to main content
Mapagam

Implementing Architecture Patterns

1. Understanding MVVM Pattern

Component Description Responsibility
Model Represents the data layer and business logic Handles data operations, validation, and communication with backend services
View UI layer (Activities, Fragments) Displays data and forwards user interactions to ViewModel
ViewModel Acts as a bridge between View and Model Manages UI-related data, handles user input, and prepares data for the View

Example: Basic MVVM Implementation in Kotlin

import androidx.lifecycle.ViewModel

class UserViewModel : ViewModel() {
    private val userRepository = UserRepository()

    fun fetchUser(userId: String) = liveData<User> {
        val user = userRepository.getUser(userId)
        emit(user)
    }

    fun updateUser(user: User) {
        viewModelScope.launch {
            userRepository.updateUser(user)
        }
    }
}

Comparison: MVVM vs MVC

  • MVC: View directly interacts with Model; tight coupling
  • MVVM: View binds to ViewModel; loose coupling, easier testing
Note: The ViewModel is lifecycle-aware and survives configuration changes like screen rotation.

2. Creating ViewModel Classes

Property Description Example
ViewModel Base class for ViewModel implementation class MyViewModel : ViewModel()
LiveData Observable data holder for UI updates val data: LiveData<String>
MutableLiveData Mutable version of LiveData for data updates val mutableData = MutableLiveData<String>()

Example: Basic ViewModel Implementation

import androidx.lifecycle.ViewModel
import androidx.lifecycle.LiveData
import androidx.lifecycle.MutableLiveData

class UserViewModel : ViewModel() {
    private val _user = MutableLiveData<String>()
    val user: LiveData<String> get() = _user

    fun loadUser(id: String) {
        _user.value = "User: $id"
    }
}

Example: Using ViewModel with Repository

class UserRepository {
    fun fetchUser(id: String): LiveData<String> {
        // Simulate network call
        return MutableLiveData("User: $id")
    }
}

class UserViewModel(private val repository: UserRepository) : ViewModel() {
    private val _user = MutableLiveData<String>()
    val user: LiveData<String> get() = _user

    fun loadUser(id: String) {
        repository.fetchUser(id).observeForever { data ->
            _user.value = data
        }
    }
}

3. Using LiveData for Observables

LifecycleOwner is the interface that represents a component that can observe the lifecycle state of another component. In Android, Activity and Fragment implement this interface.

Property Description Usage
value The value held by the LiveData instance. liveData.value = newValue
observe Registers an observer for lifecycle events. liveData.observe(this) { data -> ... }
observeForever Registers an observer that will be called regardless of lifecycle state. liveData.observeForever { data -> ... }

Example: Basic LiveData Usage

class MyViewModel : ViewModel() {
    private val _liveData = MutableLiveData<String>()
    val liveData: LiveData<String> = _liveData

    fun updateValue(newValue: String) {
        _liveData.value = newValue
    }
}

class MyActivity : AppCompatActivity() {
    private lateinit var viewModel: MyViewModel

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        viewModel = ViewModelProvider(this)[MyViewModel::class.java]

        viewModel.liveData.observe(this) { data ->
            // Update UI with data
            textView.text = data
        }
    }
}
Note: LiveData is lifecycle-aware and automatically manages the observer's lifecycle to prevent memory leaks.
Warning: Avoid holding strong references to LiveData in long-lived objects like activities or fragments to prevent memory leaks.

Key Points About LiveData

  • Thread-safe: Can be updated from any thread.
  • Lifecycle-aware: Observers are only notified when the lifecycle is in an active state.
  • Reactive: Automatically updates UI when data changes.

4. Observing LiveData

Property Description Usage
observe Registers an observer for LiveData changes liveData.observe(this) { data -> ... }
observeForever Registers an observer that is always active liveData.observeForever { data -> ... }
removeObserver Removes a specific observer liveData.removeObserver(observer)

Example: Observing LiveData in a Fragment

class MyFragment : Fragment() {
    private val viewModel: MyViewModel by viewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        viewModel.userData.observe(viewLifecycleOwner) { user ->
            // Update UI with user data
            textView.text = user.name
        }
    }
}

Example: Using observeForever

val liveData = MutableLiveData<String>()

// Observer that stays active even if lifecycle is not tied
liveData.observeForever { value ->
    println("Received: $value")
}

// Later, remove observer when no longer needed
liveData.removeObserver(observer)
Note: Use observe with viewLifecycleOwner in Fragments to avoid memory leaks.
Warning: Avoid using observeForever unless necessary, as it can lead to memory leaks if not manually removed.

5. Transforming LiveData

LiveData provides several transformation methods to modify data streams. These methods are essential for applying business logic or filtering data before observing it.

Method Description Return Type Notes
map Transforms the value of the LiveData using a function LiveData<T> Applies transformation to each emitted value
switchMap Transforms the value into a new LiveData and observes that LiveData<T> Useful for asynchronous operations or nested data

Example: Using map to transform data

val liveData = MutableLiveData<Int>()
val transformedLiveData = liveData.map { it * 2 }

// When liveData emits 5, transformedLiveData emits 10

Example: Using switchMap for asynchronous operations

val queryLiveData = MutableLiveData<String>()
val searchResults = queryLiveData.switchMap { query ->
    repository.search(query)
}

6. Implementing Repository Pattern

The Repository pattern is a design pattern that acts as an intermediary between the data layer and the business logic layer in Android applications. It abstracts the data source, allowing the app to work with local and remote data sources uniformly.

Component Description Implementation
Repository Encapsulates data access logic and provides a clean API for the rest of the app. 
class UserRepository(private val userDataSource: UserDataSource) {
    suspend fun getUser(id: String): Result<User> = userDataSource.getUser(id)
}
DataSource Defines how data is fetched or stored, can be local (e.g., Room) or remote (e.g., Retrofit). 
interface UserDataSource {
    suspend fun getUser(id: String): Result<User>
}
LocalDataSource Handles local data storage, typically using Room. 
class LocalUserDataSource(private val userDao: UserDao) : UserDataSource {
    override suspend fun getUser(id: String): Result<User> = 
        try {
            val user = userDao.getUser(id)
            Result.success(user)
        } catch (e: Exception) {
            Result.failure(e)
        }
}
RemoteDataSource Handles remote data fetching, typically using Retrofit or another HTTP client. 
class RemoteUserDataSource(private val api: UserApi) : UserDataSource {
    override suspend fun getUser(id: String): Result<User> = 
        try {
            val user = api.getUser(id)
            Result.success(user)
        } catch (e: Exception) {
            Result.failure(e)
        }
}

Example: Repository with Local and Remote Data Sources

class UserRepository(
    private val localDataSource: LocalUserDataSource,
    private val remoteDataSource: RemoteUserDataSource
) : UserDataSource {

    override suspend fun getUser(id: String): Result<User> {
        return localDataSource.getUser(id).getOrElse { 
            remoteDataSource.getUser(id) 
        }
    }

    suspend fun refreshUser(id: String): Result<User> {
        return remoteDataSource.getUser(id).onSuccess { user ->
            localDataSource.saveUser(user)
        }
    }
}
Note: The Repository pattern helps in decoupling the data layer from the UI and business logic, making it easier to test and maintain.

Key Benefits of Repository Pattern

  • Decouples data sources from the rest of the app.
  • Enables switching between local and remote data sources seamlessly.
  • Centralizes data access logic, improving maintainability.

7. Using StateFlow and SharedFlow

StateFlow and SharedFlow are part of Kotlin's reactive programming capabilities, designed to handle streams of data in a stateful and efficient manner. They are particularly useful in Android development for managing UI state and handling asynchronous events.

Feature Description Usage
StateFlow Represents a flow of values that always has a current value and emits new values to its collectors. Use for managing UI state that needs to be observed by the UI.
SharedFlow Represents a flow of values that can emit multiple values to multiple collectors. Use for handling events or asynchronous operations where multiple listeners are needed.

Example: Using StateFlow to manage UI state

import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.StateFlow

class UserViewModel {
    private val _userState = MutableStateFlow("Initial State")
    val userState: StateFlow<String> = _userState

    fun updateState(newState: String) {
        _userState.value = newState
    }
}

Example: Using SharedFlow to emit events

import kotlinx.coroutines.flow.MutableSharedFlow
import kotlinx.coroutines.flow.SharedFlow

class EventViewModel {
    private val _events = MutableSharedFlow<String>()
    val events: SharedFlow<String> = _events

    fun emitEvent(event: String) {
        _events.tryEmit(event)
    }
}
Note: StateFlow is a subclass of SharedFlow, but it ensures that there's always a current value, making it ideal for representing state.
Warning: When using SharedFlow, be cautious about memory leaks if collectors are not properly disposed of, especially in Android components like Activities or Fragments.

8. Managing UI State

State Management Approach Description Use Case Pros/Cons
ViewModel + LiveData Uses ViewModel to store and manage UI-related data in a lifecycle-conscious way. LiveData is observable and updates the UI when data changes. Simple to implement, good for basic state management in Android apps Pros: Built-in, lifecycle-aware, easy to test
Cons: Can become complex with large apps, requires manual handling of state transitions
StateFlow + ViewModel Uses Kotlin's StateFlow to manage UI state in a reactive way. More modern than LiveData, supports backpressure and is more flexible. Modern Android apps with reactive UI updates Pros: Reactive, immutable state, better for complex apps
Cons: Requires understanding of Kotlin coroutines
Jetpack Compose State Uses Compose's built-in state management with mutableStateOf, remember, and derivedStateOf. Apps using Jetpack Compose for UI Pros: Integrated with Compose, declarative
Cons: Only for Compose-based UIs

Example: Using ViewModel with StateFlow

import androidx.lifecycle.ViewModel
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.StateFlow

class UserViewModel : ViewModel() {
    private val _userState = MutableStateFlow("")
    val userState: StateFlow<String> = _userState

    fun updateUser(name: String) {
        _userState.value = name
    }
}

Example: Using Jetpack Compose State

import androidx.compose.runtime.*
import androidx.compose.foundation.layout.*

@Composable
fun UserScreen() {
    var userName by remember { mutableStateOf("") }

    Column {
        TextField(
            value = userName,
            onValueChange = { userName = it },
            label = { Text("Enter name") }
        )
        Text(text = "Hello, $userName!")
    }
}
Note: StateFlow is preferred over LiveData in modern Android development for its more reactive and functional approach.

9. Implementing Single Activity Architecture

Example: Basic Single Activity with Multiple Fragments

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        if (savedInstanceState == null) {
            supportFragmentManager.beginTransaction()
                .replace(R.id.container, HomeFragment())
                .commit()
        }
    }
}
Component Description Usage
Activity Root container for UI components Hosts Fragments and manages navigation
Fragment Reusable UI component Represents distinct sections of UI
FragmentManager Manages Fragments within Activity Handles transactions and lifecycle
Note: Single Activity Architecture (SAA) reduces complexity by using one Activity to manage multiple Fragments.

Workflow: Navigation Between Fragments

  1. Define navigation graph in nav_graph.xml
  2. Create NavigationController in Activity
  3. Use navController.navigate() to switch fragments

Comparison: SAA vs Multi-Activity

  • SAA: One Activity, multiple Fragments
  • Multi-Activity: Multiple Activities, each with own Fragment

10. Separating Concerns

Concern Description Implementation
Presentation Layer Handles UI logic and user interactions Use ViewModels with LiveData/StateFlow
Business Logic Layer Encapsulates core application logic Implement in Repository or Use Cases
Data Layer Manages data sources and persistence Use Room, Retrofit, or DataStore

Example: ViewModel with Separated Concerns

class UserViewModel(
    private val getUserUseCase: GetUserUseCase,
    private val updateUserUseCase: UpdateUserUseCase
) : ViewModel() {

    private val _user = MutableLiveData<User>()
    val user: LiveData<User> = _user

    fun loadUser(id: String) {
        viewModelScope.launch {
            val user = getUserUseCase(id)
            _user.value = user
        }
    }

    fun updateUser(user: User) {
        viewModelScope.launch {
            updateUserUseCase(user)
        }
    }
}

Benefits of Separation

  • Improved testability
  • Easier maintenance and scalability
  • Clearer responsibility boundaries
  • Enhanced code reusability

11. Implementing Clean Architecture

Example: Project Structure

app/
├── data/
│   ├── repository/
│   │   └── UserRepositoryImpl.kt
│   └── model/
│       └── UserResponse.kt
├── domain/
│   ├── repository/
│   │   └── UserRepository.kt
│   └── usecase/
│       └── GetUserUseCase.kt
└── presentation/
    ├── viewmodel/
    │   └── UserViewModel.kt
    └── ui/
        └── UserActivity.kt
Layer Description Responsibilities
Presentation Layer UI components and ViewModels Handles UI logic, observes data, updates UI
Domain Layer Business logic and use cases Defines use cases, business rules, and interfaces
Data Layer Data sources and repositories Handles data fetching, persistence, and repository implementations
Note: Clean Architecture promotes separation of concerns by organizing code into distinct layers with clear responsibilities.

Example: Use Case Implementation

interface UserRepository {
    suspend fun getUser(id: String): User
}

class GetUserUseCase(private val repository: UserRepository) {
    suspend operator fun invoke(id: String): Result<User> {
        return try {
            val user = repository.getUser(id)
            Result.success(user)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }
}

Example: Repository Implementation

class UserRepositoryImpl(
    private val api: UserApi,
    private val cache: UserCache
) : UserRepository {
    
    override suspend fun getUser(id: String): User {
        return cache.get(id) ?: api.fetchUser(id).also { cache.save(it) }
    }
}

Was this article helpful?

Related Cheat Sheets