We will now use EnvironmentObject to monitor when a user logs in and out.

1. When the user is successfully logged in (isLoggedIn = true), they are directed to the rest of the application views.
2. When a user is logged out (isLoggedIn = false) at any point within the app, they are directed to the login page.

We need the following components:

1. User State View Model
2. Application Switcher
3. Login Screen
4. Home Screen (Our Application Views)

User State View Model

The user state view model tracks and broadcasts the user status. We store this view model in an EnvironmentObject.

import Foundation

enum UserStateError: Error{
    case signInError, signOutError
}

@MainActor
class UserStateViewModel: ObservableObject {

    @Published var isLoggedIn = false
    @Published var isBusy = false

    func signIn(email: String, password: String) async -> Result<Bool, UserStateError>  {
        isBusy = true
        do{
            try await Task.sleep(nanoseconds:  1_000_000_000)
            isLoggedIn = true
            isBusy = false
            return .success(true)
        }catch{
            isBusy = false
            return .failure(.signInError)
        }
    }

    func signOut() async -> Result<Bool, UserStateError>  {
        isBusy = true
        do{
            try await Task.sleep(nanoseconds: 1_000_000_000)
            isLoggedIn = false
            isBusy = false
            return .success(true)
        }catch{
            isBusy = false
            return .failure(.signOutError)
        }
    }
}

We make our view model instance available to all child views, starting from the ApplicationSwitcher view

Application Switcher

import SwiftUI

@main
struct LoginFlowApp: App {

    @StateObject var userStateViewModel = UserStateViewModel()

    var body: some Scene {
        WindowGroup {
            NavigationView{
                ApplicationSwitcher()
            }
            .navigationViewStyle(.stack)
            .environmentObject(userStateViewModel)
        }
    }
}

struct ApplicationSwitcher: View {

    @EnvironmentObject var vm: UserStateViewModel

    var body: some View {
        if (vm.isLoggedIn) {
                HomeScreen()
        } else {
            LoginScreen()
        }

    }
}

Login Screen

The Login screen uses the UserStateViewModel to invoke signIn

import SwiftUI

struct LoginScreen: View {

    @EnvironmentObject var vm: UserStateViewModel
    @State var email = ""
    @State var password = ""

    fileprivate func EmailInput() -> some View {
        TextField("Email", text: $email)
            .keyboardType(.emailAddress)
            .disableAutocorrection(true)
            .autocapitalization(.none)
            .textFieldStyle(.roundedBorder)
    }

    fileprivate func PasswordInput() -> some View {
        SecureField("Password", text: $password)
            .textFieldStyle(.roundedBorder)
    }

    fileprivate func LoginButton() -> some View {
        Button(action: {
            Task {
                await vm.signIn(
                    email: email,
                    password:password
                )
            }
        }) {
            Text("Sign In")
        }
    }

    var body: some View {

        VStack{
            if(vm.isBusy){
                ProgressView()
            }else{
                Text("Login Screen").font(.title)
                EmailInput()
                PasswordInput()
                LoginButton()
            }
        }.padding()

    }
}

Home Screen with Logout Button

The Home screen uses the UserStateViewModel to invoke signOut

import SwiftUI

struct HomeScreen: View {

    @EnvironmentObject var vm: UserStateViewModel

    var body: some View {

        if(vm.isBusy){
            ProgressView()
        }else{
            Text("Home Screen")
                .navigationTitle("Home")
                .toolbar {

                        Button {
                            Task{
                                await vm.signOut()
                            }
                        } label: {
                            Image(systemName:  "rectangle.portrait.and.arrow.right")
                        }


                }
        }
    }
}

Here we will use it to direct our application when a user logs in and out.

1. When the user is successfully logged in (isLoggedIn = true), they are directed to the rest of the application views.
2. When a user is logged out (isLoggedIn = false) at any point within the app, they are directed to the login page.

We need the following components:

1. User State View Model
2. Application Switcher
3. Login Screen
4. Home Screen

User State View Model

The UserStateViewModel keeps track of and broadcasts our user status. We are going to store this view model to a CompositionLocal.

import androidx.compose.runtime.compositionLocalOf
import androidx.compose.runtime.getValue
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.setValue
import androidx.lifecycle.ViewModel
import kotlinx.coroutines.delay


class UserStateViewModel : ViewModel() {
    var isLoggedIn by mutableStateOf(false)
    var isBusy by mutableStateOf(false)

    suspend fun signIn(email: String, password: String) {
        isBusy = true
        delay(2000)
        isLoggedIn = true
        isBusy = false
    }

    suspend fun signOut() {
        isBusy = true
        delay(2000)
        isLoggedIn = false
        isBusy = false
    }
}

val UserState = compositionLocalOf<UserStateViewModel> { error("User State Context Not Found!") }

We make our view model instance available to all child composables, starting from the ApplicationSwitcher composable

class MainActivity : ComponentActivity() {
    private val userState by viewModels<UserStateViewModel>()
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            CompositionLocalProvider(UserState provides userState) {
                ApplicationSwitcher()
            }
        }
    }
}

Application Switcher

@Composable
fun ApplicationSwitcher() {
    val vm = UserState.current
    if (vm.isLoggedIn) {
        HomeScreen()
    } else {
        LoginScreen()
    }
}

Login Screen

The Login screen can now use the UserStateViewModel to invoke signIn

@Composable
fun LoginScreen() {
    var email by remember { mutableStateOf("") }
    var password by remember { mutableStateOf("") }
    val coroutineScope = rememberCoroutineScope()
    val vm = UserState.current
    Column(
        Modifier
            .fillMaxSize()
            .padding(32.dp),
        verticalArrangement = Arrangement.Center,
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        if (vm.isBusy) {
            CircularProgressIndicator()
        } else {
            Text("Login Screen", fontSize = 32.sp)
            Spacer(modifier = Modifier.height(16.dp))
            Email(email, onChange = {
                email = it
            })
            Spacer(modifier = Modifier.height(16.dp))
            Password(password, onChange = {
                password = it
            })
            Spacer(modifier = Modifier.height(16.dp))
            LoginButton(onClick = {
                coroutineScope.launch {
                    vm.signIn(email, password)
                }
            })
        }


    }
}

Home Screen with Logout Button

The Home screen also uses the UserStateViewModel to invoke the signOut

@Composable
fun HomeScreen(navController: NavHostController) {
    val vm = UserState.current
    val coroutineScope = rememberCoroutineScope()
    Scaffold(
        topBar = {
            TopAppBar(
                title = { Text("Home") },
                actions = {
                    IconButton(onClick = {
                        coroutineScope.launch {
                            vm.signOut()
                        }
                    }) {
                        Icon(Icons.Filled.ExitToApp, null)
                    }
                }
            )
        },
        ) {
        Column(
            Modifier
                .fillMaxSize()
                .padding(16.dp),
            verticalArrangement = Arrangement.Center,
            horizontalAlignment = Alignment.CenterHorizontally
        ) {
            if (vm.isBusy) {
                CircularProgressIndicator()
            } else {
                Text("Home")
            }
        }
    }
}

At all times the Application Switcher is monitoring the isLoggedIn status:

In this blog, I'll cover how I would use TDD to build a clean architecture To-do SwiftUI application

I'll cover implementing the "Get To-dos" use case.

For this type of application, we need 2 types for application testing; UI Testing and Unit Testing. We'll be concentrating on the business logic, so we'll only be covering TDD unit testing. Before we write any production code, we'll write the test first.

The application will be structured in the following file and folder structure:

.
├── MyApp
    ├── Data
    │   ├── DataSource
    │   │   ├── TodoDataSource.swift
    │   │   └── DB
    │   │       ├── Entity
    │   │       │    └── TodoDBEntity.swift
    │   │       └── TodoDBDataSourceImpl.swift
    │   └── Repository
    │       └── TodoRepositoryImpl.swift
    ├── Domain
    │    ├── Model
    │    │   └── Todo.swift
    │    ├── Repository
    │    │   └── TodoRepository.swift
    │    └── UseCase
    │        └── GetTodos.swift
    └── Presentation
        ├── TodoViewModel.swift
        └── TodoListView.swift
└── MyAppTests
    ├── Data
    │   ├── DataSource
    │   │   └── DB
    │   │       └── TodoDBDataSourceImplTest.swift
    │   └── Repository
    │       └── TodoRepositoryImplTest.swift
    ├── Domain
    │    └── UseCase
    │        └── GetTodosTest.swift
    └── Presentation
        └── TodoViewModelTest.swift

We'd like to develop the "TodoViewModel" through the practice of TDD

A note on TDD

TDD is a software development process in which the unit test will be written first and after that the original code. In TDD, the design and development of the code are through unit tests.

In the traditional unit tests, the unit test is written after the original code is written. This is only for long-term maintainability. But in TDD the unit test is written first and code evolved through it.

Red Green Refactor

Red Green Refactor is an interesting concept in TDD. The stages are given below:

Red - First a failing unit test is created, and it results in red status

Green - We will modify the associated code to just make the unit test pass - resulting in green status

Refactor - Once the test is passing we can refactor the code so that the original implementation is done.

To get started with testing in your iOS SwiftUI project, we need to add a test target:

This now creates a test template: To run the entire test suite click on the run button next to the class name or to run individual tests click the diamond button next to each test. Also note that each test needs to begin with the word "test"

