Kotlin

Your app needs to sync data with the server every hour. Or compress images before uploading. Or clean up old cache files once a day. You cannot use a coroutine for this. If the user closes the app, the coroutine dies. If the device restarts, the work is gone. WorkManager guarantees execution. It schedules background tasks that survive app restarts, device reboots, and even Doze mode. Android’s system handles when to run the work — you just define what to do and under what conditions. ...

SharedPreferences has been the go-to way to store simple data on Android for over a decade. It works. But it has problems. It runs on the main thread and can cause jank. It has no type safety — you request a string and get a crash if the key holds an integer. It has no way to observe changes reactively. And it does not handle errors — a corrupted file means lost data with no recovery. ...

The Compose tutorial covered basic Room: one entity, one DAO, simple CRUD operations. That is enough for a notes app. Real apps need more. Users update their app and you need to migrate the database without losing data. You have notes with tags — a many-to-many relationship. Users search through thousands of notes and expect instant results. This tutorial covers the advanced Room patterns you need for production apps. Prerequisites: Compose Tutorial #13: Room basics and Kotlin Tutorial: Flow. ...

In the Compose series, you learned basic Retrofit: define an interface, call an endpoint, show the result. That works for tutorials. In production, you need more. Authentication tokens that refresh automatically. Logging for debugging. Retry logic for flaky networks. Proper error handling that shows meaningful messages. This tutorial builds a production-ready API layer with Retrofit 3, Kotlin Serialization, and OkHttp interceptors. Prerequisites: Compose Tutorial #12: Retrofit basics and Kotlin Tutorial: Serialization. Why Kotlin Serialization Over Gson? Retrofit traditionally used Gson for JSON parsing. Kotlin Serialization is better for modern Android: ...

Your single-module app compiles in 45 seconds. You add more features. More screens. More dependencies. Now it takes 3 minutes. Every small change triggers a full rebuild. Worse, any file can import any other file. Your UI layer imports database classes directly. A junior developer bypasses the repository and calls the DAO from a Composable. There are no boundaries. Multi-module architecture fixes both problems. Faster builds (Gradle only recompiles changed modules) and enforced boundaries (modules can only access what they depend on). ...

Your ViewModel starts simple. It loads data from a repository and shows it on screen. Then product requirements arrive: filter tasks by priority, sort by due date, combine tasks with user data, validate input before saving. The ViewModel grows. It becomes 500 lines of mixed UI logic and business rules. Testing one rule means setting up the entire ViewModel. Use cases fix this. Each use case is one business operation. One class. One job. Easy to test. Easy to reuse across ViewModels. ...

Your app calls an API. It also reads from a local database. Sometimes the API is down. Sometimes the user has no internet. Where does the data come from? Without a clear answer, your app becomes unpredictable. One screen shows fresh data from the API. Another screen shows stale data from the database. The user sees different information depending on which screen they check first. The repository pattern solves this. It gives your app a single source of truth — one place where data lives. Every screen reads from the same source. ...

In the previous tutorial, you learned about Clean Architecture layers. But there is a problem — who connects everything together? Who creates the repository and gives it to the ViewModel? Who creates the database and gives it to the repository? You could wire everything manually. But with 10 ViewModels, 5 repositories, and 3 data sources, you will spend more time wiring than coding. Hilt solves this. You annotate your classes and Hilt connects everything automatically. It is Google’s recommended DI framework for Android. ...

Your first Android app works fine with everything in one file. But as the app grows, things fall apart. You add more screens. More API calls. More database queries. Suddenly, one change breaks three unrelated features. This is the architecture problem. And it is the reason most real-world apps follow a structured pattern. In this tutorial, you will learn the three most important architecture patterns for Android: MVVM, MVI, and Clean Architecture. You will understand when to use each one and how they work together. ...

Mobile development is hard. Cross-platform mobile development is harder. Kotlin Multiplatform sits in the middle — shared business logic with native UI on each platform. The Gradle configuration alone can take hours. Can Claude handle it? This is the most technically challenging project in the entire series. KMP has expect/actual declarations, platform-specific dependency injection, multiplatform Gradle config, and two completely different UI frameworks (Jetpack Compose for Android, SwiftUI for iOS). ...