Android

Your music app needs to keep playing when the user switches to another app. Your fitness app needs to track location while the phone is in the user’s pocket. A download manager needs to stay alive until the file is complete. These are foreground services. They run long-running operations that the user is aware of, shown with a persistent notification. In this tutorial, you will learn how to build foreground services — service types, lifecycle, communication with the UI, and practical examples for music playback and location tracking. ...

Notifications are how your app communicates with users when they are not looking at the screen. A chat message arrives. A download completes. A delivery is on the way. In this tutorial, you will learn how to build notifications from basic to advanced — channels, styles, actions, permission handling, and the new Progress-centric notifications in Android 16. Prerequisites: You should know Kotlin basics and Compose fundamentals. If not, start with the Kotlin tutorial series and the Jetpack Compose tutorial series. ...

Your app has a list of 10,000 items. Loading them all at once is a bad idea. The API call takes forever. The device runs out of memory. The UI freezes while Room queries thousands of rows. You need pagination — load 20 items at a time, and load more when the user scrolls near the bottom. You could build this manually. Track the current page. Handle loading and error states. Cache pages. Manage memory. Or you could use Paging 3, which does all of this for you. ...

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. ...