Let's create the test and application file and folder structure. We'll just create the file without any production code. All development code will be driven by test code.

Let's start with our first test:

MyAppTests/Presentation/TodoViewModelTest.swift

Of course, this test doesn't build and therefore fails because the file doesn't exist. We're in the RED Stage.

Let's write the minimum code to make the test pass.

import Foundation

class TodoViewModel: ObservableObject {

}

If we run the test again, it passes - GREEN Stage

We also notice that the View Model takes a dependency so we'll have to change the test to include the getTodosUseCase

We're back in RED stage

Let's update the view model

import Foundation

class TodoViewModel: ObservableObject {

    private var getTodosUseCase : GetTodos

    init(getTodosUseCase: GetTodos){
        self.getTodosUseCase = getTodosUseCase
    }

}

We need to create the protocol and mock implementation for GetTodosUseCase. While we are at it let's create the Todo Model

enum UseCaseError: Error{
    case dataSourceError, decodingError
}

protocol GetTodos {
    func execute() async -> Result<[Todo], UseCaseError>
}

import Foundation

struct Todo: Identifiable {
    let id: Int
    let title: String
    let isCompleted: Bool
}

Because we're testing and developing the view model, we don't need a GetTodos use case implementation at this stage, we will need to create a mock use case that implements the protocol

import Foundation
@testable import MyApp

class MockGetTodosUseCase: GetTodos{
    func execute() async -> Result<[Todo], UseCaseError> {
        Result.success([
            Todo(id: 1, title: "Mock Title One", isCompleted: true),
            Todo(id: 2, title: "Mock Title Two", isCompleted: false)
        ])
    }
}

The test passes - GREEN stage

Let's add a few more tests to drive the development of the view model

testTodoViewModel_Should_Return_An_Empty_Todos_List

import Foundation

class TodoViewModel: ObservableObject {

    private var getTodosUseCase : GetTodos

    init(getTodosUseCase: GetTodos){
        self.getTodosUseCase = getTodosUseCase
    }

    @Published
    var todos: [Todo] = []

}

testTodoViewModel_Should_Return_2_Todos_When_getTodos_Is_Invoked

import Foundation

class TodoViewModel: ObservableObject {

    private var getTodosUseCase : GetTodos

    init(getTodosUseCase: GetTodos){
        self.getTodosUseCase = getTodosUseCase
    }

    @Published
    var todos: [Todo] = []

    func getTodos() async {

        let result = await self.getTodosUseCase.execute()
        switch result{
        case .success(let todos):
            self.todos = todos
        case .failure(_):
            self.todos = []

        }
    }
}

testTodoViewModel_Should_Display_Error_Message_When_getTodos_Results_In_Error

let's create a use case that results in an error

import Foundation
@testable import MyApp

class MockGetTodosErrorUseCase: GetTodos{
    func execute() async -> Result<[Todo], UseCaseError> {
        Result.failure(.dataSourceError)
    }
}

import Foundation

class TodoViewModel: ObservableObject {

    private var getTodosUseCase : GetTodos

    init(getTodosUseCase: GetTodos){
        self.getTodosUseCase = getTodosUseCase
    }

    @Published
    var todos: [Todo] = []


    @Published
    var errorMessage = ""

    func getTodos() async {

        let result = await self.getTodosUseCase.execute()
        switch result{
        case .success(let todos):
            self.todos = todos
        case .failure(let error):
            self.todos = []

            if(error == UseCaseError.dataSourceError){
                errorMessage = "Error"
            }

            if(error == UseCaseError.decodingError){
                errorMessage = "Data Decoding Error"
            }
        }
    }
}

Our test is finally picking up that the error message is incorrect. We need to rename it from "Error" to "Data Source Error" and all the tests finally pass

     if(error == UseCaseError.dataSourceError){
                errorMessage = "Data Source Error"
            }

Our code for the todo view model is finally done. We can use the same process for all other business logic in other layers.

In this blog, I'll cover how I would use TDD to build a clean architecture To-do Jetpack Compose Android application

I'll cover implementing the "Get To-dos" use case.

For this type of application, we need 2 types for application testing; UI Testing and Unit Testing. We'll be concentrating on the business logic, so we'll only be covering TDD unit testing. Before we write any production code, we'll write the test first.

The application will be structured in the following file and folder structure:

.
.
├── src
    ├── Data
    │   ├── DataSource
    │   │   ├── TodoDataSource.kt
    │   │   └── DB
    │   │       ├── Entity
    │   │       │    └── TodoDBEntity.kt
    │   │       └── TodoDBDataSourceImpl.kt
    │   └── Repository
    │       └── TodoRepositoryImpl.kt
    ├── Domain
    │    ├── Model
    │    │   └── Todo.kt
    │    ├── Repository
    │    │   └── TodoRepository.kt
    │    └── UseCase
    │        └── GetTodos.kt
    └── Presentation
        ├── TodoViewModel.kt
        └── TodoListView.kt
└── test
    ├── Data
    │   ├── DataSource
    │   │   └── DB
    │   │       └── TodoDBDataSourceImplTest.kt
    │   └── Repository
    │       └── TodoRepositoryImplTest.kt
    ├── Domain
    │    └── UseCase
    │        └── GetTodosTest.kt
    └── Presentation
        └── TodoViewModelTest.kt

We'd like to put the "TodoViewModel" under test.

A note on TDD

TDD (Test Driven Development) is a software development process in which the unit test will be written first and after that the original code. In TDD, the design and development of the code are through unit tests.

In the traditional unit tests, the unit test is written after the original code is written. This is only for long-term maintainability. But in TDD the unit test is written first and code evolved through it.

Red Green Refactor

Red Green Refactor is an interesting concept in TDD. The stages are given below:

Red - First a failing unit test is created, and it results in red status

Green - We will modify the associated code to just make the unit test pass - resulting in green status

Refactor - Once the test is passing we can refactor the code so that the original implementation is done.

When you create an android project, Android Studio automatically creates a UI Test (androidTest) Package and Unit Test (test) Package.

Let's start by writing a test for our View Model.

test_TodoListViewModel_Should_Exist

Obviously the test doesn't build and therefore fails because these file don't exist. We're in Red Stage.

Let's write the minimum code to make the test pass. We need a view model and its mock dependency.

class TodoViewModel constructor(private val GetTodos: GetTodos) : ViewModel() {

}

interface GetTodos {
    suspend operator fun invoke(): List<Todo>
}

class MockGetTodosUseCase : GetTodos {

    override suspend operator fun invoke(): List<Todo> {
        var list = listOf(
            Todo(id = 1, title = "One", isComplete = true),
            Todo(id = 2, title = "Two", isComplete = false),
            Todo(id = 3, title = "Three", isComplete = true),
            Todo(id = 4, title = "Four", isComplete = false),
        )

        return list
    }
}

The test will now pass - Green Stage

Let's add a few more tests to drive the development of the view model

test_TodoListViewModel_Should_Return_An_Empty_Todos_List

class TodoViewModel constructor(private val GetTodos: GetTodos) : ViewModel() {
    private val _todos = mutableStateListOf<Todo>()
    val todos: List<Todo>
        get() = _todos
}

test_TodoListViewModel_Should_Return_4_Todos_When_getTodos_Is_Invoked

class TodoViewModel constructor(private val GetTodos: GetTodos) : ViewModel() {
    private val _todos = mutableStateListOf<Todo>()
    val todos: List<Todo>
        get() = _todos

    suspend fun getTodos() {
        _todos.clear()
        val result = GetTodos()
        _todos.addAll(result)
    }

}

test_TodoListViewModel_Should_Display_Error_Message_When_getTodos_Throws_Exception

class MockGetTodosThrowingUseCase : GetTodos {

    override suspend operator fun invoke(): List<Todo> {
        throw Exception("Use Case Error")
    }
}

class TodoViewModel constructor(private val GetTodos: GetTodos) : ViewModel() {
    private val _todos = mutableStateListOf<Todo>()
    val todos: List<Todo>
        get() = _todos

    private val _errorMessage = mutableStateOf("")
    val errorMessage: String
        get() = _errorMessage.value

    suspend fun getTodos() {
        try {
            _todos.clear()
            val result = GetTodos()
            _todos.addAll(result)
        } catch (err: Exception) {
            _errorMessage.value = err.message.toString()
        }
    }
}

We can now continue down the flow dependency chain, unit testing and mocking until we complete the "get todos" use case.

dependencies {
    ....
    kapt "org.xerial:sqlite-jdbc:3.34.0"

    // Room
    def room_version = "2.3.0"
    implementation "androidx.room:room-runtime:$room_version"
    annotationProcessor "androidx.room:room-compiler:$room_version"
    kapt "androidx.room:room-compiler:$room_version"
    implementation "androidx.room:room-ktx:$room_version"
}

Note: the “sqlite-jdbc” needed at the time of this blog if you’re running an arm processor as you’ll get this without it: “No native library is found for os.name=Mac and os.arch=aarch64”

After adding those dependencies, let’s once again continue with a clean architectured project by creating the following structure. We’ll only cover the files on display

