Development

In the previous tutorial, we learned borrowing and references. Now we learn how to create custom types with structs and attach behavior to them with methods. If you have used classes in Kotlin, Java, or Python, structs will feel familiar. Rust does not have classes, but structs with impl blocks give you the same power — without inheritance. Defining a Struct A struct groups related data together: struct User { name: String, email: String, age: u32, active: bool, } Each field has a name and a type. This is similar to a data class in Kotlin or a class in Python. ...

In the previous tutorial, we installed Rust and wrote “Hello, world!”. Now let’s learn the building blocks — variables, types, and functions. If you know Kotlin, Python, or JavaScript, most of this will feel familiar. But Rust has a few surprises — especially around mutability and shadowing. Variables: let and mut Immutable by Default In Rust, variables are immutable by default. You cannot change them after creation: let name = "Alex"; name = "Sam"; // ERROR: cannot assign twice to immutable variable This is the opposite of most languages. In Kotlin, val is immutable and var is mutable. In Rust, let is immutable and let mut is mutable. ...

In the previous tutorial, we learned why Rust matters. Now let’s install it and write our first program. By the end of this tutorial, you will have Rust installed, your editor set up, and a working program that you built and ran yourself. Step 1: Install Rust with rustup Rust uses a tool called rustup to manage installations. One command installs everything: macOS / Linux curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh Follow the prompts — choose the default installation (option 1). ...

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