Kotlin
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Null Safety
-
Section 4: Object-Oriented Kotlin
-
Section 5: Functional Kotlin
-
Section 6: Coroutines
-
Section 7: Collections Deep Dive
-
Section 8: Type System Deep Dive
-
Section 9: Interop and Tooling
-
Section 10: Kotlin DSLs and Patterns
-
Section 11: Testing and Quality
-
Section 12: Server-Side Kotlin
-
Section 13: Practical Projects
-
Section 14: Interview Practice
-
Section 15: More Practice Exercises
-
Section 16: More Standard Library
-
Section 17: Multiplatform Kotlin
-
Section 18: kotlin.collections In Depth
-
Section 19: kotlin.text In Depth
-
Section 20: kotlin.ranges and kotlin.sequences
-
Section 21: kotlin.io and File Handling
-
Section 22: kotlinx.coroutines Deep Dive
-
Section 23: kotlin.reflect
-
Section 24: Android Development with Kotlin Overview
-
Section 25: Kotlin Multiplatform Deep Dive
-
Section 26: Kotlin for Backend Deep Dive
-
Section 27: Kotlin Design Patterns
-
Section 28: Advanced Language Features
-
Section 29: More Practice Exercises
-
Section 30: More Interview Practice
-
Section 31: Kotlin Type System Deep Dive
-
Section 32: Kotlin Null Safety Advanced
-
Section 33: Kotlin Testing Deep Dive
-
Section 34: Kotlin Build Tooling Deep Dive
-
Section 35: Kotlin Serialization
-
Section 36: Kotlin Performance Considerations
-
Section 37: Kotlin Native Overview
-
Section 38: Kotlin for Data and Scripting
-
Section 39: More Coroutines Practice
-
Section 40: More Android-Adjacent Patterns
-
Section 41: More Practical Projects
-
Section 42: More Design and Architecture Practice
-
Section 43: Kotlin Language Evolution
-
Section 44: More Interview and Review
-
Section 45: Kotlin Delegation Patterns Deep Dive
-
Section 46: Kotlin Annotations Deep Dive
-
Section 47: Kotlin for Gradle Plugin Development
-
Section 48: Kotlin Concurrency Beyond Coroutines
-
Section 49: Kotlin Compiler Internals
-
Section 50: Real-World Kotlin Case Studies
-
Section 51: Final Practice Projects
-
Section 52: Kotlin for Server-Side Reactive Programming
-
Section 53: More Practice and Drills
-
Section 54: Kotlin Security Practices
233: Building a Multiplatform To-Do App
Where should the actual "To-Do" logic live so I don't write it twice?
Look, the whole point of Kotlin Multiplatform (KMP) is to avoid the "copy-paste" dance between Android and iOS. For a To-Do app, your data models and business logic—like validating that a task isn't empty or filtering completed items—belong in commonMain. I always recommend starting with a simple data class that both platforms can see.
// In commonMain data class TodoItem( val id: Long, val title: String, val isCompleted: Boolean = false, val priority: Priority = Priority.MEDIUM ) enum class Priority { LOW, MEDIUM, HIGH }By keeping this in
commonMain, you ensure that if you add a "Priority" field later, you aren't hunting through two different projects to update the model. You define it once, and the Kotlin compiler handles the rest.How do I handle the database since iOS and Android store data differently?
This is where people usually get stuck. You can't just throw a Room database into the shared module because Room is heavily tied to Android. Instead, use SQLDelight. It's the gold standard for KMP because it generates typesafe Kotlin APIs from actual SQL statements.
The trick is the
expect/actualpattern for the database driver. You define the "expectation" in common code and provide the "actual" implementation for each platform. It looks something like this:// In commonMain expect class DatabaseDriverFactory { fun createDriver(): SqlDriver } // In androidMain actual class DatabaseDriverFactory(private val context: Context) { actual fun createDriver(): SqlDriver { return AndroidSqliteDriver(TodoDatabase.Schema, context, "todo.db") } } // In iosMain actual class DatabaseDriverFactory { actual fun createDriver(): SqlDriver { return NativeSqliteDriver(TodoDatabase.Schema, "todo.db") } }I've found that setting this up early saves you a massive headache. You write your SQL in a
.sqfile, and SQLDelight gives you aTodoQueriesobject that you can use in your shared repository regardless of whether you're on an iPhone or a Pixel.How do I make the UI update instantly when a task is checked off?
You don't want your UI to manually poll the database. Instead, use
StateFlowin a shared ViewModel. Since we're using Compose Multiplatform, the UI can just "collect" this flow. When the database changes, the flow emits a new list, and the UI snaps into place.Here is a simplified version of how I'd structure the shared ViewModel logic:
class TodoViewModel(private val repository: TodoRepository) { private val _todos = MutableStateFlow<List<TodoItem>>(emptyList()) val todos: StateFlow<List<TodoItem>> = _todos.asStateFlow() fun toggleTodo(id: Long, isCompleted: Boolean) { viewModelScope.launch { repository.updateTodoStatus(id, isCompleted) // Refresh the flow from the DB _todos.value = repository.getAllTodos() } } }By keeping the
StateFlowin the shared module, you've effectively written your "state management" once. Your Android Compose code and your iOS Compose code (or SwiftUI) just listen to that same stream of data. It makes the app feel snappy and keeps the platforms perfectly in sync.
📋 Practical Task
Implement a Priority-Based Filter for the To-Do List
Right now, the app shows all tasks in a single list. Your task is to extend the shared logic to allow filtering by priority.
- Modify the
TodoViewModelto include acurrentFilterStateFlow that holds aPriorityvalue (or a "All" option). - Update the
todosflow in the ViewModel to usecombine, so it automatically filters the list from the repository based on the currently selected priority. - Ensure that when the user changes the filter, the UI updates without needing to reload the entire database.
There are no comments for now.