├─Core
├─Presentation
├─Domain
│ ├─Model
│ │ └─ Todo.kt
│ └─Repository
│   └─ TodoRepository.kt
└─Data
  ├─DataSource 
  │ ├─ TodoDataSource.kt
  │ └─Room
  │   ├─ TodoDao.kt
  │   ├─ TodoDatabase.kt
  │   ├─ TodoRoomDataSourceImpl.kt
  │   └─Entity
  │     └─TodoRoomEntity.kt
  └─Repository
    └─TodoRepositoryImpl.kt

data class Todo(
    val id: Int?,
    val title: String,
    val isComplete: Boolean,
)

interface TodoRepository {
    suspend fun getTodos(): Result<List<Todo>>
    suspend fun getTodo(id: Int): Result<Todo>
    suspend fun deleteTodo(id: Int): Result<Boolean>
    suspend fun createTodo(todo: Todo): Result<Boolean>
    suspend fun updateTodo(todo: Todo): Result<Boolean>
}

Next, we’ll specify what our Datasource must do by creating the TodoDataSource interface

interface TodoDataSource {
    suspend fun getAll(): List<Todo>
    suspend fun getById(id: Int)
    suspend fun delete(id: Int)
    suspend fun create(todo: Todo)
    suspend fun update(id: Int, todo: Todo)
}

Ok now let’s implement these project details:

We need three things to allow our Kotlin code to talk to our SQLite DB:

1. Data entities: data classes that represent database tables
2. Data access objects (DAO): container of methods that map to SQL queries
3. Database class: the main access point for persisting data

Let’s start with our data entity. We’ll name this TodoRoomEntity as this represents a room-specific entity. Note how the extra mapping code from TodoRoomEntity to Todo data class in the Domain layer.

@Entity(tableName = "tb_todo")
data class TodoRoomEntity(
    @PrimaryKey(autoGenerate = true)
    @ColumnInfo(name = "id")
    val id: Int?,
    val title: String,
    val is_complete: Boolean
)

fun TodoRoomEntity.toTodo(): Todo {
    return Todo(
        id = id,
        isComplete = is_complete,
        title = title
    )
}

Now let’s create the DAO and the database

@Dao
interface TodoDao {
    @Query("SELECT * FROM tb_todo")
    suspend fun getAll(): List<TodoRoomEntity>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insert(todo: TodoRoomEntity)

    @Update
    suspend fun update(vararg todos: TodoRoomEntity)

    @Query("SELECT * FROM tb_todo WHERE id = :id")
    suspend fun getById(id: Int): TodoRoomEntity?

    @Query("DELETE FROM tb_todo WHERE id = :id")
    suspend fun deleteById(id: Int)

}

@Database(entities = [TodoRoomEntity::class], version = 1)
abstract class TodoDatabase : RoomDatabase() {
    abstract val todoDao: TodoDao

    companion object {
        const val DATABASE_NAME = "todo_db"
    }
}

To use the Dao we can create a data source that conforms to the TodoDataSource. We inject the DAO as a dependency.

class TodoRoomDataSourceImpl(private val dao: TodoDao) : TodoDataSource {

    override suspend fun getAll(): List<Todo> {
        return dao.getAll().map { it.toTodo() }
    }

    override suspend fun getById(id: Int): Todo? {
        val todoRoomEntity = dao.getById(id)
        if (todoRoomEntity != null) {
            return todoRoomEntity.toTodo()
        }
        return null
    }

    override suspend fun delete(id: Int) {
        dao.deleteById(id)
    }

    override suspend fun create(todo: Todo) {
        dao.insert(
            TodoRoomEntity(
                id = null,
                title = todo.title,
                is_complete = todo.isComplete
            )
        )
    }

    override suspend fun update(id: Int, todo: Todo) {
        dao.update(
            TodoRoomEntity(
                id = id,
                title = todo.title,
                is_complete = todo.isComplete
            )
        )
    }
}

and then lastly, our TodoRepositoryImpl would implement our TodoRepository:

class TodoRepositoryImpl(private val datasource: TodoDataSource) : TodoRepository {
    override suspend fun getTodos(): Result<List<Todo>> {
        return try {
            Result.success(datasource.getAll())
        } catch (e: Exception) {
            Result.failure(Exception("Error Getting Data"))
        }
    }

    override suspend fun getTodo(id: Int): Result<Todo?> {
        return try {
            val todo = datasource.getById(id)
            Result.success(todo)
        } catch (e: Exception) {
            Result.failure(Exception("Error Getting Todo"))
        }
    }

    override suspend fun deleteTodo(id: Int): Result<Boolean> {
        return try {
            Result.success(true)
        } catch (e: Exception) {
            Result.failure(Exception("Error Deleting Data"))
        }
    }

    override suspend fun createTodo(todo: Todo): Result<Boolean> {
        return try {
            Result.success(true)
        } catch (e: Exception) {
            Result.failure(Exception("Error Creating Todo"))
        }
    }

    override suspend fun updateTodo(todo: Todo): Result<Boolean> {
        return try {
            datasource.update(todo.id!!, todo)
            Result.success(true)
        } catch (e: Exception) {
            Result.failure(Exception("Error Updating Todo"))
        }
    }
}

Of course, we can use good old manual dependency injection as follows:

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {

        val viewModel = TodoViewModel(
            GetTodos = GetTodosUseCase(
                todoRepository = TodoRepositoryImpl(
                    datasource = TodoDataSourceImpl()
                )
            ),
            CreateTodo = CreateTodoUseCase(
                todoRepository = TodoRepositoryImpl(
                    datasource = TodoDataSourceImpl()
                )
            ),
            DeleteTodo =  DeleteTodoUseCase(
                todoRepository = TodoRepositoryImpl(
                    datasource = TodoDataSourceImpl()
                )
            )
        )

        super.onCreate(savedInstanceState)
        setContent {
            TodoView(viewModel)
        }
    }
}

class TodoViewModel  constructor(
    private val GetTodos: GetTodos,
    private val CreateTodo: CreateTodo,
    private val DeleteTodo: DeleteTodo
) : ViewModel() {

...

}

class GetTodosUseCase(private val todoRepository: TodoRepository) : GetTodos {
    ...
}

class TodoRepositoryImpl(private val datasource: TodoDataSource) : TodoRepository {
    ...
}

class TodoDataSourceImpl() : TodoDataSource {
    ...
}

To ease the pain of dependency injection, we are going to use Hilt to manage and resolve our dependencies.

To use Hilt, add the following build dependencies to the Android Gradle module’s build.gradle file:

plugins {
    ...
    id 'dagger.hilt.android.plugin'
}
dependencies {
    ...
    implementation 'com.google.dagger:hilt-android:2.39.1'
    implementation 'androidx.hilt:hilt-navigation-compose:1.0.0-alpha03'
    kapt "com.google.dagger:hilt-compiler:2.39.1"
    kapt "androidx.hilt:hilt-compiler:1.0.0"
}

Note: you only need “hilt-navigation-compose” if you intend to inject view models

Let’s start.

1. Make your project aware of Hilt and that's it’s going to do DI for you
2. Mark the android activity that is going to be the root or starting point of all DI
3. Tell Hilt how to provide instances of a ViewModel.
4. Mark class constructors with @Inject to tell Hilt how to create instances of a class.
5. Create your IOC container

Create Hilt Android App

All apps that use Hilt must contain an application class that is annotated with @HiltAndroidApp.

Create a file in the root package:

import android.app.Application
import dagger.hilt.android.HiltAndroidApp

@HiltAndroidApp
class TodoApp : Application()

Update your application name in your AndroidManifest.xml file

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.diexample">

    <application
        android:name=".TodoApp"
        ...
    >
        ...                 
    </application>

</manifest>

Mark MainActivity as AndroidEntryPoint

For Hilt to be able to inject dependencies into an activity, the activity needs to be annotated with @AndroidEntryPoint. Let’s change our MainActivity from before to:

@AndroidEntryPoint
class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            TodoView()
        }
    }
}

@Composable
fun TodoView(vm: TodoViewModel = hiltViewModel()) {
   ... 
}

Create IOC Container

Next, we create our container to list and resolve our dependencies.

@Module
@InstallIn(SingletonComponent::class)
object AppModule {

    @Provides
    @Singleton
    fun providesTodoDatasource(db: TodoDatabase): TodoDataSource {
        return TodoRoomDataSourceImpl()
    }

    @Provides
    @Singleton
    fun providesTodoRepository(dataSource: TodoDataSource): TodoRepository {
        return TodoRepositoryImpl(datasource = dataSource)
    }

    @Provides
    @Singleton
    fun providesGetTodosUseCase(repository: TodoRepository): GetTodos {
        return GetTodosUseCase(todoRepository = repository)
    }


    @Provides
    @Singleton
    fun providesCreateTodoUseCase(repository: TodoRepository): CreateTodo {
        return CreateTodoUseCase(todoRepository = repository)
    }

    @Provides
    @Singleton
    fun providesDeleteTodoUseCase(repository: TodoRepository): DeleteTodo {
        return DeleteTodoUseCase(todoRepository = repository)
    }


}

├─Core
└─Data
    ├─DataSource
    │   ├── TodoDataSource.swift
    │   └─CoreData
    │       ├── Main.xcdatamodeld
    │       └── TodoCoreDataSourceImpl.swift
    └─Repository
        └── TodoRepositoryImpl.swift

