Android

In the previous tutorial, we built the data layer — Room entities, DAO, repository, and use cases. Now we connect it to the UI. This tutorial builds the three main screens of our task manager app: the task list, the add task form, and the settings screen. What We Build UI Layer: ├── TaskListScreen + TaskListViewModel (MVI) │ ├── Search bar │ ├── Filter chips (All, Active, Completed) │ ├── Task cards with priority badge + category │ └── Swipe to delete ├── AddTaskScreen + AddTaskViewModel │ ├── Title + description fields │ ├── Category chips │ ├── Priority chips │ └── Save button with validation └── SettingsScreen + SettingsViewModel ├── Dark mode toggle └── Delete completed tasks Task List Screen — State and Intents State // ui/screens/tasklist/TaskListState.kt // Everything the task list screen needs to display data class TaskListState( val tasks: List<Task> = emptyList(), val filter: TaskFilter = TaskFilter.ALL, val searchQuery: String = "", val isLoading: Boolean = true, val error: String? = null, val taskCount: Int = 0, val completedCount: Int = 0 ) Intents // ui/screens/tasklist/TaskListIntent.kt // Every action the user can take on the task list sealed interface TaskListIntent { data class Search(val query: String) : TaskListIntent data class ChangeFilter(val filter: TaskFilter) : TaskListIntent data class ToggleTask(val taskId: Long) : TaskListIntent data class DeleteTask(val taskId: Long) : TaskListIntent data object DeleteCompleted : TaskListIntent data object Retry : TaskListIntent } ViewModel // ui/screens/tasklist/TaskListViewModel.kt @HiltViewModel class TaskListViewModel @Inject constructor( private val getTasks: GetTasksUseCase, private val toggleTask: ToggleTaskUseCase, private val deleteTask: DeleteTaskUseCase, private val repository: TaskRepository ) : ViewModel() { private val _state = MutableStateFlow(TaskListState()) val state: StateFlow<TaskListState> = _state.asStateFlow() private var searchJob: Job? = null init { observeTasks() observeCounts() } fun onIntent(intent: TaskListIntent) { when (intent) { is TaskListIntent.Search -> { _state.update { it.copy(searchQuery = intent.query) } observeTasks() } is TaskListIntent.ChangeFilter -> { _state.update { it.copy(filter = intent.filter) } observeTasks() } is TaskListIntent.ToggleTask -> { viewModelScope.launch { toggleTask(intent.taskId) } } is TaskListIntent.DeleteTask -> { viewModelScope.launch { deleteTask(intent.taskId) } } is TaskListIntent.DeleteCompleted -> { viewModelScope.launch { repository.deleteCompletedTasks() } } is TaskListIntent.Retry -> { _state.update { it.copy(error = null) } observeTasks() } } } private fun observeTasks() { searchJob?.cancel() searchJob = viewModelScope.launch { _state.update { it.copy(isLoading = true) } try { getTasks( filter = _state.value.filter, searchQuery = _state.value.searchQuery ).collect { tasks -> _state.update { it.copy(tasks = tasks, isLoading = false, error = null) } } } catch (e: Exception) { _state.update { it.copy(error = e.message, isLoading = false) } } } } private fun observeCounts() { viewModelScope.launch { repository.getTaskCount().collect { count -> _state.update { it.copy(taskCount = count) } } } viewModelScope.launch { repository.getCompletedCount().collect { count -> _state.update { it.copy(completedCount = count) } } } } } The ViewModel pattern: ...

In the previous tutorial, we planned our task manager app. Now we build the foundation — the data layer. The data layer is everything below the UI: the database, the repository, and the use cases. Get this right, and the UI layer writes itself. What We Build in This Tutorial data/ ├── local/ │ ├── TaskEntity.kt ← Database table definition │ ├── TaskDao.kt ← Database operations │ └── AppDatabase.kt ← Room database ├── mapper/ │ └── TaskMapper.kt ← Convert Entity ↔ Domain Model ├── repository/ │ └── TaskRepositoryImpl.kt ← Repository implementation │ domain/ ├── model/ │ ├── Task.kt ← Clean domain model │ ├── Category.kt ← Enum │ └── Priority.kt ← Enum ├── repository/ │ └── TaskRepository.kt ← Interface (contract) └── usecase/ ├── GetTasksUseCase.kt ├── AddTaskUseCase.kt ├── ToggleTaskUseCase.kt └── DeleteTaskUseCase.kt Step 1: Domain Models The domain layer is pure Kotlin — no Android dependencies, no Room annotations. This is the “truth” of your app. ...

