If you’ve been diving into modern Android development, you’ve probably heard the buzz about Material Design 3 (also known as Material You) and Jetpack Compose. Today, we’re going to explore one of the most powerful yet underappreciated features that ties them together: Design Tokens. Understanding Design Tokens in Material 3 and Jetpack Compose will transform...
Creating a polished Android app starts with one crucial decision: your app’s visual identity. If you’ve been wondering how to make your Jetpack Compose app look consistent and professional across every screen, you’re in the right place. In this guide, I’ll walk you through building a Custom App Theme in Jetpack Compose using Material 3....
When building apps with Jetpack Compose, you’ll often pass data down through multiple layers of composables. At first, this feels fine. But as your UI grows, you may find yourself passing the same parameter through five or six functions just to reach a deeply nested child. That pattern is called prop drilling. It works, but...
Have you ever wondered how Android apps magically match your wallpaper colors? Or how Material Design creates those perfectly harmonious color palettes that just work?
That’s the magic of Material 3’s dynamic color system, and today, we’re diving deep into how it all comes together using Kotlin and Jetpack Compose.
By the end of this guide, you’ll understand exactly how the Material 3 colorScheme works, how to implement it in your Android apps with Kotlin, and how to harness the power of dynamic theming to create stunning user interfaces that feel personal and cohesive.
Let’s get started..!
The Material 3 colorScheme is Google’s revolutionary approach to app theming that goes way beyond simple primary and secondary colors. Think of it as a complete color system that automatically generates a harmonious palette of colors designed to work together beautifully.
Here’s what makes it special:
Dynamic Color Generation: Instead of manually picking dozens of color shades, the Material 3 colorScheme generates an entire palette from a single seed color. This means you get consistent, accessible, and visually appealing colors without the guesswork.
Adaptive Theming: The system automatically adjusts for light and dark modes, ensuring your app looks great in any setting.
Wallpaper Integration: On Android 12 and above, your app can automatically extract colors from the user’s wallpaper, creating a truly personalized experience.
Accessibility Built-In: Every color in the Material 3 colorScheme meets WCAG (Web Content Accessibility Guidelines) accessibility standards when used correctly, so you don’t have to worry about contrast ratios.
Dynamic color is the heart of Material 3 on Android. But what exactly is it?
Imagine your phone’s wallpaper is a beautiful sunset with warm orange and purple tones. With dynamic color, your apps can extract those colors and build their entire theme around them. It’s personalization taken to the next level.
The process is actually quite elegant:
The beauty of the Material 3 colorScheme is that all this complexity is handled for you in Jetpack Compose. You just need to understand how to use it.
Here’s where Material 3 gets really interesting. Instead of thinking in terms of “primary,” “secondary,” and “tertiary” colors alone, the Material 3 colorScheme introduces color roles.
Think of color roles as jobs that colors perform in your UI. Let’s break down the main players:
Primary: This is your brand color, the star of the show. It appears on prominent buttons and active states.
OnPrimary: Text and icons that sit on top of the primary color. The Material 3 colorScheme ensures this has enough contrast to be readable.
PrimaryContainer: A lighter (or darker in dark mode) version used for less prominent components.
OnPrimaryContainer: Text that appears on primary containers.
Secondary: Provides visual variety and highlights less prominent components.
OnSecondary: You guessed it — text on secondary colors.
SecondaryContainer: For chips, cards, and other contained elements.
OnSecondaryContainer: Text on those containers.
Tertiary: Adds even more variety, often used for accents and special highlights.
OnTertiary, TertiaryContainer, OnTertiaryContainer: Following the same pattern.
Surface: The background color for cards, sheets, and menus.
OnSurface: Text and icons on surfaces.
SurfaceVariant: Alternative surface with subtle differences.
OnSurfaceVariant: Text with lower emphasis.
Background: The main background of your app.
OnBackground: Primary text on the background.
Error: For error states and destructive actions.
OnError: Text on error colors.
ErrorContainer: Background for error messages.
OnErrorContainer: Text in error containers.
Outline: Borders and dividers.
OutlineVariant: Subtle borders.
Scrim: Semi-transparent overlays.
InverseSurface, InverseOnSurface, InversePrimary: For high-contrast elements like tooltips.
SurfaceTint: Used for elevation overlays in Material 3.
Phew! That’s a lot of colors, right..?
But here’s the magic: the Material 3 colorScheme generates all of these automatically, ensuring they work harmoniously together.
In short, a typical Material 3 colorScheme includes:
primary – main brand coloronPrimary – content placed on primarysecondary – supporting colortertiary – optional accent colorbackground – app backgroundsurface – cards and sheetserror – error statesonSurface – text/icons on surfacesEach color has a paired onColor to guarantee readability.
This pairing is key to accessibility.
Before we dive into code, let’s make sure your Android project is ready for Material 3.
First, add the necessary dependencies to your build.gradle.kts (Module level):
dependencies {
// Jetpack Compose BOM (Bill of Materials)
implementation(platform("androidx.compose:compose-bom:2024.02.00"))
// Material 3
implementation("androidx.compose.material3:material3")
// Other Compose dependencies
implementation("androidx.compose.ui:ui")
implementation("androidx.compose.ui:ui-tooling-preview")
implementation("androidx.activity:activity-compose:1.8.2")
// Core KTX
implementation("androidx.core:core-ktx:1.12.0")
// Lifecycle
implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.7.0")
}What each dependency does:
compose-bom: Manages Compose versions automaticallymaterial3: The Material 3 components and colorScheme systemui and ui-tooling-preview: Core Compose UI and preview supportactivity-compose: Integration with Android activitiesCreate a new file called Theme.kt in your ui.theme package:
package com.softaai.myapp.ui.theme
import android.app.Activity
import android.os.Build
import androidx.compose.foundation.isSystemInDarkTheme
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.darkColorScheme
import androidx.compose.material3.dynamicDarkColorScheme
import androidx.compose.material3.dynamicLightColorScheme
import androidx.compose.material3.lightColorScheme
import androidx.compose.runtime.Composable
import androidx.compose.runtime.SideEffect
import androidx.compose.ui.graphics.toArgb
import androidx.compose.ui.platform.LocalContext
import androidx.compose.ui.platform.LocalView
import androidx.core.view.WindowCompat
@Composable
fun MyAppTheme(
darkTheme: Boolean = isSystemInDarkTheme(),
dynamicColor: Boolean = true,
content: @Composable () -> Unit
) {
// We'll fill this in shortly!
}
This is your foundation. Now let’s build on it!
Let’s start with the simplest implementation and work our way up to more advanced features.
Here’s how to create a basic Material 3 colorScheme with custom colors:
import androidx.compose.material3.darkColorScheme
import androidx.compose.material3.lightColorScheme
import androidx.compose.ui.graphics.Color
// Light theme colors
private val LightColorScheme = lightColorScheme(
primary = Color(0xFF6750A4),
onPrimary = Color(0xFFFFFFFF),
primaryContainer = Color(0xFFEADDFF),
onPrimaryContainer = Color(0xFF21005D),
secondary = Color(0xFF625B71),
onSecondary = Color(0xFFFFFFFF),
secondaryContainer = Color(0xFFE8DEF8),
onSecondaryContainer = Color(0xFF1D192B),
tertiary = Color(0xFF7D5260),
onTertiary = Color(0xFFFFFFFF),
tertiaryContainer = Color(0xFFFFD8E4),
onTertiaryContainer = Color(0xFF31111D),
error = Color(0xFFB3261E),
onError = Color(0xFFFFFFFF),
errorContainer = Color(0xFFF9DEDC),
onErrorContainer = Color(0xFF410E0B),
background = Color(0xFFFFFBFE),
onBackground = Color(0xFF1C1B1F),
surface = Color(0xFFFFFBFE),
onSurface = Color(0xFF1C1B1F),
surfaceVariant = Color(0xFFE7E0EC),
onSurfaceVariant = Color(0xFF49454F),
outline = Color(0xFF79747E),
outlineVariant = Color(0xFFCAC4D0),
scrim = Color(0xFF000000),
inverseSurface = Color(0xFF313033),
inverseOnSurface = Color(0xFFF4EFF4),
inversePrimary = Color(0xFFD0BCFF),
)
// Dark theme colors
private val DarkColorScheme = darkColorScheme(
primary = Color(0xFFD0BCFF),
onPrimary = Color(0xFF381E72),
primaryContainer = Color(0xFF4F378B),
onPrimaryContainer = Color(0xFFEADDFF),
secondary = Color(0xFFCCC2DC),
onSecondary = Color(0xFF332D41),
secondaryContainer = Color(0xFF4A4458),
onSecondaryContainer = Color(0xFFE8DEF8),
tertiary = Color(0xFFEFB8C8),
onTertiary = Color(0xFF492532),
tertiaryContainer = Color(0xFF633B48),
onTertiaryContainer = Color(0xFFFFD8E4),
error = Color(0xFFF2B8B5),
onError = Color(0xFF601410),
errorContainer = Color(0xFF8C1D18),
onErrorContainer = Color(0xFFF9DEDC),
background = Color(0xFF1C1B1F),
onBackground = Color(0xFFE6E1E5),
surface = Color(0xFF1C1B1F),
onSurface = Color(0xFFE6E1E5),
surfaceVariant = Color(0xFF49454F),
onSurfaceVariant = Color(0xFFCAC4D0),
outline = Color(0xFF938F99),
outlineVariant = Color(0xFF49454F),
scrim = Color(0xFF000000),
inverseSurface = Color(0xFFE6E1E5),
inverseOnSurface = Color(0xFF313033),
inversePrimary = Color(0xFF6750A4),
)Now let’s use these in your theme:
@Composable
fun MyAppTheme(
darkTheme: Boolean = isSystemInDarkTheme(),
content: @Composable () -> Unit
) {
val colorScheme = if (darkTheme) DarkColorScheme else LightColorScheme
MaterialTheme(
colorScheme = colorScheme,
typography = Typography,
content = content
)
}Here,
MaterialTheme applies the colorScheme to your entire app
This is the manual approach. But there’s a much easier way..!
Here’s where things get really exciting. On Android 12 (API 31) and above, you can use dynamic color to automatically match the user’s wallpaper.
@Composable
fun MyAppTheme(
darkTheme: Boolean = isSystemInDarkTheme(),
dynamicColor: Boolean = true, // Enable/disable dynamic color
content: @Composable () -> Unit
) {
val context = LocalContext.current
// Determine which colorScheme to use
val colorScheme = when {
// Use dynamic color if available (Android 12+)
dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {
if (darkTheme) dynamicDarkColorScheme(context)
else dynamicLightColorScheme(context)
}
// Fall back to custom dark colors
darkTheme -> DarkColorScheme
// Fall back to custom light colors
else -> LightColorScheme
}
// Update the system bars to match theme
val view = LocalView.current
if (!view.isInEditMode) {
SideEffect {
val window = (view.context as Activity).window
window.statusBarColor = colorScheme.surface.toArgb()
WindowCompat.getInsetsController(window, view)
.isAppearanceLightStatusBars = !darkTheme
}
}
MaterialTheme(
colorScheme = colorScheme,
typography = Typography,
content = content
)
}Let’s break down what’s happening:
dynamicDarkColorScheme() or dynamicLightColorScheme()That’s it..!
Your app now supports dynamic theming with the Material 3 colorScheme.
Don’t forget to wrap your content in the theme:
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
MyAppTheme {
// Your app content here
Surface(
modifier = Modifier.fillMaxSize(),
color = MaterialTheme.colorScheme.background
) {
ProfileScreen()
}
}
}
}
}Important points:
MyAppTheme wraps all your composablesSurface uses colorScheme.background for the base colorNow that you have your Material 3 colorScheme set up, how do you actually use these colors in your UI?
Material 3 components automatically use the appropriate colors from your colorScheme:
@Composable
fun AutomaticColorExample() {
Column(
modifier = Modifier.padding(16.dp),
verticalArrangement = Arrangement.spacedBy(8.dp)
) {
// Primary button - automatically uses primary color
Button(onClick = { /* Do something */ }) {
Text("Primary Button")
}
// Tonal button - uses primaryContainer
FilledTonalButton(onClick = { /* Do something */ }) {
Text("Tonal Button")
}
// Outlined button - uses outline color
OutlinedButton(onClick = { /* Do something */ }) {
Text("Outlined Button")
}
// Card - automatically uses surface color
Card {
Text(
text = "This card uses surface colors",
modifier = Modifier.padding(16.dp)
)
}
}
}
No manual color assignment needed..! The Material 3 colorScheme handles it automatically.
Sometimes you need direct access to specific colors:
@Composable
fun ManualColorExample() {
// Access the current Material 3 colorScheme
val colorScheme = MaterialTheme.colorScheme
Box(
modifier = Modifier
.fillMaxWidth()
.background(colorScheme.primaryContainer)
.padding(16.dp)
) {
Text(
text = "Custom colored container",
color = colorScheme.onPrimaryContainer,
style = MaterialTheme.typography.headlineSmall
)
}
}Key points:
MaterialTheme.colorScheme to access all color rolesLet’s create some practical examples that showcase the Material 3 colorScheme in action.
@Composable
fun ThemedButton(
text: String,
onClick: () -> Unit,
modifier: Modifier = Modifier,
isPrimary: Boolean = true
) {
val colorScheme = MaterialTheme.colorScheme
// Choose colors based on button type
val backgroundColor = if (isPrimary) {
colorScheme.primary
} else {
colorScheme.secondary
}
val contentColor = if (isPrimary) {
colorScheme.onPrimary
} else {
colorScheme.onSecondary
}
Button(
onClick = onClick,
modifier = modifier,
colors = ButtonDefaults.buttonColors(
containerColor = backgroundColor,
contentColor = contentColor
)
) {
Text(text)
}
}
// Usage
@Composable
fun ButtonExample() {
Column(
modifier = Modifier.padding(16.dp),
verticalArrangement = Arrangement.spacedBy(8.dp)
) {
ThemedButton(
text = "Primary Action",
onClick = { /* Handle click */ },
isPrimary = true
)
ThemedButton(
text = "Secondary Action",
onClick = { /* Handle click */ },
isPrimary = false
)
}
}Here,
@Composable
fun StatusCard(
title: String,
message: String,
isError: Boolean = false,
modifier: Modifier = Modifier
) {
val colorScheme = MaterialTheme.colorScheme
// Choose colors based on status
val containerColor = if (isError) {
colorScheme.errorContainer
} else {
colorScheme.primaryContainer
}
val contentColor = if (isError) {
colorScheme.onErrorContainer
} else {
colorScheme.onPrimaryContainer
}
val iconColor = if (isError) {
colorScheme.error
} else {
colorScheme.primary
}
Card(
modifier = modifier.fillMaxWidth(),
colors = CardDefaults.cardColors(
containerColor = containerColor
)
) {
Row(
modifier = Modifier.padding(16.dp),
horizontalArrangement = Arrangement.spacedBy(12.dp),
verticalAlignment = Alignment.CenterVertically
) {
Icon(
imageVector = if (isError) {
Icons.Default.Error
} else {
Icons.Default.CheckCircle
},
contentDescription = null,
tint = iconColor,
modifier = Modifier.size(32.dp)
)
Column {
Text(
text = title,
style = MaterialTheme.typography.titleMedium,
color = contentColor,
fontWeight = FontWeight.Bold
)
Spacer(modifier = Modifier.height(4.dp))
Text(
text = message,
style = MaterialTheme.typography.bodyMedium,
color = contentColor
)
}
}
}
}
// Usage
@Composable
fun StatusCardExample() {
Column(
modifier = Modifier.padding(16.dp),
verticalArrangement = Arrangement.spacedBy(12.dp)
) {
StatusCard(
title = "Success",
message = "Your profile has been updated successfully",
isError = false
)
StatusCard(
title = "Error",
message = "Failed to save changes. Please try again.",
isError = true
)
}
}This example shows how the Material 3 colorScheme adapts to different UI states seamlessly.
Let’s build a realistic profile screen using the Material 3 colorScheme:
@Composable
fun ProfileScreen() {
val colorScheme = MaterialTheme.colorScheme
Scaffold(
topBar = {
TopAppBar(
title = { Text("Profile") },
colors = TopAppBarDefaults.topAppBarColors(
containerColor = colorScheme.surface,
titleContentColor = colorScheme.onSurface
)
)
}
) { paddingValues ->
Column(
modifier = Modifier
.fillMaxSize()
.background(colorScheme.background)
.padding(paddingValues)
.padding(16.dp),
verticalArrangement = Arrangement.spacedBy(16.dp)
) {
// Profile Header Card
Card(
modifier = Modifier.fillMaxWidth(),
colors = CardDefaults.cardColors(
containerColor = colorScheme.primaryContainer
)
) {
Column(
modifier = Modifier
.fillMaxWidth()
.padding(20.dp),
horizontalAlignment = Alignment.CenterHorizontally
) {
// Profile Image
Surface(
modifier = Modifier.size(100.dp),
shape = CircleShape,
color = colorScheme.primary
) {
Icon(
imageVector = Icons.Default.Person,
contentDescription = "Profile Picture",
modifier = Modifier
.fillMaxSize()
.padding(20.dp),
tint = colorScheme.onPrimary
)
}
Spacer(modifier = Modifier.height(16.dp))
Text(
text = "Amol Pawar",
style = MaterialTheme.typography.headlineMedium,
color = colorScheme.onPrimaryContainer,
fontWeight = FontWeight.Bold
)
Text(
text = "[email protected]",
style = MaterialTheme.typography.bodyMedium,
color = colorScheme.onPrimaryContainer.copy(alpha = 0.8f)
)
}
}
// Settings Section
Card(
modifier = Modifier.fillMaxWidth(),
colors = CardDefaults.cardColors(
containerColor = colorScheme.surface
)
) {
Column {
SettingsItem(
icon = Icons.Default.Notifications,
title = "Notifications",
onClick = { /* Handle click */ }
)
HorizontalDivider(color = colorScheme.outlineVariant)
SettingsItem(
icon = Icons.Default.Security,
title = "Privacy & Security",
onClick = { /* Handle click */ }
)
HorizontalDivider(color = colorScheme.outlineVariant)
SettingsItem(
icon = Icons.Default.Help,
title = "Help & Support",
onClick = { /* Handle click */ }
)
}
}
// Action Buttons
Button(
onClick = { /* Edit profile */ },
modifier = Modifier.fillMaxWidth(),
colors = ButtonDefaults.buttonColors(
containerColor = colorScheme.primary,
contentColor = colorScheme.onPrimary
)
) {
Text("Edit Profile")
}
OutlinedButton(
onClick = { /* Sign out */ },
modifier = Modifier.fillMaxWidth(),
colors = ButtonDefaults.outlinedButtonColors(
contentColor = colorScheme.error
),
border = BorderStroke(1.dp, colorScheme.error)
) {
Text("Sign Out")
}
}
}
}
@Composable
fun SettingsItem(
icon: ImageVector,
title: String,
onClick: () -> Unit
) {
val colorScheme = MaterialTheme.colorScheme
Surface(
onClick = onClick,
color = Color.Transparent
) {
Row(
modifier = Modifier
.fillMaxWidth()
.padding(16.dp),
horizontalArrangement = Arrangement.SpaceBetween,
verticalAlignment = Alignment.CenterVertically
) {
Row(
horizontalArrangement = Arrangement.spacedBy(16.dp),
verticalAlignment = Alignment.CenterVertically
) {
Icon(
imageVector = icon,
contentDescription = null,
tint = colorScheme.primary
)
Text(
text = title,
style = MaterialTheme.typography.bodyLarge,
color = colorScheme.onSurface
)
}
Icon(
imageVector = Icons.AutoMirrored.Filled.KeyboardArrowRight,
contentDescription = "Navigate",
tint = colorScheme.onSurfaceVariant
)
}
}
}Sometimes you need variations of your Material 3 colorScheme colors:
@Composable
fun ColorVariantExample() {
val colorScheme = MaterialTheme.colorScheme
// Create lighter or darker variants using alpha
val primaryLight = colorScheme.primary.copy(alpha = 0.1f)
val primaryDark = colorScheme.primary.copy(alpha = 0.9f)
Column(
modifier = Modifier.padding(16.dp),
verticalArrangement = Arrangement.spacedBy(8.dp)
) {
// Light variant
Surface(
modifier = Modifier
.fillMaxWidth()
.height(50.dp),
color = primaryLight
) {
Box(contentAlignment = Alignment.Center) {
Text(
"Light Variant",
color = colorScheme.onSurface
)
}
}
// Original color
Surface(
modifier = Modifier
.fillMaxWidth()
.height(50.dp),
color = colorScheme.primary
) {
Box(contentAlignment = Alignment.Center) {
Text(
"Original Primary",
color = colorScheme.onPrimary
)
}
}
// Dark variant
Surface(
modifier = Modifier
.fillMaxWidth()
.height(50.dp),
color = primaryDark
) {
Box(contentAlignment = Alignment.Center) {
Text(
"Dark Variant",
color = colorScheme.onPrimary
)
}
}
}
}
Material 3 introduces surface tint for elevation. Here’s how to use it:
@Composable
fun ElevatedCardExample() {
val colorScheme = MaterialTheme.colorScheme
Column(
modifier = Modifier.padding(16.dp),
verticalArrangement = Arrangement.spacedBy(12.dp)
) {
// Card with different elevation levels
listOf(0.dp, 2.dp, 4.dp, 6.dp).forEach { elevation ->
Card(
modifier = Modifier.fillMaxWidth(),
elevation = CardDefaults.cardElevation(
defaultElevation = elevation
),
colors = CardDefaults.cardColors(
containerColor = colorScheme.surface
)
) {
Text(
text = "Elevation: $elevation",
modifier = Modifier.padding(16.dp),
color = colorScheme.onSurface
)
}
}
}
}
The Material 3 colorScheme automatically applies surfaceTint (usually the primary color) to create subtle elevation effects.
Let users switch between light and dark themes:
@Composable
fun ThemeToggleExample() {
var isDarkTheme by remember { mutableStateOf(false) }
MyAppTheme(darkTheme = isDarkTheme) {
val colorScheme = MaterialTheme.colorScheme
Scaffold { paddingValues ->
Column(
modifier = Modifier
.fillMaxSize()
.padding(paddingValues)
.background(colorScheme.background)
.padding(16.dp)
) {
Card(
modifier = Modifier.fillMaxWidth(),
colors = CardDefaults.cardColors(
containerColor = colorScheme.surfaceVariant
)
) {
Row(
modifier = Modifier
.fillMaxWidth()
.padding(16.dp),
horizontalArrangement = Arrangement.SpaceBetween,
verticalAlignment = Alignment.CenterVertically
) {
Row(
horizontalArrangement = Arrangement.spacedBy(12.dp),
verticalAlignment = Alignment.CenterVertically
) {
Icon(
imageVector = if (isDarkTheme) {
Icons.Default.DarkMode
} else {
Icons.Default.LightMode
},
contentDescription = null,
tint = colorScheme.onSurfaceVariant
)
Text(
text = "Dark Mode",
style = MaterialTheme.typography.bodyLarge,
color = colorScheme.onSurfaceVariant
)
}
Switch(
checked = isDarkTheme,
onCheckedChange = { isDarkTheme = it },
colors = SwitchDefaults.colors(
checkedThumbColor = colorScheme.primary,
checkedTrackColor = colorScheme.primaryContainer
)
)
}
}
}
}
}
}Want to generate a complete Material 3 colorScheme visually..? Google provides an amazing tool called Material Theme Builder.
The tool generates complete Kotlin code.
Just copy this code into your Theme.kt file and you’re done..!
Pro tip: The Material Theme Builder ensures all colors are harmonious and accessible, saving you hours of manual color picking.
Use the semantic color roles instead of hard-coded values:
// Good: Uses Material 3 colorScheme
Box(
modifier = Modifier.background(MaterialTheme.colorScheme.surface)
)
// Bad: Hard-coded color
Box(
modifier = Modifier.background(Color.White)
)Why this matters: Semantic names adapt automatically to light/dark mode and dynamic color.
Always use the “on” variant for text on colored surfaces:
// Good: Proper pairing ensures readability
Card(
colors = CardDefaults.cardColors(
containerColor = colorScheme.primaryContainer
)
) {
Text(
text = "Accessible text",
color = colorScheme.onPrimaryContainer
)
}
// Bad: Might have contrast issues
Card(
colors = CardDefaults.cardColors(
containerColor = colorScheme.primaryContainer
)
) {
Text(
text = "Poor contrast",
color = colorScheme.secondary // Wrong pairing!
)
}Always have a backup for devices that don’t support dynamic color:
val colorScheme = when {
dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {
if (darkTheme) dynamicDarkColorScheme(context)
else dynamicLightColorScheme(context)
}
darkTheme -> DarkColorScheme // Fallback
else -> LightColorScheme // Fallback
}Always test your UI in both light and dark modes:
@Preview(
name = "Light Mode",
showBackground = true
)
@Preview(
name = "Dark Mode",
showBackground = true,
uiMode = Configuration.UI_MODE_NIGHT_YES
)
@Composable
fun PreviewProfileScreen() {
MyAppTheme {
ProfileScreen()
}
}Use preview parameters to test different scenarios:
@Preview(name = "Light - No Dynamic Color", showBackground = true)
@Composable
fun LightStaticPreview() {
MyAppTheme(darkTheme = false, dynamicColor = false) {
MyComposable()
}
}
@Preview(name = "Dark - No Dynamic Color", showBackground = true)
@Composable
fun DarkStaticPreview() {
MyAppTheme(darkTheme = true, dynamicColor = false) {
MyComposable()
}
}The Material 3 colorScheme uses advanced color science to ensure harmony. Here’s what happens under the hood:
Material 3 uses HCT (Hue, Chroma, Tone) instead of RGB or HSL:
When you provide a seed color, the Material 3 colorScheme:
Primary Palette (High Chroma):
- primary: tone 40 (light) / tone 80 (dark)
- onPrimary: tone 100 (light) / tone 20 (dark)
- primaryContainer: tone 90 (light) / tone 30 (dark)
Neutral Palette (Low Chroma):
- surface: tone 99 (light) / tone 10 (dark)
- onSurface: tone 10 (light) / tone 90 (dark)
You don’t need to understand all the math — just know that it works beautifully..!
Problem: Changes to colorScheme don’t appear in the UI.
Solution: Make sure you’re wrapping your content in the theme:
setContent {
MyAppTheme { // Essential wrapper!
Surface(
modifier = Modifier.fillMaxSize(),
color = MaterialTheme.colorScheme.background
) {
MyApp()
}
}
}Problem: App doesn’t match wallpaper colors.
Solution: Check these points:
dynamicColor = true in your themeBuild.VERSION.SDK_INT >= Build.VERSION_CODES.S// Debug logging
val colorScheme = when {
dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {
Log.d("Theme", "Using dynamic colors from wallpaper")
if (darkTheme) dynamicDarkColorScheme(context)
else dynamicLightColorScheme(context)
}
else -> {
Log.d("Theme", "Using static fallback colors")
if (darkTheme) DarkColorScheme else LightColorScheme
}
}Problem: Compose previews show incorrect or default colors.
Solution: Always wrap preview content in your theme:
@Preview
@Composable
fun MyComposablePreview() {
MyAppTheme { // Never forget the theme wrapper!
MyComposable()
}
}Problem: Status bar and navigation bar don’t match app theme.
Solution: Update system bars in your theme composable:
val view = LocalView.current
if (!view.isInEditMode) {
SideEffect {
val window = (view.context as Activity).window
// Set status bar color
window.statusBarColor = colorScheme.surface.toArgb()
// Set navigation bar color
window.navigationBarColor = colorScheme.surface.toArgb()
// Adjust icon colors
WindowCompat.getInsetsController(window, view).apply {
isAppearanceLightStatusBars = !darkTheme
isAppearanceLightNavigationBars = !darkTheme
}
}
}Problem: Cannot resolve Material 3 symbols.
Solution: Ensure you have the correct dependencies:
dependencies {
// Use BOM for version management
implementation(platform("androidx.compose:compose-bom:2024.02.00"))
implementation("androidx.compose.material3:material3")
// Or specify version explicitly
implementation("androidx.compose.material3:material3:1.2.0")
}Here’s a complete, copy-paste-ready example:
plugins {
id("com.android.application")
id("org.jetbrains.kotlin.android")
}
android {
namespace = "com.softaai.myapp"
compileSdk = 34
defaultConfig {
applicationId = "com.softaai.myapp"
minSdk = 21
targetSdk = 34
versionCode = 1
versionName = "1.0"
}
buildFeatures {
compose = true
}
composeOptions {
kotlinCompilerExtensionVersion = "1.5.8"
}
kotlinOptions {
jvmTarget = "1.8"
}
}
dependencies {
implementation(platform("androidx.compose:compose-bom:2024.02.00"))
implementation("androidx.compose.material3:material3")
implementation("androidx.compose.ui:ui")
implementation("androidx.compose.ui:ui-tooling-preview")
implementation("androidx.activity:activity-compose:1.8.2")
implementation("androidx.core:core-ktx:1.12.0")
implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.7.0")
debugImplementation("androidx.compose.ui:ui-tooling")
}package com.softaai.myapp.ui.theme
import android.app.Activity
import android.os.Build
import androidx.compose.foundation.isSystemInDarkTheme
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.darkColorScheme
import androidx.compose.material3.dynamicDarkColorScheme
import androidx.compose.material3.dynamicLightColorScheme
import androidx.compose.material3.lightColorScheme
import androidx.compose.runtime.Composable
import androidx.compose.runtime.SideEffect
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.graphics.toArgb
import androidx.compose.ui.platform.LocalContext
import androidx.compose.ui.platform.LocalView
import androidx.core.view.WindowCompat
private val LightColorScheme = lightColorScheme(
primary = Color(0xFF6750A4),
onPrimary = Color(0xFFFFFFFF),
primaryContainer = Color(0xFFEADDFF),
onPrimaryContainer = Color(0xFF21005D),
secondary = Color(0xFF625B71),
onSecondary = Color(0xFFFFFFFF),
secondaryContainer = Color(0xFFE8DEF8),
onSecondaryContainer = Color(0xFF1D192B),
tertiary = Color(0xFF7D5260),
onTertiary = Color(0xFFFFFFFF),
tertiaryContainer = Color(0xFFFFD8E4),
onTertiaryContainer = Color(0xFF31111D),
error = Color(0xFFB3261E),
onError = Color(0xFFFFFFFF),
errorContainer = Color(0xFFF9DEDC),
onErrorContainer = Color(0xFF410E0B),
background = Color(0xFFFFFBFE),
onBackground = Color(0xFF1C1B1F),
surface = Color(0xFFFFFBFE),
onSurface = Color(0xFF1C1B1F),
surfaceVariant = Color(0xFFE7E0EC),
onSurfaceVariant = Color(0xFF49454F),
outline = Color(0xFF79747E),
outlineVariant = Color(0xFFCAC4D0),
scrim = Color(0xFF000000),
inverseSurface = Color(0xFF313033),
inverseOnSurface = Color(0xFFF4EFF4),
inversePrimary = Color(0xFFD0BCFF),
)
private val DarkColorScheme = darkColorScheme(
primary = Color(0xFFD0BCFF),
onPrimary = Color(0xFF381E72),
primaryContainer = Color(0xFF4F378B),
onPrimaryContainer = Color(0xFFEADDFF),
secondary = Color(0xFFCCC2DC),
onSecondary = Color(0xFF332D41),
secondaryContainer = Color(0xFF4A4458),
onSecondaryContainer = Color(0xFFE8DEF8),
tertiary = Color(0xFFEFB8C8),
onTertiary = Color(0xFF492532),
tertiaryContainer = Color(0xFF633B48),
onTertiaryContainer = Color(0xFFFFD8E4),
error = Color(0xFFF2B8B5),
onError = Color(0xFF601410),
errorContainer = Color(0xFF8C1D18),
onErrorContainer = Color(0xFFF9DEDC),
background = Color(0xFF1C1B1F),
onBackground = Color(0xFFE6E1E5),
surface = Color(0xFF1C1B1F),
onSurface = Color(0xFFE6E1E5),
surfaceVariant = Color(0xFF49454F),
onSurfaceVariant = Color(0xFFCAC4D0),
outline = Color(0xFF938F99),
outlineVariant = Color(0xFF49454F),
scrim = Color(0xFF000000),
inverseSurface = Color(0xFFE6E1E5),
inverseOnSurface = Color(0xFF313033),
inversePrimary = Color(0xFF6750A4),
)
@Composable
fun MyAppTheme(
darkTheme: Boolean = isSystemInDarkTheme(),
dynamicColor: Boolean = true,
content: @Composable () -> Unit
) {
val context = LocalContext.current
val colorScheme = when {
dynamicColor && Build.VERSION.SDK_INT >= Build.VERSION_CODES.S -> {
if (darkTheme) dynamicDarkColorScheme(context)
else dynamicLightColorScheme(context)
}
darkTheme -> DarkColorScheme
else -> LightColorScheme
}
val view = LocalView.current
if (!view.isInEditMode) {
SideEffect {
val window = (view.context as Activity).window
window.statusBarColor = colorScheme.surface.toArgb()
window.navigationBarColor = colorScheme.surface.toArgb()
WindowCompat.getInsetsController(window, view).apply {
isAppearanceLightStatusBars = !darkTheme
isAppearanceLightNavigationBars = !darkTheme
}
}
}
MaterialTheme(
colorScheme = colorScheme,
typography = Typography,
content = content
)
}package com.softaai.myapp
import android.os.Bundle
import androidx.activity.ComponentActivity
import androidx.activity.compose.setContent
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.material3.MaterialTheme
import androidx.compose.material3.Surface
import androidx.compose.ui.Modifier
import com.softaai.myapp.ui.theme.MyAppTheme
class MainActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
MyAppTheme {
Surface(
modifier = Modifier.fillMaxSize(),
color = MaterialTheme.colorScheme.background
) {
// Your app content here
ProfileScreen()
}
}
}
}
}val colorScheme = MaterialTheme.colorScheme
// Primary colors
colorScheme.primary // Main brand color
colorScheme.onPrimary // Text on primary
colorScheme.primaryContainer // Lighter primary variant
colorScheme.onPrimaryContainer // Text on primary container
// Secondary colors
colorScheme.secondary // Secondary accent
colorScheme.onSecondary // Text on secondary
colorScheme.secondaryContainer // Lighter secondary
colorScheme.onSecondaryContainer // Text on secondary container
// Tertiary colors
colorScheme.tertiary // Third accent color
colorScheme.onTertiary // Text on tertiary
colorScheme.tertiaryContainer // Lighter tertiary
colorScheme.onTertiaryContainer // Text on tertiary container
// Surface and background
colorScheme.surface // Card/sheet background
colorScheme.onSurface // Text on surfaces
colorScheme.surfaceVariant // Alternative surface
colorScheme.onSurfaceVariant // Text on surface variant
colorScheme.background // Main app background
colorScheme.onBackground // Text on background
// Error colors
colorScheme.error // Error state color
colorScheme.onError // Text on error
colorScheme.errorContainer // Error message background
colorScheme.onErrorContainer // Text in error messages
// Utility colors
colorScheme.outline // Borders and dividers
colorScheme.outlineVariant // Subtle borders
colorScheme.surfaceTint // Elevation tint (usually primary)
colorScheme.scrim // Semi-transparent overlays
// Inverse colors (for tooltips, snackbars)
colorScheme.inverseSurface // High-contrast surface
colorScheme.inverseOnSurface // Text on inverse surface
colorScheme.inversePrimary // Primary color on inverse surface// Primary button
Button(
onClick = { },
colors = ButtonDefaults.buttonColors(
containerColor = MaterialTheme.colorScheme.primary,
contentColor = MaterialTheme.colorScheme.onPrimary
)
) {
Text("Click Me")
}
// Surface card
Card(
colors = CardDefaults.cardColors(
containerColor = MaterialTheme.colorScheme.surface
)
) {
Text(
text = "Card Content",
color = MaterialTheme.colorScheme.onSurface,
modifier = Modifier.padding(16.dp)
)
}
// Custom background
Box(
modifier = Modifier
.background(MaterialTheme.colorScheme.primaryContainer)
.padding(16.dp)
) {
Text(
text = "Custom Container",
color = MaterialTheme.colorScheme.onPrimaryContainer
)
}
// Error state
Surface(
color = MaterialTheme.colorScheme.errorContainer,
modifier = Modifier.padding(8.dp)
) {
Text(
text = "Error message",
color = MaterialTheme.colorScheme.onErrorContainer,
modifier = Modifier.padding(16.dp)
)
}The Material 3 colorScheme is a game-changer for Android app theming. It takes the complexity out of color design and gives you a robust, accessible, and beautiful color system right out of the box.
Here’s what we’ve covered:
Understanding: The Material 3 colorScheme generates complete, harmonious palettes from seed colors or wallpaper
Color Roles: Semantic color names ensure accessibility and visual consistency
Implementation: Simple Kotlin setup with Jetpack Compose and dynamic color support
Dynamic Color: Apps automatically match user wallpapers on Android 12+ for personalized experiences
Best Practices: Use semantic colors, test both themes, provide fallbacks, and optimize performance
Real Examples: Production-ready Kotlin code you can use in your projects immediately
Troubleshooting: Solutions to common issues developers face
The beauty of the Material 3 colorScheme is that it makes professional color design accessible to everyone. You don’t need to be a color theory expert to create stunning, accessible Android apps.
Start your next Android project by:
build.gradle.ktslightColorScheme() and darkColorScheme() in Theme.ktMaterialTheme.colorScheme throughout your composablesThe Material 3 colorScheme handles the complexity of color science, accessibility, and harmonization so you can focus on building amazing user experiences. And that’s what makes it so powerful.
Official Documentation:
Tools:
Sample Projects:
Now go build something beautiful with the Material 3 colorScheme in Kotlin..!
If you’re building Android apps with Jetpack Compose, chances are you’ve already used Compose Preview. Or at least clicked the little Preview tab in Android Studio and hoped it would magically show your UI.
Sometimes it does.
Sometimes it doesn’t.
In this blog, we’ll break down Compose Preview, covering everything from core mechanics to practical tips. You’ll learn:
Let’s start with the basics.
Compose Preview is a design-time tool in Android Studio that lets you see your Jetpack Compose UI without running the app on a device or emulator.
It renders composable functions directly inside the IDE.
That means:
In short, Compose Preview helps you design UI faster.
Let’s start with a basic example.
@Composable
fun Greeting(name: String) {
Text(text = "Hello, $name!")
}This composable works, but Android Studio can’t preview it yet. Why?
Because Greeting needs a parameter.
That’s where Compose Preview comes in.
@Preview(showBackground = true)
@Composable
fun GreetingPreview() {
Greeting(name = "Android")
}@Preview tells Android Studio: Render this composableshowBackground = true adds a white background so text is readableGreetingPreview() supplies sample data ("Android")This preview function is not used in production.
It exists only for design-time visualization.
That’s an important detail many beginners miss.
Compose Preview does not run your full app.
Instead, Android Studio:
That’s why previews are fast.
And that’s also why they’re limited.
With Compose Preview, you can:
All without touching an emulator.
For UI-heavy screens, this saves hours over time.
Compose Preview works best with small, focused composables.
That naturally pushes you toward:
This directly improves long-term maintainability.
Designers and developers can:
Compose Preview becomes a shared visual language.
Beyond basic previews, several advanced features make Compose Preview even more powerful.
The @Preview annotation accepts parameters that let you simulate different devices, screen sizes, and system settings.
@Preview(
name = "Small phone",
device = Devices.PIXEL_3A,
showSystemUi = true
)
@Preview(
name = "Large phone",
device = Devices.PIXEL_7_PRO,
showSystemUi = true
)
@Preview(
name = "Tablet",
device = Devices.PIXEL_TABLET,
showSystemUi = true
)
@Preview(
name = "Foldable",
device = Devices.FOLDABLE,
showSystemUi = true
)
@Preview(
name = "Landscape",
device = Devices.PIXEL_7_PRO,
widthDp = 891,
heightDp = 411
)
@Preview(
name = "Dark Theme",
uiMode = Configuration.UI_MODE_NIGHT_YES,
showBackground = true
)
@Preview(showBackground = true)
@Composable
fun ResponsiveLayoutPreview() {
MaterialTheme {
Surface(
modifier = Modifier.fillMaxSize(),
tonalElevation = 4.dp
) {
Column(
modifier = Modifier
.fillMaxSize()
.padding(24.dp),
verticalArrangement = Arrangement.spacedBy(20.dp)
) {
// Header
Text(
text = "Responsive UI",
style = MaterialTheme.typography.headlineMedium,
fontWeight = FontWeight.Bold
)
Text(
text = "Adaptive layouts across form factors",
style = MaterialTheme.typography.bodyMedium,
color = MaterialTheme.colorScheme.onSurfaceVariant
)
Divider()
Column(
verticalArrangement = Arrangement.spacedBy(12.dp)
) {
FeatureRow("Phones", "Compact & large screens")
FeatureRow("Tablets", "Expanded content layouts")
FeatureRow("Foldables", "Posture-aware UI")
FeatureRow("Themes", "Light & Dark mode ready")
}
}
}
}
}
@Composable
private fun FeatureRow(
title: String,
subtitle: String
) {
Column {
Text(
text = title,
style = MaterialTheme.typography.titleMedium,
fontWeight = FontWeight.SemiBold
)
Text(
text = subtitle,
style = MaterialTheme.typography.bodySmall,
color = MaterialTheme.colorScheme.onSurfaceVariant
)
}
}Let me break down what’s happening here:
You can stack multiple @Preview annotations on the same function to see all these variations simultaneously.
Sometimes you want to test your composables with different data sets. The @PreviewParameter annotation helps with this.
class UserStateProvider : PreviewParameterProvider<Boolean> {
override val values = sequenceOf(true, false)
}
@Preview(showBackground = true)
@Composable
fun StatusBadgePreview(
@PreviewParameter(UserStateProvider::class) isActive: Boolean
) {
Box(
modifier = Modifier
.size(100.dp)
.background(
color = if (isActive) Color.Green else Color.Red,
shape = CircleShape
),
contentAlignment = Alignment.Center
) {
Text(
text = if (isActive) "Active" else "Inactive",
color = Color.White,
fontWeight = FontWeight.Bold
)
}
}Here,
The UserStateProvider class implements PreviewParameterProvider<Boolean>, which means it provides a sequence of Boolean values for previewing. The values property returns both true and false.
When you use @PreviewParameter(UserStateProvider::class) on the isActive parameter, Compose Preview automatically generates two separate previews—one for each value in the sequence. You get both the active and inactive states without writing separate preview functions.
This approach is incredibly useful when testing with lists of data, different user types, or various configuration options.
Recent versions of Android Studio introduced interactive preview mode, which lets you click buttons, scroll lists, and interact with your UI directly in the preview pane. This feature brings you even closer to the actual app experience without leaving the IDE.
To enable it, look for the interactive mode toggle in the preview pane toolbar. Keep in mind that interactions are limited to the composable being previewed — you can’t navigate to other screens or trigger real network calls.
Compose Preview is helpful, but it’s not perfect.
Let’s talk honestly about its limitations.
Compose Preview does not handle:
If your composable depends on runtime data, preview will break.
That’s why preview-friendly composables should take simple, deterministic parameters that can be easily mocked in previews, rather than ViewModels.
You can’t:
Compose Preview shows how things look, not how they behave.
For behavior, you still need:
As your project grows:
This isn’t your fault. It’s a known trade-off.
Compose Preview is not a test.
It won’t catch:
Think of it as a design aid, not a quality gate.
To get the most out of Compose Preview:
Your preview functions should be straightforward and serve a single purpose. Don’t overcomplicate them with business logic or complex data transformations.
// Good: Simple and clear
@Preview(showBackground = true)
@Composable
fun LoadingButtonPreview() {
LoadingButton(
text = "Loading",
isLoading = true,
onClick = { }
)
}
// Avoid: Too much logic in preview
@Preview(showBackground = true)
@Composable
fun ComplicatedPreview() {
val viewModel = remember { MyViewModel() }
val state by viewModel.uiState.collectAsState()
// This won't work well in preview..!
}The first preview is clean and predictable. The second tries to instantiate a ViewModel, which likely depends on dependency injection, context, or other resources that aren’t available in preview mode.
When you have many related previews, organize them into preview groups for better navigation.
annotation class ComponentPreviews
@ComponentPreviews
@Preview(name = "Small Button", widthDp = 100)
@Preview(name = "Medium Button", widthDp = 200)
@Preview(name = "Large Button", widthDp = 300)
@Composable
fun ButtonSizePreview() {
Button(onClick = { }) {
Text("Click Me")
}
}By creating a custom annotation like @ComponentPreviews and applying it alongside your @Preview annotations, you can filter and group previews in Android Studio. This becomes invaluable when working on large projects with hundreds of composables.
Maintain a separate file with preview fixtures — sample data objects you can reuse across multiple previews.
// PreviewFixtures.kt
object PreviewFixtures {
val sampleUser = UserData(
name = "Amol Pawar",
email = "[email protected]",
joinDate = "March 2022"
)
val sampleMessages = listOf(
MessageData("Hello there!", "Amol", "9:00 AM"),
MessageData("How are you?", "Rutuja", "9:05 AM"),
MessageData("Doing great!", "Amol", "9:10 AM")
)
val longText = """
This is a longer text sample that helps us test how our UI
handles content that spans multiple lines. It's useful for
checking text wrapping, overflow behavior, and spacing.
""".trimIndent()
}Then use these fixtures in your previews:
@Preview(showBackground = true)
@Composable
fun UserProfileWithFixturePreview() {
UserProfile(
userId = "sample",
getUserData = { PreviewFixtures.sampleUser }
)
}This approach keeps your preview code DRY (Don’t Repeat Yourself) and makes it easier to maintain consistency across previews.
Don’t just preview your happy path. Create previews for edge cases like empty states, error states, and extreme data conditions.
@Preview(name = "Empty List", showBackground = true)
@Composable
fun EmptyListPreview() {
MessageList(messages = emptyList())
}
@Preview(name = "Very Long Name", showBackground = true)
@Composable
fun LongNamePreview() {
ProfileCard(
name = "Soundarya Bhagayalaxmi Venkateshwari Basapa Rao",
isOnline = true,
profileImageUrl = null
)
}
@Preview(name = "Single Character", showBackground = true)
@Composable
fun SingleCharPreview() {
ProfileCard(
name = "X",
isOnline = false,
profileImageUrl = null
)
}These edge case previews help you catch layout issues before they reach production. Does your text truncate properly? Do your empty states look intentional rather than broken?
The Compose Preview tool continues to evolve with each Android Studio release. Recent improvements include better performance, enhanced animation support, and more sophisticated interactive capabilities.
Looking ahead, we can expect:
The Android development community actively shapes these improvements through feedback, so don’t hesitate to file feature requests or bug reports.
Despite its limitations, Compose Preview is an essential part of modern Android development. The speed and convenience it offers make it ideal for rapid UI iteration and component-level design work.
The key is knowing when to use it. Compose Preview works best for visual validation and layout refinement, while emulators or real devices are still necessary for testing interactions, animations, and real data flows.
When used with preview-friendly composables and best practices, Compose Preview significantly improves development speed and feedback. It turns UI work into a more iterative, design-driven process rather than a cycle of long builds and guesswork.
Happy previewing..!
If you’ve ever opened your beautifully designed app on a tablet only to see it looking like a stretched-out phone screen, you know the pain. Or maybe you’ve watched your carefully crafted layout break apart on a foldable device. Trust me, I’ve been there. The good news..? Responsive and Adaptive UI in Jetpack Compose makes...
Jetpack Compose introduces a very different mental model compared to XML-based Android UI. One line that often confuses beginners (and even experienced Android devs at first) is:
onValueChange = { value = it }Especially when value is defined like this:
var value by remember { mutableStateOf(0) }At first glance, this line looks almost too simple — and that’s exactly why it’s confusing.
Let’s break down what’s really happening, why it’s written this way, and how it fits into Compose’s state-driven architecture.
Before diving into syntax, it’s important to understand how Compose thinks.
This single line:
onValueChange = { value = it }is the bridge between user interaction and state updates.
remember { mutableStateOf(...) } Really DoesConsider this state declaration:
var value by remember { mutableStateOf(0) }This does three important things:
mutableStateOfCreates an observable state holder.
Compose watches this value and tracks where it’s used.
rememberEnsures the state survives re-composition.
Without remember, the value would reset every time Compose redraws the UI.
by keywordThis is Kotlin property delegation. It allows you to write:
value = 5instead of:
value.value = 5So value behaves like a normal variable, but Compose is quietly observing it.
onValueChange Is (Conceptually)Most interactive Compose components (such as TextField, Slider, Checkbox) follow the same pattern:
Component(
value = currentState,
onValueChange = { /* update state */ }
)This is intentional and consistent.
onValueChange is:Compose itself does not store the value internally.
You are responsible for updating the state.
{ value = it }Let’s rewrite the lambda in a more explicit way:
onValueChange = { newValue ->
value = newValue
}Now it’s clearer.
it (or newValue) is the latest value from the UIvalue = it updates your stateThis is not assigning a random variable — it’s updating the single source of truth.
Here’s the real flow behind the scenes:
onValueChange(newValue)value = newValue)value recompose automaticallyThis is called unidirectional data flow, and it’s a core Compose principle.
State → UI<br>UI interaction → Callback → State update → RecompositionTextField@Composable
fun NameInput() {
var name by remember { mutableStateOf("") }
TextField(
value = name,
onValueChange = { name = it },
label = { Text("Enter your name") }
)
}Here,
name controls what the TextField displaysonValueChangenameIf you remove onValueChange, the field becomes read-only.
This design is intentional.
Compose avoids hidden internal state because:
You always know where your data lives.
onValueChange = { }Result: UI never changes.
remembervar value by mutableStateOf(0)Result: Value resets on every recomposition.
Compose renders, it doesn’t store business state. That’s your job (or ViewModel’s).
Once you understand this line, you understand 50% of Compose.
It enables:
Example with state hoisting:
@Composable
fun Counter(value: Int, onValueChange: (Int) -> Unit) {
Slider(
value = value.toFloat(),
onValueChange = { onValueChange(it.toInt()) }
)
}Now the parent owns the state — not the UI.
Compose does not mutate UI.
Compose reacts to state changes.
And this line:
onValueChange = { value = it }is simply saying:
“When the user changes something, update my state — and let Compose handle the rest.”
Once this clicks, Jetpack Compose stops feeling confusing and starts feeling refreshingly simple..!
State management is the backbone of any modern Android app. If state is messy, your UI becomes unpredictable, buggy, and hard to maintain. Jetpack Compose was designed to solve many of these problems, but only if you understand how State Management in Jetpack Compose actually works. In this post, we will break down modern state...
If you’ve been writing object-oriented code for a while, you’ve probably used inheritance a lot. It feels natural. You create a base class, extend it, override a few methods, and move on.
But as projects grow, inheritance often becomes hard to manage. Classes get tightly coupled. Changes ripple through the codebase. Small tweaks break unexpected things.
This is where Composition Over Inheritance comes in.
In this post, we’ll break down what Composition Over Inheritance really means, why it matters, and how it’s used naturally in modern Kotlin development, especially with Jetpack Compose.
Composition Over Inheritance is a design principle that says:
Prefer building classes by combining smaller, reusable components instead of extending base classes.
In simpler terms:
Instead of forcing behavior through class hierarchies, you compose behavior by using other objects.
Think of a smartphone.
A smartphone has a camera, battery, speaker, and screen.
It does not inherit from Camera, Battery, or Speaker.
That’s composition.
If you used inheritance here, the design would fall apart fast.
Inheritance looks clean at first, but it comes with hidden costs.
open class Vehicle {
open fun move() {
println("Vehicle is moving")
}
}
open class Car : Vehicle() {
override fun move() {
println("Car is driving")
}
}
class ElectricCar : Car() {
override fun move() {
println("Electric car is driving silently")
}
}At first glance, this seems fine.
But now imagine:
Your inheritance tree explodes.
Changes to Vehicle affect every subclass. You’re locked into decisions you made early, often before requirements were clear.
This is exactly what Composition Over Inheritance helps you avoid.
Let’s rewrite the same idea using composition.
interface Engine {
fun move()
}class GasEngine : Engine {
override fun move() {
println("Driving using gas engine")
}
}class ElectricEngine : Engine {
override fun move() {
println("Driving silently using electric engine")
}
}Each class has one clear responsibility.
class Car(private val engine: Engine) {
fun drive() {
engine.move()
}
}Now the Car has an engine, instead of being forced into a rigid hierarchy.
fun main() {
val electricCar = Car(ElectricEngine())
electricCar.drive()
val gasCar = Car(GasEngine())
gasCar.drive()
}
Output:
Driving silently using electric engine
Driving using gas engine
This is Composition Over Inheritance in action.
Here’s why modern Kotlin developers strongly prefer this approach.
Your classes depend on interfaces, not concrete implementations.
You can swap behaviors without rewriting class hierarchies.
You can inject fake or mock implementations easily.
Smaller classes. Clear responsibilities. Fewer surprises.
Jetpack Compose is built almost entirely on Composition Over Inheritance.
That’s not an accident.
class CustomButton : Button {
// override styles, behavior, states
}This leads to rigid UI components that are hard to reuse.
@Composable
fun MyButton(
text: String,
onClick: () -> Unit
) {
Button(onClick = onClick) {
Text(text)
}
}Here’s what’s happening:
MyButton is not extending ButtonButtonThis is Composition Over Inheritance at the UI level.
Compose avoids deep inheritance trees entirely.
Instead:
That’s composition by design.
Kotlin makes Composition Over Inheritance even easier with delegation.
interface Logger {
fun log(message: String)
}
class ConsoleLogger : Logger {
override fun log(message: String) {
println(message)
}
}
class UserService(private val logger: Logger) : Logger by loggerNow UserService automatically uses ConsoleLogger’s implementation without inheritance.
This keeps your code flexible and clean.
Inheritance is not evil. It’s just often overused.
Inheritance works best when:
If those conditions are missing, Composition Over Inheritance is usually the safer choice.
Let’s wrap it up.
If you’re writing Kotlin today, especially with Compose, you’re already using Composition Over Inheritance whether you realized it or not.
And once you start designing with it intentionally, your code gets simpler, not harder.
If you’ve built Android apps with Jetpack Compose, you’ve probably run into the question: Should I use ViewModel or rememberSaveable? Both help you keep state alive, but they work very differently depending on what’s happening to your app — like when the screen rotates or when the system kills your process.
This post will break down ViewModel and rememberSaveable, explain when to use each, and show real code examples so it finally clicks.
On Android, your app doesn’t always stay alive. Two big events affect your app’s state:
If you don’t handle these correctly, your users lose whatever they were doing. That’s where ViewModel and rememberSaveable come in.
At the simplest level, you use remember in Jetpack Compose to keep state alive across recompositions.
@Composable
fun CounterScreen() {
var count by remember { mutableStateOf(0) }
Button(onClick = { count++ }) {
Text("Count: $count")
}
}count won’t reset when Compose redraws the UI.remember only survives recompositions, not activity recreation.That’s why we need more powerful tools.
rememberSaveable goes one step further. It automatically saves your state into a Bundle using Android’s saved instance state mechanism.
@Composable
fun CounterScreen() {
var count by rememberSaveable { mutableStateOf(0) }
Button(onClick = { count++ }) {
Text("Count: $count")
}
}count survives.count also survives, because it was written to the saved instance state.Limitations:
Bundle (primitives, Strings, parcelables, etc.).A ViewModel is a lifecycle-aware container designed to hold UI data. It’s tied to a LifecycleOwner like an activity or a navigation back stack entry.
class CounterViewModel : ViewModel() {
var count by mutableStateOf(0)
}
@Composable
fun CounterScreen(viewModel: CounterViewModel = viewModel()) {
Button(onClick = { viewModel.count++ }) {
Text("Count: ${viewModel.count}")
}
}count survives. The same ViewModel instance is reused.count is lost. The ViewModel does not persist beyond process death.Here’s the clear breakdown:
Use rememberSaveable for small, lightweight UI state that:
Bundle.Examples:
Use ViewModel for more complex or long-lived state that:
Examples:
Often, the best solution is to use ViewModel and rememberSaveable together.
For example, a ViewModel manages your main UI state, but a few critical fields use rememberSaveable so they’re restored even after process death.
@Composable
fun FormScreen(viewModel: FormViewModel = viewModel()) {
var userInput by rememberSaveable { mutableStateOf("") }
Column {
TextField(
value = userInput,
onValueChange = { userInput = it }
)
Button(onClick = { viewModel.submit(userInput) }) {
Text("Submit")
}
}
}Here:
userInput is lightweight and saved with rememberSaveable.ViewModel takes care of processing and persisting the submitted data.The truth about ViewModel and rememberSaveable is simple once you think in terms of configuration changes vs process death:
remember → Only survives recomposition.rememberSaveable → Survives both rotation and process death (small, serializable state).ViewModel → Survives rotation, great for business logic, but not process death.Use them in combination, not competition. Each tool has its place, and knowing when to reach for which makes your Compose apps more resilient, smoother, and user-friendly.