├─Presentation
└─Domain
    ├─Model
    │ └── Todo.swift
    ├─Error
    │ └── TodoError.swift
    └─Repository
      └── TodoRepository.swift

Let’s first specify our Domain Model and Repository. We need a domain model because we can’t always control what our data source model looks and operates like.

struct Todo: Identifiable{
    let id: UUID
    let title: String
    let isCompleted: Bool
}

Mapping between these two models would need to take place in our data source.

protocol TodoDataSource{
 func getAll() async throws -> [Todo]
 func getById(_ id: UUID) async throws -> Todo?
 func delete(_ id: UUID) async throws -> ()
 func create(todo: Todo) async throws -> ()
 func update(id: UUID, todo: Todo) async throws -> ()
}

This time around we need a persistence framework for our data source. Here we’re going to use Core Data to save your application’s permanent data for offline use.

Create a CoreData Model by adding a new file and choosing Core Data -> Data Model and creating at TodoCoreDataEntity:

To use the CoreData Main Model we can create a data source that conforms to the TodoDataSource and uses the NSPersitanceContainer.

import Foundation
import CoreData

struct TodoCoreDataSourceImpl: TodoDataSource {

    let container: NSPersistentContainer

    init(){
        container = NSPersistentContainer(name: "Main")
        container.loadPersistentStores { description, error in
            if error != nil {
                fatalError("Cannot Load Core Data Model")
            }
        }
    }

    func getAll() throws -> [Todo]{
        let request = TodoCoreDataEntity.fetchRequest()
        return try container.viewContext.fetch(request).map({ todoCoreDataEntity in
            Todo(
                id: todoCoreDataEntity.id!,
                 title: todoCoreDataEntity.title!,
                isCompleted: todoCoreDataEntity.is_completed
            )
        })

    }

    func getById(_ id: UUID)  throws  -> Todo?{
        let todoCoreDataEntity = try getEntityById(id)!
        return Todo(
            id: todoCoreDataEntity.id!,
            title: todoCoreDataEntity.title!,
            isCompleted: todoCoreDataEntity.is_completed
        )

    }

    func delete(_ id: UUID) throws -> (){
        let todoCoreDataEntity = try getEntityById(id)!
        let context = container.viewContext;
        context.delete(todoCoreDataEntity)
        do{
            try context.save()
        }catch{
            context.rollback()
            fatalError("Error: \(error.localizedDescription)")
        }

    }

    func update(id: UUID, todo: Todo) throws -> (){
        let todoCoreDataEntity = try getEntityById(id)!
        todoCoreDataEntity.is_completed = todo.isCompleted
        todoCoreDataEntity.title = todo.title
        saveContext()
    }

    func create(todo: Todo) throws -> (){
        let todoCoreDataEntity = TodoCoreDataEntity(context: container.viewContext)
        todoCoreDataEntity.is_completed = todo.isCompleted
        todoCoreDataEntity.title = todo.title
        todoCoreDataEntity.id = todo.id
        saveContext()
    }


    private func getEntityById(_ id: UUID)  throws  -> TodoCoreDataEntity?{
        let request = TodoCoreDataEntity.fetchRequest()
        request.fetchLimit = 1
        request.predicate = NSPredicate(
            format: "id = %@", id.uuidString)
        let context =  container.viewContext
        let todoCoreDataEntity = try context.fetch(request)[0]
        return todoCoreDataEntity

    }

    private func saveContext(){
        let context = container.viewContext
        if context.hasChanges {
            do{
                try context.save()
            }catch{
                fatalError("Error: \(error.localizedDescription)")
            }
        }
    }

}

and then lastly, our TodoRepositoryImpl would implement our TodoRepository and call our Datasource:

protocol TodoRepository {
 func getTodos() async -> Result<[Todo], TodoError>
 func getTodo(id: UUID) async -> Result<Todo? , TodoError>
 func deleteTodo(_ id: UUID) async -> Result<Bool, TodoError>
 func createTodo(_ todo: Todo) async -> Result<Bool, TodoError>
 func updateTodo(_ todo: Todo) async -> Result<Bool, TodoError>
}

enum TodoError: Error{
 case DataSourceError, CreateError, DeleteError, UpdateError, FetchError
}

import Foundation

struct TodoRepositoryImpl: TodoRepository{

    var dataSource: TodoDataSource

    func getTodo(id: UUID) async  -> Result<Todo?, TodoError> {
        do{
            let _todo =  try await dataSource.getById(id)
            return .success(_todo)
        }catch{
            return .failure(.FetchError)
        }

    }

    func deleteTodo(_ id: UUID) async ->  Result<Bool, TodoError>  {
        do{
            try await dataSource.delete(id)
            return .success(true)
        }catch{
            return .failure(.DeleteError)
        }

    }

    func createTodo(_ todo: Todo) async ->  Result<Bool, TodoError>   {
        do{
            try await dataSource.create(todo: todo)
            return .success(true)
        }catch{
            return .failure(.CreateError)
        }

    }

    func updateTodo(_ todo: Todo) async ->  Result<Bool, TodoError>   {
        do{
            try await dataSource.update(id: todo.id, todo:todo)
            return .success(true)
        }catch{
            return .failure(.UpdateError)
        }

    }

    func getTodos() async -> Result<[Todo], TodoError> {
        do{
            let _todos =  try await dataSource.getAll()
            return .success(_todos)
        }catch{
            return .failure(.FetchError)
        }
    }
}

The folder/group structure of the project takes on the following form:

├── Core
├── Data
├── Domain
└── Presentation

Let’s start with the Domain Layer.

This layer describes WHAT your project/application does. Let me explain, Many applications are built and structured in a way that you cannot understand what the application does by merely looking at the folder structure. Using a building of a house analogy, you can quickly identify what a building would look like and its functionality by viewing the floor plan and elevation of the building

In the same way, the domain layer of our project should specify and describe WHAT our application does. In this folder, we would use models, repository interfaces, and use cases.

├── Core
├── Data
├── Presentation
└── Domain
    ├── Model
    │   ├── Todo.ts
    │   └── User.ts
    ├── Repository
    │   ├── TodoRepository.ts
    │   └── UserRepository.ts
    └── UseCase
        ├── Todo
        │   ├── GetTodos.ts
        │   ├── GetTodo.ts
        │   ├── DeleteTodo.ts
        │   ├── UpdateTodo.ts
        │   └── CreateTodo.ts
        └── User
            ├── GetUsers.ts
            ├── GetUser.ts
            ├── DeleteUser.ts
            ├── UpdateUser.ts
            └── CreateUser.ts

1. Model: A model typically represents a real-world object that is related to the problem. In this folder, we would typically keep classes to represent objects. e.g. Todo, User, Product, etc
2. Repository: Container for all repository interfaces. The repository is a central place to keep all model-specific operations. In this case, the Todo repository interface would describe repository methods. The actual repository implementation will be kept in the Data layer.
3. UseCases: Container to list all functionality of our application. e.g Get Todos, Delete Todo, Create Todo, Update Todo

The PRESENTATION layer will keep all of the consumer-related code as to HOW the application will interact with the outside world. The presentation layer can be WebForms, Command Line Interface, API Endpoints, etc. In this case, it would be the screens for a List of Todos and its accompanying view model.

├── Core
├── Data
├── Domain
└── Presentation
    └── Todo
        └── TodoList
            ├── TodoListViewModel.tsx
            └── TodoListView.tsx

The DATA layer will keep all the external dependency-related code as to HOW they are implemented:

├── Core
├── Domain
├── Presentation
└── Data
    ├── Repository
    │   ├── TodoRepositoryImpl.ts
    └── DataSource
        ├── TodoDataSource.ts
        ├── API
        │   ├── TodoAPIDataSourceImpl.ts
        │   └── Entity
        │       ├── TodoAPIEntity.ts
        │       └── UserAPIEntity.ts
        └── DB
            ├── TodoDBDataSourceImpl.ts
            └── Entity
                ├── TodoDBEntity.ts
                └── UserDBEntity.ts

1. Repository: Repository implementations
2. DataSource: All data source interfaces and entities. An entity represents a single instance of your domain object saved into the database as a record. It has some attributes that we represent as columns in our DB tables or API endpoints. We can’t control how data is modeled on the external data source, so these entities are required to be mapped from entities to domain models in the implementations

and lastly, the CORE layer keep all the components that are common across all layers like constants or configs or dependency injection (which we won’t cover) Our first task would be always to start with the domain models and data entities. Let’s start with the model

//Domain/Model/Todo.ts
export interface Todo {
  id: number;
  title: string;
  isComplete: boolean;
}

We need it to conform to Identifiable as we’re going to display these items in a list view.

Next, let’s do the todo entity

//Data/DataSource/API/Entity/TodoAPIEntity.ts
export interface TodoAPIEntity {
  id: number;
  title: string;
  completed: boolean;
}

Let’s now write an interface for the TodoDatasource

//Data/DataSource/TodoDataSource.ts
import { Todo } from "../../Domain/Model/Todo";

export default interface TodoDataSource {
  getTodos(): Promise<Todo[]>;
}

We have enough to write an implementation of this interface and we’ll call it TodoAPIImpl:

import { Todo } from "../../../Domain/Model/Todo";
import TodoDataSource from "../TodoDataSource";
import { TodoAPIEntity } from "./Entity/TodoAPIEntity";