You have learned every piece: layouts, state, navigation, ViewModel, MVI, Room, Hilt, animations, testing, and adaptive layouts. Now it is time to use them all together. In the next five tutorials, we will build a complete task manager app from scratch. Not a toy demo — a real app with real architecture that you could publish to Google Play. This tutorial is about planning — deciding what to build, how to organize the code, and what dependencies to use. No code yet. Just decisions. ...

Your app looks great on a phone. But open it on a tablet and there is a giant empty space. Open it on a foldable and the layout breaks. In 2026, adaptive layouts are not optional. Google Play requires apps to support different screen sizes. And with foldables, tablets, and ChromeOS — your app will run on screens from 4 inches to 15 inches. This tutorial teaches you how to build one codebase that adapts to every screen. ...

Your app needs the camera. Or the user’s location. Or access to files. On Android, you can’t just use these — you need to ask permission first. In the old View system, permissions required complex boilerplate with onRequestPermissionsResult. In Compose, it’s much simpler — a few lines with rememberLauncherForActivityResult or the Accompanist library. Two Ways to Handle Permissions Approach Library Best For Activity Result API Built-in (no extra dependency) Simple, single permission Accompanist Permissions accompanist-permissions Multiple permissions, complex flows Both work well. Activity Result API is simpler. Accompanist gives more control. ...

Your app works when you manually tap through it. But does it work after your next code change? And the one after that? Manual testing doesn’t scale. You can’t tap through 50 screens after every change. That is what automated tests are for — and Compose makes testing surprisingly easy. Why Test Compose UI? Three reasons: Catch bugs before users do — tests run in seconds, not minutes of manual tapping Refactor with confidence — change code, run tests, know nothing broke Document behavior — tests show WHAT the UI should do Setup Add the testing dependencies to app/build.gradle.kts: ...

Your app works. But it stutters when scrolling. The screen freezes for a split second when you type. Animations aren’t smooth. The problem isn’t Compose — it’s recomposition. Compose redraws parts of your UI when state changes. If it redraws too much, too often, your app feels slow. This tutorial will teach you why Compose gets slow and how to fix it. How Recomposition Works When state changes, Compose doesn’t redraw the entire screen. It redraws only the Composables that read the changed state. This is called recomposition. ...

Sometimes Column, Row, and Box are not enough. You need a circular progress bar. A custom chart. A drawing canvas. A shape that doesn’t exist in Material Design. That is when you use Canvas — Compose’s drawing API that lets you draw anything pixel by pixel. What is Canvas? Canvas is a Composable that gives you a blank area to draw on. You can draw shapes, lines, arcs, text — anything. ...

Your app works. But it feels flat. Buttons appear instantly. Screens switch without transition. Content pops in and out like a slideshow from 2005. Animations fix that. They make your app feel smooth, polished, and alive — like a well-made product instead of a homework assignment. The good news: Compose makes animations surprisingly easy. You can add most animations with a single line of code. The Animation API at a Glance Compose has several animation APIs, each for a different use case: ...

In the previous tutorials, we created databases and ViewModels manually. We wrote DatabaseProvider singletons. We passed dependencies by hand. It worked — but it doesn’t scale. When your app has 10 ViewModels, 5 repositories, 3 data sources, and a database — wiring everything manually becomes a nightmare. One missing connection and your app crashes. Hilt fixes this. You add annotations to your classes, and Hilt connects everything automatically. What is Dependency Injection? Dependency injection (DI) means: instead of a class creating its own dependencies, someone else provides them. ...