const BASE_URL = "https://jsonplaceholder.typicode.com";

interface TypedResponse<T = any> extends Response {
  json<P = T>(): Promise<P>;
}

function myFetch<T>(...args: any): Promise<TypedResponse<T>> {
  return fetch.apply(window, args);
}

export default class TodoAPIDataSourceImpl implements TodoDataSource {
  async getTodos(): Promise<Todo[]> {
    let response = await myFetch<TodoAPIEntity[]>(`${BASE_URL}/todos`);
    let data = await response.json();
    return data.map((item) => ({
      id: item.id,
      title: item.title,
      isComplete: item.completed,
    }));
  }
}

Note: this data source's getTodos function returns a list of Todo. So, we have to map TodoEntity -> Todo: Before we write our TodoRepositoryImpl let’s write the interface for that in the Domain layer

//Domain/Repository/TodoRepository.ts
import { Todo } from "../Model/Todo";

export interface TodoRepository {
  getTodos(): Promise<Todo[]>;
}

//Data/Repository/TodoRepositoryImpl.ts
import { Todo } from "../../Domain/Model/Todo";
import { TodoRepository } from "../../Domain/Repository/TodoRepository";
import TodoDataSource from "../DataSource/TodoDataSource";

export class TodoRepositoryImpl implements TodoRepository {
  dataSource: TodoDataSource;

  constructor(_datasource: TodoDataSource) {
    this.dataSource = _datasource;
  }

  async getTodos(): Promise<Todo[]> {
    return this.dataSource.getTodos();
  }
}

Now that we have our todo repository, we can code up the GetTodos use case

//Domain/UseCase/GetTodos.ts
import { Todo } from "../Model/Todo";
import { TodoRepository } from "../Repository/TodoRepository";

export interface GetTodos {
  invoke(): Promise<Todo[]>;
}

export class GetTodosUseCase implements GetTodos {
  private todoRepo: TodoRepository;

  constructor(_todoRepo: TodoRepository) {
    this.todoRepo = _todoRepo;
  }
  async invoke(): Promise<Todo[]> {
    return this.todoRepo.getTodos();
  }
}

and then in turn we can write our presentation’s view model and view

//Presentation/View/Todo/TodoListViewModel.ts
import { useState } from "react";
import TodoAPIDataSourceImpl from "../../../Data/DataSource/API/TodoAPIDataSourceImpl";
import { TodoRepositoryImpl } from "../../../Data/Repository/TodoRepositoryImpl";
import { Todo } from "../../../Domain/Model/Todo";
import { GetTodosUseCase } from "../../../Domain/UseCase/GetTodos";

export default function TodoViewModel() {
  const [todos, setTodos] = useState<Todo[]>([]);

  const UseCase = new GetTodosUseCase(
    new TodoRepositoryImpl(new TodoAPIDataSourceImpl())
  );

  async function getTodos() {
    setTodos(await UseCase.invoke());
  }

  return {
    getTodos,
    todos,
  };
}

//Presentation/Views/Todo/TodoListView.ts
import { useEffect } from "react";
import useViewModel from "./TodoListViewModel";
import {
  List,
  ListItem,
  ListItemIcon,
  Checkbox,
  ListItemText,
} from "@mui/material";

export default function TodoView() {
  const { getTodos, todos } = useViewModel();

  useEffect(() => {
    getTodos();
  }, []);

  return (
    <List>
      {todos.map((todo, i) => {
        return (
          <ListItem key={i}>
            <ListItemIcon>
              <Checkbox checked={todo.isComplete} />
            </ListItemIcon>
            <ListItemText primary={todo.title} />
          </ListItem>
        );
      })}
    </List>
  );
}

So to recap:

Let’s say we have a 3 layer dependency:

Of course, we can use good old manual dependency injection as follows:

class TodoListViewModel: ObservableObject {
    var getTodosUseCase = GetTodosUseCase(
        repo: TodoRepositoryImpl(
            dataSource: TodoDataSourceImpl()
        )
    )
....
}

class TodoListViewModel: ObservableObject {
    @Inject
    private var getTodosUseCase : GetTodos
....
}

This would allow us to control the external dependencies by simply decorating the property with the Inject annotation and specifying the interface.

So the first thing is the @Inject annotation. In Swift, we use a property wrapper. Since Swift 5.1, the property wrapper feature enables us to attach logic directly to the property itself. Here we create a property wrapper called “Inject” that will automatically assign something to the prop

@propertyWrapper
struct Inject<I> {
    let wrappedValue: I
    init() {
        //Resolve the interface to an implementation.
        self.wrappedValue = Resolver.shared.resolve(I.self)
    }
}

Let’s build the resolver

class Resolver {
    static let shared = Resolver()

    //get the IOC container
    private var container = buildContainer() 

    func resolve<T>(_ type: T.Type) -> T {
        container.resolve(T.self)!
    }
}

All we now need is an IOC container. Let’s use Swinject to build one to resolve all interfaces to their respective implementations:

import Swinject
func buildContainer() -> Container {
    let container = Container()
    container.register(GetTodos.self) { _  in
        return GetTodosUseCase()
    }.inObjectScope(.container)
    container.register(TodoDataSource.self) { _  in
        return TodoMockDataSourceImpl()
    }.inObjectScope(.container)
    container.register(TodoRepository.self) { _  in
        return TodoRepositoryImpl()
    }.inObjectScope(.container)
    return container
}

The Todo APIService

We need to create an API service to send the network requests. We will use URLSession. Here we have one method to fetch all todo item and deserialise them to [TodoItem]

import Foundation

struct TodoItem: Identifiable, Codable {
    let id: Int
    let title: String
    let completed: Bool
}

enum APIError: Error{
    case invalidUrl, requestError, decodingError, statusNotOk
}

let BASE_URL: String = "https://jsonplaceholder.typicode.com"

struct APIService {

    func getTodos() async throws -> [TodoItem] {

        guard let url = URL(string:  "\(BASE_URL)/todos") else{
            throw APIError.invalidUrl
        }

        guard let (data, response) = try? await URLSession.shared.data(from: url) else{
            throw APIError.requestError
        }

        guard let response = response as? HTTPURLResponse, response.statusCode == 200 else{
            throw APIError.statusNotOk
        }

        guard let result = try? JSONDecoder().decode([TodoItem].self, from: data) else {
            throw APIError.decodingError
        }

        return result
    }

}

The Todo ViewModel

The view model in turn uses the API Service to fetch todos to then publish

import Foundation

@MainActor
class TodoViewModel: ObservableObject {

    @Published var todos: [TodoItem] = []
    @Published var errorMessage = ""
    @Published var hasError = false


    func getTodos() async {
        guard let data = try?  await  APIService().getTodos() else {
            self.todos = []
            self.hasError = true
            self.errorMessage  = "Server Error"
            return
        }

        self.todos = data

    }
}

The Todo View

Finally we have the view which watches the ViewModel for any todo list state changes. The todo list is display in the view. On list appear the view makes the api call.

import SwiftUI

struct TodoList: View {
    @StateObject var vm = TodoViewModel()

    var body: some View {
        List{
            ForEach(vm.todos){todo in
                HStack{
                    Image(systemName: todo.completed ? "checkmark.circle": "circle")
                        .foregroundColor(todo.completed ? .green : .red)
                    Text("\(todo.title)")
                }
            }
        }
        .task {
            await vm.getTodos()
        }
        .listStyle(PlainListStyle())
        .navigationTitle("Todos")

    }
}

The package structure of the project takes on the following form:

├── Core
├── Data
├── Domain
└── Presentation

Let’s start with the Domain Layer.

This layer describes WHAT your project/application does. Let me explain, Many applications are built and structured in a way that you cannot understand what the application does just by looking at the folder structure. Using a building of a house analogy, you can quickly identify what a building would look like and its functionality by viewing the floor plan and elevation of the building

In the same way, the domain layer of our project should specify and describe WHAT our application does. In this folder, we would keep use models, repository interfaces, and use cases.

├── Core
├── Data
├── Presentation
└── Domain
    ├── Model
    │   ├── Todo.kt
    │   └── User.kt
    ├── Repository
    │   ├── TodoRepository.kt
    │   └── UserRepository.kt
    └── UseCase
        ├── Todo
        │   ├── GetTodos.kt
        │   ├── GetTodo.kt
        │   ├── DeleteTodo.kt
        │   ├── UpdateTodo.kt
        │   └── CreateTodo.kt
        └── User
            ├── GetUsers.kt
            ├── GetUser.kt
            ├── DeleteUser.kt
            ├── UpdateUser.kt
            └── CreateUser.kt

1. Model: A model typically represents a real-world object that is related to the problem. In this folder, we would typically keep classes to represent objects. e.g. Todo, User, etc

2. Repository: Container for all repository interfaces. The repository is a central place to keep all model-specific operations. In this case, the Todo repository interface would describe repository methods. The actual repository implementation will be kept in the Data layer.

3. UseCases: Container to list all functionality of our application. e.g Get, Delete, Create , Update

The PRESENTATION layer will keep all of the consumer-related code as to HOW the application will interact with the outside world. The presentation layer can be WebForms, Command Line Interface, API Endpoints, etc. In this case, it would be the screens for a List of Todos and its accompanying view model.

├── Core
├── Data
├── Domain
└── Presentation
    └── Todo
        └── TodoList
            ├── TodoListViewModel.kt
            └── TodoListView.kt

The DATA layer will keep all the external dependency-related code as to HOW they are implemented:

├── Core
├── Domain
├── Presentation
├── Data
    ├── Repository
    │   ├── TodoRepositoryImpl.kt
    │   ├── TodoAPIDataSourceImpl.kt
    │   └── TodoDBDataSourceImpl.kt
    └── DataSource
        ├── API
        │   ├── TodoAPIDataSource.kt.
        │   └── Entity
        │       ├── TodoAPIEntity.kt
        │       └── UserAPIEntity.kt
        └── DB
            ├── TodoDBDataSource.kt.
            └── Entity
                ├── TodoDBEntity.kt
                └── UserDBEntity.kt

1. Repository: Repository implementations

2. DataSource: All data source interfaces and entities. An entity represents a single instance of your domain object saved into the database as a record. It has some attributes that we represent as columns in our DB tables or API endpoints. We can’t control how data is modeled on the external data source, so these entities are required to be mapped from entities to domain models in the implementations

and lastly, the CORE layer keep all the components that are common across all layers like constants or configs or dependency injection (which we won’t cover)

Our first task would be always to start with the domain models and data entities

data class Todo(
    val id: Int,
    val isCompleted: Boolean,
    val task: String

)

data class TodoAPIEntity(
    val id: Int,
    val completed: Boolean,
    val title: String
)

fun TodoAPIEntity.toTodo(): Todo {
    return Todo(
        id = id,
        isCompleted = completed,
        task = title
    )
}

Let’s now write an interface for the TodoDatasource. We need one to enforce how any data source (API, DB, etc) needs to behave.

interface TodoDataSource {    
    suspend fun getTodos(): List<Todo>
}

We have enough to write an implementation of this interface and we’ll call it TodoAPIImpl:

import toTodo
import za.co.nanosoft.cleantodo.Data.DataSource.TodoAPI
import za.co.nanosoft.cleantodo.Data.DataSource.TodoDataSource
import za.co.nanosoft.cleantodo.Domain.Model.Todo


interface TodoApi {

    @GET("todos")
    suspend fun getTodos(): List<TodoAPIEntity>

    companion object {
        var todoApi: TodoApi? = null
        fun getInstance(): TodoApi {
            if (todoApi == null) {
                todoApi = Retrofit.Builder()
                    .baseUrl(BASE_URL)
                    .addConverterFactory(GsonConverterFactory.create())
                    .build().create(TodoApi::class.java)
            }
            return todoApi!!
        }
    }
}

class TodoAPIImpl : TodoDataSource {

    override suspend fun getTodos(): List<Todo> {
        return TodoAPI.getInstance().getTodos().map { it.toTodo() }
    }
}

Note: this repository’s getTodos function returns a list of Todo. So, we have to map TodoAPIEntity -> Todo:

Before we write our TodoRepositoryImpl let’s write the interface for that in the Domain layer

import za.co.nanosoft.cleantodo.Domain.Model.Todo

interface TodoRepository {
    suspend fun getTodos(): List<Todo>

}

We can now see that the TodoRepositoryImpl can take any datasource as a dependency, great for swapping out datasources.

Now that we have our todo repository, we can code up the GetTodos use case

import za.co.nanosoft.cleantodo.Domain.Model.Todo
import za.co.nanosoft.cleantodo.Domain.Repository.TodoRepository

class GetTodos(
    private val repository: TodoRepository
) {
    suspend operator fun invoke(): List<Todo> {
        return repository.getTodos()
    }
}

and then in turn we can write our presentation’s view model and view

import androidx.compose.runtime.mutableStateListOf
import androidx.lifecycle.ViewModel
import androidx.lifecycle.viewModelScope
import kotlinx.coroutines.launch
import za.co.nanosoft.cleantodo.Domain.Model.Todo
import za.co.nanosoft.cleantodo.Domain.UseCase.GetTodos

class TodoViewModel constructor(
    private val getTodosUseCase: GetTodos
) : ViewModel() {
    private val _todos = mutableStateListOf<Todo>()

    val todos: List<Todo>
        get() = _todos


    suspend fun getTodos() {
        viewModelScope.launch {
            _todos.addAll(getTodosUseCase())
        }
    }
}

@Composable
fun TodoListView(vm: TodoViewModel) {

    LaunchedEffect(Unit, block = {
        vm.getTodos()
    })

    Scaffold(
        topBar = {
            TopAppBar(
                title = {
                    Text("Todos")
                }
            )
        },
        content = {
            Column(modifier = Modifier.padding(16.dp)) {
                LazyColumn(modifier = Modifier.fillMaxHeight()) {
                    items(vm.todos) { todo ->
                        Row(modifier = Modifier.padding(16.dp)) {
                            Checkbox(checked = todo.isCompleted, onCheckedChange = null)
                            Spacer(Modifier.width(5.dp))
                            Text(todo.task)
                        }
                        Divider()
                    }
                }
            }
        }
    )
}

So to recap:

The folder/group structure of the project takes on the following form:

├── Core
├── Data
├── Domain
└── Presentation

Let’s start with the Domain Layer. This layer describes WHAT your project/application does. Let me explain, Many applications are built and structured in a way that you cannot understand what the application does just by looking at the folder structure. Using a building of a house analogy, you can quickly identify what a building would look like and its functionality by viewing the floor plan and elevation of the building

In the same way, the domain layer of our project should specify and describe WHAT our application does. In this folder, we would keep use models, repository interfaces, and use cases.

├── Core
├── Data
├── Presentation
└── Domain
    ├── Model
    │   ├── Todo.swift
    │   └── User.swift
    ├── Repository
    │   ├── TodoRepository.swift
    │   └── UserRepository.swift
    └── UseCase
        ├── Todo
        │   ├── GetTodos.swift
        │   ├── GetTodo.swift
        │   ├── DeleteTodo.swift
        │   ├── UpdateTodo.swift
        │   └── CreateTodo.swift
        └── User
            ├── GetUsers.swift
            ├── GetUser.swift
            ├── DeleteUser.swift
            ├── UpdateUser.swift
            └── CreateUser.swift

1. Model: A model typically represents a real-world object that is related to the problem. In this folder, we would typically keep classes to represent objects. e.g. Todo, User, Product, etc
2. Repository: Container for all repository interfaces. The repository is a central place to keep all model-specific operations. In this case, the Todo repository interface would describe repository methods. The actual repository implementation will be kept in the Data layer.
3. UseCases: Container to list all functionality of our application. e.g Get Todos, Delete Todo, Create Todo, Update Todo

The PRESENTATION layer will keep all of the consumer-related code as to HOW the application will interact with the outside world. The presentation layer can be WebForms, Command Line Interface, API Endpoints, etc. In this case, it would be the screens for a List of Todos and its accompanying view model.

├── Core
├── Data
├── Domain
└── Presentation
    └── Todo
        └── TodoList
            ├── TodoListViewModel.swift
            └── TodoListView.swift

The DATA layer will keep all the external dependency-related code as to HOW they are implemented:

├── Core
├── Domain
├── Presentation
└── Data
    ├── Repository
    │   ├── TodoRepositoryImpl.swift
    └── DataSource
        ├── TodoDataSource.swift
        ├── API
        │   ├── TodoAPIDataSourceImpl.swift
        │   └── Entity
        │       ├── TodoAPIEntity.swift
        │       └── UserAPIEntity.swift
        └── DB
            ├── TodoDBDataSourceImpl.swift
            └── Entity
                ├── TodoDBEntity.swift
                └── UserDBEntity.swift

1. Repository: Repository implementations
2. DataSource: All data source interfaces and entities. An entity represents a single instance of your domain object saved into the database as a record. It has some attributes that we represent as columns in our DB tables or API endpoints. We can’t control how data is modelled on the external data source, so these entities are required to be mapped from entities to domain models in the implementations

and lastly, the CORE layer keep all the components that are common across all layers like constants or configs or dependency injection (which we won’t cover) Our first task would be always to start with the domain models and data entities. Let’s start with the model

struct Todo: Identifiable {
    let id: Int
    let title: String
    let isCompleted: Bool
}

We need it to conform to Identifiable as we’re going to display these items in a list view. Next let’s do the todo entity

struct TodoAPIEntity: Codable {
    let id: Int
    let title: String
    let completed: Bool
}

Let’s now write an interface (protocol) for the TodoDatasource

protocol TodoDataSource{   
    func getTodos() async throws -> [Todo]   
}

We have enough to write an implementation of this protocol and we’ll call it TodoAPIDataSourceImpl:

enum APIServiceError: Error{
    case badUrl, requestError, decodingError, statusNotOK
}

struct TodoAPIDataSourceImpl: TodoDataSource{


    func getTodos() async throws -> [Todo] {

        guard let url = URL(string:  "\(Constants.BASE_URL)/todos") else{
            throw APIServiceError.badUrl
        }

        guard let (data, response) = try? await URLSession.shared.data(from: url) else{
            throw APIServiceError.requestError
        }

        guard let response = response as? HTTPURLResponse, response.statusCode == 200 else{
            throw APIServiceError.statusNotOK
        }

        guard let result = try? JSONDecoder().decode([TodoAPIEntity].self, from: data) else {
            throw APIServiceError.decodingError
        }

        return result.map({ item in
            Todo(
                id: item.id,
                title: item.title,
                isCompleted: item.completed
            )
        })
    }
}

Note: this repository’s getTodos function returns a list of Todo. So, we have to map TodoEntity -> Todo: Before we write our TodoRepositoryImpl let’s write the protocol for that in the Domain layer

protocol TodoRepository{   
    func getTodos() async throws -> [Todo]   
}

struct TodoRepositoryImpl: TodoRepository{

    var dataSource: TodoDataSource

    func getTodos() async throws -> [Todo] {
        let _todos =  try await dataSource.getTodos()
        return _todos
    }
}

Now that we have our todo repository, we can code up the GetTodos use case

enum UseCaseError: Error{
    case networkError, decodingError
}

struct GetTodosUseCase{
    var repo: TodoRepository

    func execute() async -> Result<[Todo], UseCaseError>{
        do{
            let todos = try await repo.getTodos()
            return .success(todos)
        }catch(let error){
            switch(error){
            case APIServiceError.decodingError:
                return .failure(.decodingError)
            default:
                return .failure(.networkError)
            }
        }
    }
}

and then in turn we can write our presentation’s view model and view

@MainActor
class TodoListViewModel: ObservableObject {

    var getTodosUseCase = GetTodosUseCase(repo: TodoRepositoryImpl(dataSource: TodoAPISourceImpl()))
    @Published var todos: [Todo] = []
    @Published var errorMessage = ""
    @Published var hasError = false

    func getTodos() async {
        errorMessage = ""
        let result = await getTodosUseCase.execute()
        switch result{
        case .success(let todos):
            self.todos = todos
        case .failure(let error):
            self.todos = []
            errorMessage = error.localizedDescription
            hasError = true
        }
    }
}

Note: We use the @MainActor attribute for the view model class because we need to run these functions on the main thread, a singleton actor whose executor is equivalent to the main dispatch queue.

struct TodoListView: View {
    @StateObject var vm = TodoListViewModel()


    fileprivate func listRow(_ todo: Todo) -> some View {
        HStack{
            Image(systemName: todo.isCompleted ? "checkmark.circle": "circle")
                .foregroundColor(todo.isCompleted ? .green : .red)
            Text("\(todo.title)")
        }
    }

    fileprivate func TodoList() -> some View {
        List {
            ForEach(vm.todos){ item in
                listRow(item)
            }
        }
        .navigationTitle("Todo List")
        .task {
           await vm.getTodos()
        }
        .alert("Error", isPresented: $vm.hasError) {
        } message: {
            Text(vm.errorMessage)
        }
    }

    var body: some View {
       TodoList()
    }
}

struct TodoListView_Previews: PreviewProvider {
    static var previews: some View {
        NavigationView{
        TodoListView()
        }.navigationViewStyle(StackNavigationViewStyle())
    }
}

So to recap:

Sample Model

import Foundation

struct User: Identifiable {
    let id: UUID
    let name: String
}

struct UserModel{
    private(set) var users :[User] = []

    mutating func addUser(_ user: User){
        users.append(user)
    }
}

We define a User model. The model has 2 members, a privately changeable users list and a mutating function to change the state of the user's collection. Note the User struct conforms to the Identifiable protocol. SwiftUI needs to know how it can identify each item uniquely otherwise it’s not able to compare view hierarchies to figure out what has changed when a new body is re-built in the view.

Sample ViewModel

This should contain everything one would need to interact with the view. Right now it contains 2 members: users, and an addUser function.

import Foundation
import UIKit


class UserViewModel: ObservableObject{
    @Published private var userModel =  UserModel()

    var users: [User] {
        return userModel.users
    }

    func addUser(_ user: User){
        userModel.addUser(user)
    }
}

Sample View

And now the View. These are DataTemplates that define how data should be displayed.

import SwiftUI

struct UserView: View {
   @ObservedObject var viewModel = UserViewModel()

    var body: some View {
        NavigationView{
            List(viewModel.users) { user in
                VStack(alignment: .leading){
                    Text("\(user.name)")
                    Text("\(user.id)")
                }
            }
            .navigationTitle("Users")
            .toolbar {
                Button(action: {
                    viewModel.addUser(User(id: UUID(),name: "User"))
                }) {
                    Image(systemName: "plus")
                }
            }
            .listStyle(PlainListStyle())
        }
    }
}

Anything that conforms to ObservableObject can be used inside SwiftUI, and publish announcements when its values have changed so the View can be updated. Clicking the add button will add User Objects to the collection which will cause the view to be rebuilt as shown here:

Firstly, Add Internet Permission to your Application in AndroidManifest.xml

<uses-permission android:name="android.permission.INTERNET"></uses-permission>

Before we start let’s update our build.gradle file with the Retrofit HTTP client and aConverter which uses Gson for serialisation to and from JSON.:

dependencies{
...
    implementation "com.squareup.retrofit2:retrofit:2.9.0"
    implementation "com.squareup.retrofit2:converter-gson:2.0.0"
}

The Todo APIService

We need to create the Retrofit instance to send the network requests. We need to use the Retrofit Builder class and specify the base URL for the service. Here we have one GET to fetch all Todos and deserialise to List

data class Todo(
    var userId: Int,
    var id: Int,
    var title: String,
    var completed: Boolean
)

const val BASE_URL = "https://jsonplaceholder.typicode.com/"

interface APIService {
    @GET("todos")
    suspend fun getTodos(): List<Todo>

    companion object {
        var apiService: APIService? = null
        fun getInstance(): APIService {
            if (apiService == null) {
                apiService = Retrofit.Builder()
                    .baseUrl(BASE_URL)
                    .addConverterFactory(GsonConverterFactory.create())
                    .build().create(APIService::class.java)
            }
            return apiService!!
        }
    }
}

The Todo ViewModel

The View model publishes the todoList and has a getTodoList function to fetch all todos

class TodoViewModel : ViewModel() {
    private val _todoList = mutableStateListOf<Todo>()
    var errorMessage: String by mutableStateOf("")
    val todoList: List<Todo>
        get() = _todoList

    fun getTodoList() {
        viewModelScope.launch {
            val apiService = APIService.getInstance()
            try {
                _todoList.clear()
                _todoList.addAll(apiService.getTodos())

            } catch (e: Exception) {
                errorMessage = e.message.toString()
            }
        }
    }
}

The Todo View

Finally we have the view which observes the ViewModel for any todo list state changes. When changes are detected the composable rebuilds. The todo list is displayed in the view.

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        val vm = TodoViewModel()
        super.onCreate(savedInstanceState)
        setContent {
            MaterialTheme {
                TodoView(vm)
            }
        }
    }
}

@Composable
fun TodoView(vm: TodoViewModel) {

    LaunchedEffect(Unit, block = {
        vm.getTodoList()
    })

    Scaffold(
        topBar = {
            TopBar()
        },
        content = {
            if (vm.errorMessage.isEmpty()) {
                TodoList(vm)
            } else {
                Text(vm.errorMessage)
            }
        }
    )
}

@Composable
private fun TodoList(vm: TodoViewModel) {
    Column(modifier = Modifier.padding(16.dp)) {
        LazyColumn(modifier = Modifier.fillMaxHeight()) {
            items(vm.todoList) { todo ->
                Column {
                    Row(
                        modifier = Modifier
                            .fillMaxWidth()
                            .padding(16.dp),
                        horizontalArrangement = Arrangement.SpaceBetween
                    ) {
                        Box(
                            modifier = Modifier
                                .fillMaxWidth()
                                .padding(0.dp, 0.dp, 16.dp, 0.dp)
                        ) {
                            Text(
                                todo.title,
                                maxLines = 1,
                                overflow = TextOverflow.Ellipsis
                            )
                        }
                        Spacer(modifier = Modifier.width(16.dp))
                        Checkbox(checked = todo.completed, onCheckedChange = null)
                    }
                    Divider()
                }
            }
        }
    }
}

@Composable
private fun TopBar() {
    TopAppBar(
        title = {
            Row {
                Text("Todos")
            }
        })
}

I’ve put together a small sample showing these 3 layers and how they relate to each other in JetPack Compose. You’ll notice that other than property/method names, none of the objects need to know anything about the others. Each layer can be built completely independent of the others.

Sample Model

import java.util.*

data class User(
    var id: UUID,
    var name: String
)

Sample ViewModel

This should contain everything one would need to interact with the view. Right now it contains 2 members: users, and an addUser function. Note we’re using mutableStateListOf to maintain state of a collection of users in the view model.

import androidx.compose.runtime.*
import androidx.lifecycle.ViewModel

class UserViewModel : ViewModel() {
    private val _users = mutableStateListOf<User>()

    val users: List<User>
        get() = _users

    fun addUser(user: User) {
        _users.add(user)
    }
}

Sample View

And now the View. These are DataTemplates that define how data should be displayed. ViewModels survive configuration changes, so they allow you to encapsulate state and events related to the UI without having to deal with the activity or fragment lifecycle that hosts your Compose code.

@Composable
fun UserView() {
    val vm by remember { mutableStateOf(UserViewModel()) }
    Scaffold(
        topBar = {
            TopAppBar(
                title = { Text("Users") },
                actions = {
                    IconButton(onClick = {
                        vm.addUser(User(UUID.randomUUID(), "User"))
                    }) {
                        Icon(Icons.Filled.Add, null)
                    }
                })
        },
        content = {
            Column(modifier = Modifier.padding(16.dp)) {
                LazyColumn(modifier = Modifier.fillMaxHeight()) {
                    items(vm.users) {
                        Column {
                            Text(it.name)
                            Text("${it.id}")
                        }

                    }
                }
            }
        }
    )
}

We can hoist the ViewModel further up the Compose UI tree to maintain a more global state as follows:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val vm = UserViewModel()
        setContent {
            MaterialTheme {
                UserView(vm)
            }
        }
    }
}

@Composable
fun UserView(vm: UserViewModel) {
    Scaffold(
        topBar = {
            TopAppBar(
                title = { Text("Users") },
                actions = {
                    IconButton(onClick = {
                        vm.addUser(User(UUID.randomUUID(), "User"))
                    }) {
                        Icon(Icons.Filled.Add, null)
                    }
                })
        },
        content = {
            Column(modifier = Modifier.padding(16.dp)) {
                LazyColumn(modifier = Modifier.fillMaxHeight()) {
                    items(vm.users) {
                        Column {
                            Text(it.name)
                            Text("${it.id}")
                        }

                    }
                }
            }
        }
    )
}

When building a business application the 2 main navigation structures are Hierarchical and Flat.

Hierarchical

Users navigate by making only one choice per screen until they reach their destination. To get to another destination, users must either retrace, or start from the beginning and make other choices.

We use NavHostController to implement hierarchical navigation

Add this to your project by updating your app module’s build.gradle dependencies

dependencies {
    ...
    implementation("androidx.navigation:navigation-compose:2.4.0-alpha10")
}

Then create a Router component to do all route management. Within this router we map 2 screens to 2 routes: “screen1" and “child1". We keep track of all nav state through a hoisted navController state which is passed down to all routed components.

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            val navController = rememberNavController()
            MaterialTheme {
                Router(navController)
            }
        }
    }
}

@Composable
fun Router(navController: NavHostController) {
    NavHost(
        navController = navController,
        startDestination = "screen1"
    ) {
        composable("screen1") {
            Screen1(navController)
        }
        composable("child1") {
            Child1(navController)
        }
    }
}

@Composable
fun Screen1(navController: NavController) {
    Scaffold(
        topBar = { TopAppBar(title = { Text("Screen 1") }) },
        content = {
            Box(modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center ){
                Button(onClick = { navController.navigate("child1") }) {
                    Text(text = "Go to Child of Screen 1")
                }
            }
        })
}

@Composable
fun Child1(navController: NavController) {
    Scaffold(
        topBar = {
            TopAppBar(
                title = { Text("Screen 1") },
                navigationIcon = {
                    IconButton(onClick = {
                        navController.popBackStack()
                    }) {
                        Icon(Icons.Filled.ArrowBack, null)
                    }
                })
        },
        content = {
            Box(modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center ){
                Text("This is the Child of Screen 1")
            }
        })
}

Clicking on the Button on Screen 1 will push the child screen onto Screen 1

Flat

Now let’s look at Flat navigation. All the primary screens can be navigated from the main screen. We’ll build and use a BottomNavigation Bar to implement flat navigation.

First Let’s add another screen (screen2) to the Router

@Composable
fun Router(navController: NavHostController) {
    NavHost(
        navController = navController,
        startDestination = "screen1"
    ) {
        composable("screen1") {
            Screen1(navController)
        }
        composable("screen2") {
            Screen2()
        }
        composable("child1") {
            Child1(navController)
        }
    }
}

@Composable
fun Screen2() {
    Scaffold(
        topBar = { TopAppBar(title = { Text("Screen 2") }) },
        content = {
            Box(modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
                Text(text = "Screen 2")
            }
        })
}

Now let’s create a BottomNavigationBar, a component that takes in a list of nav items, a nav controller, and an item click handler. It then loops through nav items to display them in within a BottomNavigation. Note the BottomNavigation returns a RowScope so all items rendered in this component will automatically be rendered in a row.

data class BottomNavItem(
    val name: String,
    val route: String,
    val icon: ImageVector
)


@Composable
fun BottomNavigationBar(
    items: List<BottomNavItem>,
    navController: NavHostController,
    modifier: Modifier = Modifier,
    onItemClick: (BottomNavItem) -> Unit
) {
    val backStackEntry = navController.currentBackStackEntryAsState();
    BottomNavigation(modifier = modifier) {
        items.forEach { item ->
            var selected = item.route == backStackEntry.value?.destination?.route
            BottomNavigationItem(
                selected = selected,
                onClick = { onItemClick(item) },
                selectedContentColor = Color(0xFFFFFFFF),
                unselectedContentColor = Color(0x88FFFFFF),
                icon = {
                    Column(horizontalAlignment = Alignment.CenterHorizontally) {
                        Icon(
                            imageVector = item.icon,
                            contentDescription = item.name
                        )
                        Text(text = item.name, textAlign = TextAlign.Center, fontSize = 10.sp)

                    }
                }
            )
        }
    }
}

The last step is to change the MainActivity to return a Scaffold with a bottomBar.

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            MaterialTheme {
                val navController = rememberNavController()
                Scaffold(
                    bottomBar = {
                        BottomNavigationBar(
                            items = listOf(
                                BottomNavItem(
                                    name = "Screen1",
                                    route = "screen1",
                                    icon = Icons.Filled.Home
                                ),
                                BottomNavItem(
                                    name = "Screen2",
                                    route = "screen2",
                                    icon = Icons.Filled.Settings
                                )
                            ),
                            navController = navController,
                            onItemClick = {
                                navController.navigate(it.route)
                            }
                        )
                    }
                ) {
                    Router(navController = navController)
                }
            }
        }
    }
}

Final result:

When building a business application the 2 main navigation structures are Hierarchical and Flat.

Hierarchical

Users navigate by making only one choice per screen until they reach their destination. To get to another destination, users must either retrace, or start from the beginning and make other choices.

We use NavigationView to implement hierarchical navigation

import SwiftUI


struct ChildView: View {
    var body: some View {
        Text("This is the Child of Screen 1")
    }
}

struct ContentView: View {
    var body: some View {
        NavigationView {
            NavigationLink(destination: ChildView()) {
                Text("Go To Child of Screen 1")
            }.navigationTitle("Screen 1")
        }.navigationViewStyle(StackNavigationViewStyle())
    }
}

Clicking on the Navigation Link will push the child screen onto Screen 1

Flat

All the primary screens can be navigated from the main screen.

We use TabViews to implement flat navigation.

import SwiftUI


struct ChildView: View {
    var body: some View {
        Text("This is the Child of Screen 1")
    }
}

struct Screen1View: View {
    var body: some View {
        NavigationView {
            NavigationLink(destination: ChildView()) {
                Text("Go To Child of Screen 1")

            }.navigationTitle("Screen 1")
        }.navigationViewStyle(StackNavigationViewStyle())
    }
}

struct Screen2View: View {
    var body: some View {
        NavigationView {
            Text("Screen 2").navigationTitle("Screen 2")
        }.navigationViewStyle(StackNavigationViewStyle())
    }
}

struct ContentView: View {
    var body: some View {
        TabView{
            Screen1View()
                .tabItem({
                    Label("One", systemImage: "1.circle")
                })
            Screen2View()
                .tabItem({
                    Label("Two", systemImage: "2.circle")
                })
        }
    }
}

We’ve now incorporated hierarchical nav inside of flat nav with a TabView and given the tabs labels and icons

To illustrate Dependency Injection, we’ll build an API with the following endpoints

1. GET /post: Gets all posts

2. POST /post: Creates a post

and structure the API in the following way:

1. Datasource — persistence implementation using third party modules.

2. Repository — decouple application from persistence: has a datasource dependency.

3. UseCase — business logic: has a repository dependency.

4. Presentation — routes: has a use-case dependency.

1. PostDataSource

The post datasource uses on third a party lib as shown in the require statement. (nedb is an embedded persistent database for Node. API is a subset of MongoDB)

2. PostRepository

The repository is a way of decoupling our datasource from the rest of our application. The datasource is therefore property injected into the repository. Once injected, all the functions within the repository now have access to this external dependency. This is using the closure feature within Javascript

A closure is a feature where an inner function has access to the outer (enclosing) function’s variables

3. CreatePost UseCase

As we’ve done with the post repository, the post repository is now property injected into the use-case.

Let’s now build the post router and see how we chain these dependencies.

4. Post Router

With the code above, we manually need to create and chain together the dependencies in order to produce a use-case object on which we run the execute command to produce the result the endpoint responds with.

We can simplify the process of manually managing dependencies by using an IoC container. IoC container (a.k.a. DI Container) is a framework for implementing automatic dependency injection. It manages object creation, and also injects dependencies.

Let us firstly create the container.

IoC Container

All dependencies are imported and registered here. We use the Awilix third party library to help use create the container

Let’s now revisit our router and replace manually dependency management with the use of the container.

Post Router with Container

And that’s it. We’ve now shown how we can use dependency injection in Javascript and without classes.