Voice input can dramatically improve UX, yet most apps don’t use it. Here’s why you should:

✅ Zero app size increase - Uses Android’s native speech recognition (no libraries!) ✅ No permissions required - Works out of the box ✅ 3-5x faster input - Users can speak 150+ words/min vs typing 40 words/min ✅ Better accessibility - Essential for users with motor impairments ✅ Reduces friction - One tap vs multiple keyboard interactions ✅ Professional polish - Shows attention to UX details

The catch? It requires network connectivity and device support. But with proper availability checks, you can gracefully hide the feature when unavailable—making it a pure win when present.

Why Most Apps Skip This Feature

Despite being a native Android capability since API 8, many developers overlook voice input because:

1. Assumed complexity - Developers think it requires heavy ML libraries
2. Unclear implementation - Documentation is scattered
3. Network dependency concerns - Fear of handling edge cases
4. Device fragmentation worries - Uncertainty about availability
5. “The keyboard already has it” - The most common misconception

The truth? It’s simpler than adding a date picker, and this guide shows you how to handle all edge cases properly.

“But Users Have Voice Input on Their Keyboard Already!”

This is the most common objection developers raise. Yes, most mobile keyboards (Gboard, SwiftKey, Samsung Keyboard) have a mic button. But here’s why in-app voice input is still essential:

The Reality of Keyboard Voice Input Usage

📊 Usage statistics show a problem:

• Most users don’t even know the keyboard mic button exists
• Many forget about it after the initial setup
• Some disable it accidentally during keyboard customization
• The keyboard mic is visually small and easy to miss
• Users must actively look for it among other keyboard buttons

Why In-App Voice Input is Superior

1. Discoverability

❌ Keyboard mic: Hidden among 30+ keyboard keys, looks like any other button
✅ In-app mic: Prominent, contextual, right next to the input field

Example: A text field with a mic icon in the trailing position is immediately obvious. The keyboard mic? Users have to open the keyboard, scan for it, and remember it exists.

2. Context-Aware UX

// In-app voice can be contextual
TextField(
    label = { Text("Product Review") },
    trailingIcon = { MicIcon() }  // Clear purpose: "Speak your review"
)

The keyboard mic has no context - it’s the same button whether you’re entering an email, a password, or a product review. In-app voice input can show field-specific prompts like “Describe your issue” or “Speak your address”.

3. User Intent and Flow

• Keyboard mic: Requires users to:

  1. Tap the input field
  2. Wait for keyboard to appear
  3. Look for the mic button among keyboard keys
  4. Tap the mic
  5. Speak

• In-app mic: Simplified flow:

  1. Tap the mic icon (no keyboard needed!)
  2. Speak

Result: 2 fewer steps and no keyboard lag.

4. Visual Prominence

5. Accessibility Considerations

Users with motor impairments or visual limitations benefit significantly:

• Larger, easier-to-tap target
• Better contrast and visibility
• Screen readers can announce it contextually
• Doesn’t require precise keyboard navigation

6. User Psychology

Explicit invitation > Hidden capability

When users see a mic icon next to a text field, it:

• Signals that voice input is encouraged
• Reduces friction - they don’t need to hunt for it
• Increases adoption - visible features get used more
• Feels intentional - the app wants them to use voice

The keyboard mic feels like a generic fallback. The in-app mic feels like a first-class feature.

Real-World Data Points

While specific metrics vary by app, general patterns show:

• 📈 5-10x higher voice input usage with prominent in-app mic icons
• 🎯 New user discovery - many users don’t realize keyboard voice exists
• ♿ Accessibility gains - significant usage increase among users with disabilities
• 📱 Mobile-first users especially benefit (small screen, fat fingers)

The Hybrid Approach: Best of Both Worlds

The ideal solution is not either/or, but both:

✅ In-app mic for discoverability and context ✅ Keyboard mic still works as a fallback

Users get:

• A prominent, obvious voice input option
• Fallback if they prefer keyboard mic
• Contextual prompts and better UX
• No downsides!

When “Just Use the Keyboard” Fails

Some scenarios where keyboard voice input is insufficient:

1. Custom keyboards - Not all keyboards have voice input
2. Enterprise devices - Some organizations disable keyboard voice for security
3. Locked-down keyboards - Educational or restricted environments
4. Non-Google keyboards - Third-party keyboards may lack voice features
5. Disabled by user - Some users disable keyboard permissions

Your in-app implementation works regardless of keyboard choice.

The Bottom Line

“Users have voice on their keyboard” is like saying:

• “Don’t add a search icon, users can use Ctrl+F”
• “Don’t add a share button, users can copy-paste”
• “Don’t add undo, users can manually fix mistakes”

Just because a capability exists somewhere doesn’t mean it’s discoverable or convenient.

In-app voice input is about removing friction and guiding users toward better UX. The fact that keyboard voice exists is great - your in-app implementation makes it more likely to actually be used.

Ever wanted to add voice input to your Android app with minimal effort? Speech-to-Text functionality can dramatically improve user experience, especially for note-taking, messaging, or search features.

In this guide, we’ll build a clean, reusable Speech-to-Text component using Jetpack Compose that wraps Android’s native speech recognition API.

🎯 What We’re Building

A composable speech recognition system with:

• ✅ Simple API - One composable function to handle everything
• ✅ Lifecycle-aware - Properly managed with Activity Result API
• ✅ Locale support - Respects app language settings
• ✅ Availability checking - Gracefully handles devices without speech recognition
• ✅ Reusable state - Clean separation of concerns

🏗️ Architecture Overview

Our implementation consists of three main components:

1. SystemSpeechToTextHelper - A utility object that handles Android’s RecognizerIntent
2. SpeechToTextState - A state holder that manages the speech recognition launcher
3. rememberSpeechToText() - A composable function that creates and remembers the state
4. SpeechToTextButton (Bonus) - A ready-to-use UI component

📝 Implementation

1️⃣ The Helper Object

First, let’s create a helper object to encapsulate all Android-specific speech recognition logic:

object SystemSpeechToTextHelper {
    fun getAppLocale(): Locale {
        return try {
            Locale.forLanguageTag(Language.currentLocale.value.code)
        } catch (e: Exception) {
            Locale.getDefault()
        }
    }

    fun createRecognitionIntent(
        languageModel: String = RecognizerIntent.LANGUAGE_MODEL_FREE_FORM,
        locale: Locale = getAppLocale(),
        prompt: String? = null,
        maxResults: Int = 1
    ): Intent {
        return Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH).apply {
            putExtra(RecognizerIntent.EXTRA_LANGUAGE_MODEL, languageModel)
            putExtra(RecognizerIntent.EXTRA_LANGUAGE, locale.toLanguageTag())
            putExtra(RecognizerIntent.EXTRA_MAX_RESULTS, maxResults)
            prompt?.let { putExtra(RecognizerIntent.EXTRA_PROMPT, it) }
        }
    }

    fun extractSpokenText(result: ActivityResult): String? {
        return if (result.resultCode == Activity.RESULT_OK) {
            result.data
                ?.getStringArrayListExtra(RecognizerIntent.EXTRA_RESULTS)
                ?.firstOrNull()
                ?.takeIf { it.isNotBlank() }
        } else {
            null
        }
    }

    fun isRecognitionAvailable(context: Context): Boolean {
        val pm = context.packageManager
        val activities = pm.queryIntentActivities(
            Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH),
            PackageManager.MATCH_DEFAULT_ONLY
        )
        return activities.isNotEmpty()
    }
}

Key Features:

• 🌍 Locale handling - Automatically uses your app’s current language
• 🎤 Flexible configuration - Customize prompt, language model, and result count
• ✅ Validation - Ensures speech recognition is available on the device
• 🧹 Clean extraction - Filters out blank results

2️⃣ The State Holder

Next, we create a state class that manages the speech recognition lifecycle:

@Stable
class SpeechToTextState(
    private val launcher: ManagedActivityResultLauncher<Intent, ActivityResult>,
    private val prompt: String?,
    val isAvailable: Boolean
) {
    fun launch(
        customPrompt: String? = prompt,
        customLocale: Locale? = null
    ) {
        val intent = SystemSpeechToTextHelper.createRecognitionIntent(
            prompt = customPrompt,
            locale = customLocale ?: SystemSpeechToTextHelper.getAppLocale()
        )
        launcher.launch(intent)
    }
}

Why @Stable? The @Stable annotation tells Compose that this class follows specific stability contracts, allowing for better recomposition optimizations.

3️⃣ The Composable Function

Now comes the magic - a composable that ties everything together:

@Composable
fun rememberSpeechToText(
    prompt: String? = null,
    onResult: (String) -> Unit
): SpeechToTextState {
    val context = LocalContext.current

    val launcher = rememberLauncherForActivityResult(
        contract = ActivityResultContracts.StartActivityForResult()
    ) { result ->
        SystemSpeechToTextHelper.extractSpokenText(result)?.let { spokenText ->
            onResult(spokenText)
        }
    }

    val isAvailable = remember {
        SystemSpeechToTextHelper.isRecognitionAvailable(context)
    }

    return remember(launcher, prompt, isAvailable) {
        SpeechToTextState(
            launcher = launcher,
            prompt = prompt,
            isAvailable = isAvailable
        )
    }
}

Key Points:

• 🔄 Activity Result API - Modern way to handle activity results
• 💾 Remembered state - Survives recompositions
• 🎯 Callback pattern - Clean result handling via lambda

4️⃣ Bonus: Ready-to-Use Button Component

For convenience, here’s a pre-built button component:

@Composable
fun SpeechToTextButton(
    speechToTextState: SpeechToTextState,
    modifier: Modifier = Modifier,
    enabled: Boolean = true,
    iconSize: Dp = 24.dp,
    tint: Color = Color.Unspecified,
    contentDescription: String? = null
) {
    IconButton(
        onClick = speechToTextState::launch,
        enabled = enabled && speechToTextState.isAvailable,
        modifier = modifier
    ) {
        Icon(
            painter = painterResource(id = R.drawable.ic_mic),
            contentDescription = contentDescription,
            tint = tint,
            modifier = Modifier.size(iconSize)
        )
    }
}

🚀 Real-World Implementation Examples

Example 1: TextField with Voice Input (Production-Ready)

Here’s how to properly integrate voice input with a text field, including validation and network checking:

@Composable
fun SmartTextField(
    value: String,
    onValueChange: (String) -> Unit,
    modifier: Modifier = Modifier,
    label: String = "",
    placeholder: String = "",
    isError: Boolean = false,
    errorMessage: String? = null,
    maxLength: Int? = null,
    singleLine: Boolean = true
) {
    val context = LocalContext.current
    var showNetworkWarning by remember { mutableStateOf(false) }

    // Check network connectivity
    val isNetworkAvailable = remember {
        val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
        cm.activeNetwork != null
    }

    val speechToText = rememberSpeechToText(
        prompt = "Speak $label"
    ) { spokenText ->
        // Handle max length validation
        val newText = if (maxLength != null) {
            spokenText.take(maxLength)
        } else {
            spokenText
        }
        onValueChange(newText)
    }

    Column(modifier = modifier) {
        OutlinedTextField(
            value = value,
            onValueChange = { newValue ->
                // Enforce max length on manual input too
                val sanitized = if (maxLength != null) {
                    newValue.take(maxLength)
                } else {
                    newValue
                }
                onValueChange(sanitized)
            },
            label = { Text(label) },
            placeholder = { Text(placeholder) },
            isError = isError,
            singleLine = singleLine,
            modifier = Modifier.fillMaxWidth(),
            trailingIcon = {
                // Only show mic icon if speech recognition is available
                if (speechToText.isAvailable) {
                    IconButton(
                        onClick = {
                            if (isNetworkAvailable) {
                                speechToText.launch()
                            } else {
                                showNetworkWarning = true
                            }
                        }
                    ) {
                        Icon(
                            painter = painterResource(id = R.drawable.ic_mic),
                            contentDescription = "Voice input for $label",
                            tint = if (isNetworkAvailable) {
                                MaterialTheme.colorScheme.primary
                            } else {
                                MaterialTheme.colorScheme.onSurface.copy(alpha = 0.38f)
                            }
                        )
                    }
                }
            },
            supportingText = {
                when {
                    errorMessage != null && isError -> {
                        Text(
                            text = errorMessage,
                            color = MaterialTheme.colorScheme.error
                        )
                    }
                    maxLength != null -> {
                        Text(
                            text = "${value.length}/$maxLength",
                            modifier = Modifier.fillMaxWidth(),
                            textAlign = TextAlign.End
                        )
                    }
                }
            }
        )

        // Network warning
        if (showNetworkWarning) {
            Text(
                text = "Voice input requires internet connection",
                color = MaterialTheme.colorScheme.error,
                style = MaterialTheme.typography.bodySmall,
                modifier = Modifier.padding(start = 16.dp, top = 4.dp)
            )
            LaunchedEffect(Unit) {
                delay(3000)
                showNetworkWarning = false
            }
        }
    }
}

Usage:

@Composable
fun FeedbackForm() {
    var userName by remember { mutableStateOf("") }
    var feedback by remember { mutableStateOf("") }
    val maxFeedbackLength = 500

    Column(modifier = Modifier.padding(16.dp)) {
        SmartTextField(
            value = userName,
            onValueChange = { userName = it },
            label = "Your Name",
            placeholder = "John Doe",
            maxLength = 50,
            singleLine = true
        )

        Spacer(modifier = Modifier.height(16.dp))

        SmartTextField(
            value = feedback,
            onValueChange = { feedback = it },
            label = "Feedback",
            placeholder = "Tell us what you think...",
            maxLength = maxFeedbackLength,
            singleLine = false
        )
    }
}

Example 2: Search Bar with Voice Input

@Composable
fun VoiceEnabledSearchBar(
    query: String,
    onQueryChange: (String) -> Unit,
    onSearch: () -> Unit,
    modifier: Modifier = Modifier
) {
    val speechToText = rememberSpeechToText(
        prompt = "What are you looking for?"
    ) { spokenText ->
        onQueryChange(spokenText)
        // Auto-search after voice input
        onSearch()
    }

    SearchBar(
        query = query,
        onQueryChange = onQueryChange,
        onSearch = { onSearch() },
        active = false,
        onActiveChange = {},
        modifier = modifier,
        leadingIcon = {
            Icon(
                imageVector = Icons.Default.Search,
                contentDescription = "Search"
            )
        },
        trailingIcon = {
            Row {
                // Clear button
                if (query.isNotEmpty()) {
                    IconButton(onClick = { onQueryChange("") }) {
                        Icon(
                            imageVector = Icons.Default.Close,
                            contentDescription = "Clear"
                        )
                    }
                }

                // Voice input button (only if available)
                if (speechToText.isAvailable) {
                    IconButton(onClick = { speechToText.launch() }) {
                        Icon(
                            painter = painterResource(id = R.drawable.ic_mic),
                            contentDescription = "Voice search"
                        )
                    }
                }
            }
        },
        placeholder = { Text("Search products...") }
    ) {
        // Search suggestions
    }
}

Example 3: Multi-line Text Input with Append Mode

Perfect for note-taking or messaging apps:

@Composable
fun VoiceNoteEditor() {
    var noteContent by remember { mutableStateOf("") }
    var isRecording by remember { mutableStateOf(false) }

    val speechToText = rememberSpeechToText(
        prompt = "Speak your note"
    ) { spokenText ->
        // Intelligently append or replace
        noteContent = when {
            noteContent.isEmpty() -> spokenText
            noteContent.endsWith(".") || noteContent.endsWith("!") || noteContent.endsWith("?") ->
                "$noteContent $spokenText"
            else ->
                "$noteContent. $spokenText"
        }
        isRecording = false
    }

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(16.dp)
    ) {
        OutlinedTextField(
            value = noteContent,
            onValueChange = { noteContent = it },
            modifier = Modifier
                .fillMaxWidth()
                .weight(1f),
            placeholder = {
                Text("Start typing or tap the mic to speak...")
            },
            textStyle = MaterialTheme.typography.bodyLarge
        )

        Spacer(modifier = Modifier.height(16.dp))

        Row(
            modifier = Modifier.fillMaxWidth(),
            horizontalArrangement = Arrangement.SpaceBetween,
            verticalAlignment = Alignment.CenterVertically
        ) {
            // Word count
            Text(
                text = "${noteContent.split("\\s+".toRegex()).size} words",
                style = MaterialTheme.typography.bodySmall,
                color = MaterialTheme.colorScheme.onSurfaceVariant
            )

            // Voice input button
            if (speechToText.isAvailable) {
                FilledTonalButton(
                    onClick = {
                        isRecording = true
                        speechToText.launch()
                    }
                ) {
                    Icon(
                        painter = painterResource(id = R.drawable.ic_mic),
                        contentDescription = null,
                        modifier = Modifier.size(20.dp)
                    )
                    Spacer(modifier = Modifier.width(8.dp))
                    Text(if (isRecording) "Listening..." else "Add Voice Note")
                }
            }
        }
    }
}

Example 4: Form with Conditional Voice Input

Shows how to conditionally enable voice input based on field type:

@Composable
fun UserRegistrationForm() {
    var name by remember { mutableStateOf("") }
    var email by remember { mutableStateOf("") }
    var bio by remember { mutableStateOf("") }

    Column(modifier = Modifier.padding(16.dp)) {
        // Name field - voice input enabled
        SmartTextField(
            value = name,
            onValueChange = { name = it },
            label = "Full Name",
            maxLength = 50
        )

        Spacer(modifier = Modifier.height(16.dp))

        // Email field - voice input disabled (too error-prone)
        OutlinedTextField(
            value = email,
            onValueChange = { email = it },
            label = { Text("Email") },
            keyboardOptions = KeyboardOptions(
                keyboardType = KeyboardType.Email
            ),
            modifier = Modifier.fillMaxWidth()
            // No voice input for email - typing is more accurate
        )

        Spacer(modifier = Modifier.height(16.dp))

        // Bio field - voice input enabled
        SmartTextField(
            value = bio,
            onValueChange = { bio = it },
            label = "Bio",
            placeholder = "Tell us about yourself...",
            maxLength = 200,
            singleLine = false
        )
    }
}

⚠️ Critical Implementation Guidelines

1. Always Check Availability

Never show the mic icon if speech recognition is unavailable. This creates a poor UX when users tap it and nothing happens.

// ✅ GOOD - Only show when available
if (speechToText.isAvailable) {
    SpeechToTextButton(speechToTextState = speechToText)
}

// ❌ BAD - Shows disabled button (confusing UX)
SpeechToTextButton(
    speechToTextState = speechToText,
    enabled = speechToText.isAvailable  // Don't do this!
)

Why? On devices without Google services (some custom ROMs, enterprise devices), the feature won’t work. Hiding it entirely is cleaner than showing a permanently disabled button.

2. Handle Network Connectivity

Speech recognition requires active internet connection. Check before launching:

fun isNetworkAvailable(context: Context): Boolean {
    val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    return cm.activeNetwork != null
}

// Usage
val isNetworkAvailable = remember {
    isNetworkAvailable(context)
}

IconButton(
    onClick = {
        if (isNetworkAvailable) {
            speechToText.launch()
        } else {
            // Show snackbar or toast
            Toast.makeText(context, "Voice input requires internet", Toast.LENGTH_SHORT).show()
        }
    }
) {
    Icon(
        painter = painterResource(id = R.drawable.ic_mic),
        tint = if (isNetworkAvailable) {
            MaterialTheme.colorScheme.primary
        } else {
            MaterialTheme.colorScheme.onSurface.copy(alpha = 0.38f)
        }
    )
}

Best Practice: Show the mic icon in a dimmed state when offline, and display a brief message when tapped.

3. Input Validation After Voice Input

Always validate voice input just like you would keyboard input:

val speechToText = rememberSpeechToText { spokenText ->
    // Sanitize and validate
    val sanitized = spokenText
        .trim()
        .take(maxLength)
        .filter { it.isLetterOrDigit() || it.isWhitespace() }

    // Check if valid
    if (sanitized.isNotEmpty()) {
        inputValue = sanitized
    } else {
        showError("Invalid input received")
    }
}

Common validations:

• Length limits - Trim to max length
• Character filtering - Remove special chars if needed
• Empty checks - Handle blank results
• Format validation - Email, phone, etc.

4. Permissions - None Required!

Good news: No runtime permissions needed! Android’s speech recognition uses Google’s cloud service, which handles all the heavy lifting.

This is a huge advantage over custom speech recognition libraries that require RECORD_AUDIO permission.

5. Locale and Language Support

By default, the implementation respects your app’s current locale:

fun getAppLocale(): Locale {
    return try {
        Locale.forLanguageTag(Language.currentLocale.value.code)
    } catch (e: Exception) {
        Locale.getDefault()
    }
}

For multilingual apps, you can override the locale per-field:

// Spanish input for a specific field
speechToText.launch(customLocale = Locale("es", "ES"))

// French input
speechToText.launch(customLocale = Locale.FRANCE)

6. When NOT to Use Voice Input

Some fields are better suited for keyboard input:

❌ Email addresses - Punctuation and special characters are error-prone ❌ Passwords - Security risk + poor accuracy ❌ Credit card numbers - High error rate + security concerns ❌ URLs - Complex syntax not recognized well ❌ Code snippets - Special characters and formatting issues

✅ Good use cases: ✔ Names, addresses, descriptions ✔ Search queries ✔ Notes and messages ✔ Feedback and reviews ✔ Long-form text content

📊 UX Impact: The Numbers

Why voice input matters for your app’s user experience:

Real-world impact:

• 📝 A 100-word product review takes 2.5 minutes typing vs 40 seconds speaking
• 🔍 Voice search feels instantaneous vs typing lag
• ♿ Critical for users with motor impairments, RSI, or visual limitations
• 🌍 Easier for non-native keyboard users

✅ Why This Implementation is Superior

Compared to Keyboard Input:

✔ 3-5x faster input for long text ✔ Lower cognitive load - speaking is more natural than typing ✔ Better mobile experience - no tiny keyboard frustration ✔ Hands-free operation - can be used while multitasking

Compared to Third-Party Libraries:

✔ Zero app size increase - uses system APIs ✔ No permissions required - no RECORD_AUDIO prompt ✔ Always up-to-date - Google maintains the recognition engine ✔ No API keys or quotas - completely free ✔ Better privacy - uses Google’s standard speech service (same as Gboard)

Compared to Custom ML Models:

✔ No model training needed ✔ No storage for ML models (models can be 50MB+) ✔ Supports 100+ languages out of the box ✔ Continuously improving - benefits from Google’s updates

🎯 When Voice Input Makes Sense

Perfect Use Cases:

• 📝 Note-taking and memos - Natural dictation flow
• 💬 Messaging and chat - Quick voice-to-text messages
• 🔍 Search queries - Faster than typing
• 📋 Long-form content - Reviews, feedback, descriptions
• ♿ Accessibility features - Essential for many users
• 🚗 Hands-free scenarios - When typing isn’t safe

Skip Voice Input For:

• 🔒 Sensitive data - Passwords, PINs, SSNs
• 📧 Format-specific fields - Emails, URLs, credit cards
• 🔢 Numeric codes - OTPs, account numbers
• 💻 Technical input - Code, command-line syntax

🚀 Performance Considerations

App Size Impact: 0 KB - Uses system APIs only

Runtime Performance:

• Minimal memory usage
• Lazy initialization (only when needed)
• No background processes
• Network call only during active recognition

Battery Impact:

• Negligible - recognition happens on Google’s servers
• No continuous listening (only when user taps mic)
• Automatic cleanup after recognition

🎁 Quick Implementation Checklist

Before shipping voice input to production, verify:

• ✅ Mic icon only shows when isAvailable == true
• 🌐 Network connectivity is checked before launching
• ✍️ Input validation applied to voice results
• 📏 Max length limits enforced
• 🌍 Proper locale configuration
• ⚠️ User feedback for network errors
• 📱 Tested on devices without Google services
• ♿ Content descriptions added for accessibility
• 🎨 Visual feedback when mic is active (if custom UI)

🔗 Related Resources

• Android Speech Recognition Guide
• Jetpack Compose Activity Result API
• Material Design Voice Input Guidelines

💡 Final Thoughts

Voice input is a low-effort, high-impact feature that most apps overlook. With zero dependencies, no permissions, and minimal code, there’s little reason not to add it where appropriate.

The key differentiators:

1. Always check availability - hide the feature gracefully when unavailable
2. Validate network state - provide feedback when offline
3. Apply proper validation - treat voice input like any other input
4. Choose appropriate fields - not everything needs voice input

By following these guidelines, you’ll provide a professional, polished experience that sets your app apart.

That’s it! You now have a fully functional, production-ready speech-to-text component for Jetpack Compose. 🎉

Feel free to customize this implementation to fit your app’s specific needs. If you have questions or suggestions, reach out via my social handles! 😊

Happy coding! 🚀

Stop building custom camera UIs for document capture. ML Kit Document Scanner gives you a professional, AI-powered document scanning experience with just a few lines of code:

✅ Automatic edge detection - AI finds document boundaries instantly ✅ Perspective correction - Automatically straightens skewed documents ✅ Shadow removal - Intelligent lighting correction ✅ Multi-page support - Scan multiple pages in one session ✅ Quality enhancement - Auto-adjusts contrast and brightness ✅ Minimal code - 10 lines vs 500+ for custom implementation ✅ Small library size - ~3MB vs building from scratch

The result? Professional document scanning that rivals dedicated scanner apps, with 95% less code and effort.

Why Developers Still Use Basic Camera Capture

Despite ML Kit Document Scanner being available since 2022, most apps still use basic camera capture for documents. Here’s why:

1. Lack of awareness - Many developers don’t know it exists
2. “Camera is good enough” - Until users complain about quality
3. Custom UI preference - Wanting full control (unnecessary)
4. Assumed complexity - Thinking it requires ML expertise
5. Library size concerns - Actually very reasonable (~3MB)

The reality: Basic camera capture for documents creates terrible UX compared to proper document scanning.

The Problem with Basic Camera Capture

What Happens with Regular Camera:

// Typical camera implementation
val cameraIntent = Intent(MediaStore.ACTION_IMAGE_CAPTURE)
launcher.launch(cameraIntent)
// User gets: blurry, skewed, shadowy image

User experience issues:

• 📸 No guidance on document boundaries
• 🔲 Manual cropping required (tedious)
• 🌓 Poor lighting = unusable scans
• 📐 Perspective distortion (holding phone at angle)
• 📄 One page at a time (inefficient for multi-page docs)
• 🎨 No enhancement (washed out, low contrast)

Result: Users waste time cropping, retaking photos, and dealing with poor quality scans.

What ML Kit Document Scanner Provides

The Complete Package:

1. Real-time Edge Detection

   • AI instantly finds document corners
   • Visual overlay shows detected boundaries
   • Works even with complex backgrounds

2. Auto Perspective Correction

   • Straightens tilted/skewed documents
   • Removes keystoning (trapezoid effect)
   • Perfect rectangular output every time

3. Smart Enhancement

   • Removes shadows and glare
   • Adjusts contrast automatically
   • Optimizes for text readability
   • Handles various lighting conditions

4. Multi-page Scanning

   • Scan entire documents in one flow
   • Add/remove pages easily
   • Page reordering built-in

5. Multiple Export Formats

   • High-quality images (JPEG/PNG)
   • PDF generation built-in
   • Configurable resolution

Implementation

Step 1: Add Dependencies

Add to your app’s build.gradle:

dependencies {
    // ML Kit Document Scanner
    implementation 'com.google.android.gms:play-services-mlkit-document-scanner:16.0.0-beta1'
}

Library size: ~3MB (tiny compared to the functionality you get!)

Step 2: Configure Scanner Options

import com.google.mlkit.vision.documentscanner.GmsDocumentScanner
import com.google.mlkit.vision.documentscanner.GmsDocumentScannerOptions
import com.google.mlkit.vision.documentscanner.GmsDocumentScannerOptions.RESULT_FORMAT_JPEG
import com.google.mlkit.vision.documentscanner.GmsDocumentScannerOptions.RESULT_FORMAT_PDF
import com.google.mlkit.vision.documentscanner.GmsDocumentScannerOptions.SCANNER_MODE_FULL

// Create scanner with options
val options = GmsDocumentScannerOptions.Builder()
    .setGalleryImportAllowed(true)              // Allow importing from gallery
    .setPageLimit(10)                            // Max 10 pages per scan
    .setResultFormats(RESULT_FORMAT_JPEG, RESULT_FORMAT_PDF)  // Get both formats
    .setScannerMode(SCANNER_MODE_FULL)           // Full scanning experience
    .build()

val scanner = GmsDocumentScanning.getClient(options)

Scanner Modes:

• SCANNER_MODE_FULL - Complete UI with all features (recommended)
• SCANNER_MODE_BASE - Minimal UI, faster scanning

Step 3: Launch Scanner and Handle Results

// Activity Result Launcher
private val scannerLauncher = registerForActivityResult(
    ActivityResultContracts.StartIntentSenderForResult()
) { result ->
    if (result.resultCode == RESULT_OK) {
        val scanningResult = GmsDocumentScanningResult.fromActivityResultIntent(result.data)

        scanningResult?.let { scanResult ->
            // Get scanned pages
            scanResult.pages?.let { pages ->
                pages.forEach { page ->
                    // Access page image URI
                    val imageUri = page.imageUri

                    // Use the scanned image
                    loadScannedImage(imageUri)
                }
            }

            // Get PDF if generated
            scanResult.pdf?.let { pdf ->
                val pdfUri = pdf.uri
                val pageCount = pdf.pageCount

                // Save or share PDF
                savePdfDocument(pdfUri, pageCount)
            }
        }
    }
}

// Launch scanner
fun startDocumentScan() {
    scanner.getStartScanIntent(this)
        .addOnSuccessListener { intentSender ->
            scannerLauncher.launch(
                IntentSenderRequest.Builder(intentSender).build()
            )
        }
        .addOnFailureListener { exception ->
            // Handle error
            Log.e("Scanner", "Failed to start scanner", exception)
        }
}

Step 4: Complete Jetpack Compose Integration

Here’s a production-ready composable implementation:

@Composable
fun DocumentScannerButton(
    onDocumentsScanned: (List<Uri>) -> Unit,
    onPdfGenerated: (Uri, Int) -> Unit,
    modifier: Modifier = Modifier,
    enabled: Boolean = true
) {
    val context = LocalContext.current
    val activity = context as? ComponentActivity

    // Scanner options
    val scanner = remember {
        val options = GmsDocumentScannerOptions.Builder()
            .setGalleryImportAllowed(true)
            .setPageLimit(10)
            .setResultFormats(RESULT_FORMAT_JPEG, RESULT_FORMAT_PDF)
            .setScannerMode(SCANNER_MODE_FULL)
            .build()
        GmsDocumentScanning.getClient(options)
    }

    // Result launcher
    val scannerLauncher = rememberLauncherForActivityResult(
        contract = ActivityResultContracts.StartIntentSenderForResult()
    ) { result ->
        if (result.resultCode == ComponentActivity.RESULT_OK) {
            val scanResult = GmsDocumentScanningResult.fromActivityResultIntent(result.data)

            scanResult?.let {
                // Handle scanned images
                it.pages?.let { pages ->
                    val imageUris = pages.mapNotNull { page -> page.imageUri }
                    if (imageUris.isNotEmpty()) {
                        onDocumentsScanned(imageUris)
                    }
                }

                // Handle PDF
                it.pdf?.let { pdf ->
                    onPdfGenerated(pdf.uri, pdf.pageCount)
                }
            }
        }
    }

    // Launch scanner
    fun launchScanner() {
        activity?.let { act ->
            scanner.getStartScanIntent(act)
                .addOnSuccessListener { intentSender ->
                    scannerLauncher.launch(
                        IntentSenderRequest.Builder(intentSender).build()
                    )
                }
                .addOnFailureListener { exception ->
                    Log.e("DocumentScanner", "Failed to start", exception)
                }
        }
    }

    Button(
        onClick = { launchScanner() },
        enabled = enabled,
        modifier = modifier
    ) {
        Icon(
            imageVector = Icons.Default.DocumentScanner,
            contentDescription = null,
            modifier = Modifier.size(20.dp)
        )
        Spacer(modifier = Modifier.width(8.dp))
        Text("Scan Document")
    }
}

Usage:

@Composable
fun DocumentUploadScreen() {
    var scannedImages by remember { mutableStateOf<List<Uri>>(emptyList()) }
    var pdfUri by remember { mutableStateOf<Uri?>(null) }

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(16.dp)
    ) {
        DocumentScannerButton(
            onDocumentsScanned = { images ->
                scannedImages = images
                Toast.makeText(
                    context,
                    "Scanned ${images.size} pages",
                    Toast.LENGTH_SHORT
                ).show()
            },
            onPdfGenerated = { uri, pageCount ->
                pdfUri = uri
                Toast.makeText(
                    context,
                    "PDF created with $pageCount pages",
                    Toast.LENGTH_SHORT
                ).show()
            }
        )

        // Display scanned images
        LazyColumn {
            items(scannedImages) { imageUri ->
                AsyncImage(
                    model = imageUri,
                    contentDescription = "Scanned page",
                    modifier = Modifier
                        .fillMaxWidth()
                        .height(200.dp)
                        .padding(vertical = 8.dp)
                )
            }
        }
    }
}

Real-World Use Cases

1. ID/Document Verification

Perfect for KYC (Know Your Customer) flows:

@Composable
fun KYCDocumentUpload() {
    var idCardUri by remember { mutableStateOf<Uri?>(null) }

    Column {
        Text("Upload ID Card", style = MaterialTheme.typography.titleLarge)

        DocumentScannerButton(
            onDocumentsScanned = { images ->
                idCardUri = images.firstOrNull()
                // Automatically extract text with ML Kit Text Recognition
                verifyIDDocument(idCardUri)
            },
            onPdfGenerated = { _, _ -> }
        )

        idCardUri?.let { uri ->
            AsyncImage(
                model = uri,
                contentDescription = "ID Card",
                modifier = Modifier.fillMaxWidth()
            )
        }
    }
}

2. Receipt/Invoice Scanning

For expense tracking or accounting apps:

@Composable
fun ExpenseReceiptScanner(
    onReceiptScanned: (Uri, String) -> Unit
) {
    DocumentScannerButton(
        onDocumentsScanned = { images ->
            images.firstOrNull()?.let { receiptUri ->
                // Extract text from receipt
                val amount = extractReceiptAmount(receiptUri)
                onReceiptScanned(receiptUri, amount)
            }
        },
        onPdfGenerated = { _, _ -> }
    )
}

3. Multi-page Document Archival

For scanning contracts, forms, or books:

@Composable
fun DocumentArchiver() {
    var documentTitle by remember { mutableStateOf("") }
    var savedPdfUri by remember { mutableStateOf<Uri?>(null) }

    Column {
        OutlinedTextField(
            value = documentTitle,
            onValueChange = { documentTitle = it },
            label = { Text("Document Name") }
        )

        DocumentScannerButton(
            onDocumentsScanned = { images ->
                // Individual pages available if needed
            },
            onPdfGenerated = { pdfUri, pageCount ->
                // Save PDF with title
                savedPdfUri = pdfUri
                saveToDocuments(documentTitle, pdfUri)
            }
        )
    }
}

4. Note-Taking Apps

Scan handwritten notes or whiteboard content:

@Composable
fun ScanAndConvertNotes() {
    DocumentScannerButton(
        onDocumentsScanned = { images ->
            images.forEach { imageUri ->
                // Use ML Kit Text Recognition
                extractHandwrittenText(imageUri) { text ->
                    // Convert to editable text
                    saveAsNote(text)
                }
            }
        },
        onPdfGenerated = { _, _ -> }
    )
}

Advanced Configuration Options

Custom Scanner Settings

// Minimal scanner (faster, less features)
val minimalOptions = GmsDocumentScannerOptions.Builder()
    .setScannerMode(SCANNER_MODE_BASE)
    .setPageLimit(1)
    .setResultFormats(RESULT_FORMAT_JPEG)
    .setGalleryImportAllowed(false)
    .build()

// Professional scanner (all features)
val professionalOptions = GmsDocumentScannerOptions.Builder()
    .setScannerMode(SCANNER_MODE_FULL)
    .setPageLimit(50)                           // Up to 50 pages
    .setResultFormats(RESULT_FORMAT_JPEG, RESULT_FORMAT_PDF)
    .setGalleryImportAllowed(true)
    .build()

Handling Different Result Formats

scanningResult?.let { result ->
    // Option 1: Process individual images
    result.pages?.forEach { page ->
        val imageUri = page.imageUri
        // Each page as separate image
        processImage(imageUri)
    }

    // Option 2: Get consolidated PDF
    result.pdf?.let { pdf ->
        val pdfUri = pdf.uri
        val pageCount = pdf.pageCount
        // Single PDF with all pages
        sharePDF(pdfUri)
    }
}

Comparison: Before vs After

Custom Camera Implementation (Old Way)

// 500+ lines of code for:
class CustomCameraActivity : AppCompatActivity() {
    private lateinit var cameraProvider: ProcessCameraProvider
    private var imageCapture: ImageCapture? = null

    // Camera setup
    // Permission handling
    // Custom UI overlay
    // Manual cropping UI
    // Image enhancement logic
    // Edge detection algorithm
    // Perspective correction math
    // Multi-page management
    // PDF generation
    // Error handling
    // ... 450+ more lines
}

Problems:

• 500+ lines of complex code
• Camera permission management
• Device compatibility issues
• Manual cropping UI needed
• No auto enhancement
• Mediocre results
• Maintenance burden

ML Kit Document Scanner (New Way)

// 10 lines of code:
val scanner = GmsDocumentScanning.getClient(options)

scanner.getStartScanIntent(activity)
    .addOnSuccessListener { intentSender ->
        launcher.launch(IntentSenderRequest.Builder(intentSender).build())
    }

// Done! Professional scanning with AI.

Benefits:

• 10 lines of code
• No permissions needed
• Works on all devices
• Auto cropping included
• AI enhancement
• Professional results
• Zero maintenance

Performance & Best Practices

Library Size Impact

ML Kit Document Scanner:  ~3MB
Custom camera + CV libs:  ~15-25MB

Worth it? Absolutely. You get professional features for 1/5th the size.

Memory Management

// Don't load all images at once
scannedImages.forEach { uri ->
    // Process one at a time
    processImage(uri)
    // Or use paging for large batches
}

// Use Coil/Glide for efficient image loading
AsyncImage(
    model = imageUri,
    contentDescription = null,
    contentScale = ContentScale.Fit
)

Error Handling

scanner.getStartScanIntent(activity)
    .addOnSuccessListener { intentSender ->
        launcher.launch(IntentSenderRequest.Builder(intentSender).build())
    }
    .addOnFailureListener { exception ->
        when (exception) {
            is MlKitException -> {
                // ML Kit specific error
                showError("Scanner unavailable: ${exception.message}")
            }
            else -> {
                // Generic error
                showError("Failed to start scanner")
            }
        }
    }

Testing on Different Devices

ML Kit Document Scanner works on:

• ✅ Android 5.0+ (API 21+)
• ✅ Devices with Google Play Services
• ✅ All form factors (phones, tablets)
• ✅ Various camera qualities

Note: Requires Google Play Services. Check availability:

fun isDocumentScannerAvailable(context: Context): Boolean {
    return try {
        val status = GoogleApiAvailability.getInstance()
            .isGooglePlayServicesAvailable(context)
        status == ConnectionResult.SUCCESS
    } catch (e: Exception) {
        false
    }
}

When to Use ML Kit vs Custom Camera

Use ML Kit Document Scanner When:

✅ Scanning documents, receipts, IDs, contracts ✅ Need professional quality scans ✅ Want multi-page support ✅ Need PDF generation ✅ Auto enhancement required ✅ Limited development time/budget

Use Custom Camera When:

⚠️ Capturing photos (not documents) ⚠️ Need real-time filters/effects ⚠️ Building a camera app ⚠️ Very specific custom workflow ⚠️ Can’t use Google Play Services

Bottom line: For 95% of document capture use cases, ML Kit is superior.

Common Pitfalls to Avoid

1. Not Checking for Play Services

// ❌ BAD - Assumes availability
scanner.getStartScanIntent(activity)

// ✅ GOOD - Check first
if (isDocumentScannerAvailable(context)) {
    scanner.getStartScanIntent(activity)
} else {
    showFallbackOption()
}

2. Ignoring URI Permissions

// ✅ Grant persistent URI permissions
contentResolver.takePersistableUriPermission(
    uri,
    Intent.FLAG_GRANT_READ_URI_PERMISSION
)

3. Not Handling Page Limits

// ✅ Set appropriate page limits
val options = GmsDocumentScannerOptions.Builder()
    .setPageLimit(
        if (multiPage) 50 else 1  // Adjust based on use case
    )
    .build()

Integration with Other ML Kit Features

Combine with Text Recognition

// Scan document, then extract text
onDocumentsScanned = { images ->
    images.forEach { imageUri ->
        recognizeText(imageUri) { extractedText ->
            // Use extracted text
            saveDocumentWithText(imageUri, extractedText)
        }
    }
}

fun recognizeText(uri: Uri, onTextExtracted: (String) -> Unit) {
    val image = InputImage.fromFilePath(context, uri)
    val recognizer = TextRecognition.getClient(TextRecognizerOptions.DEFAULT_OPTIONS)

    recognizer.process(image)
        .addOnSuccessListener { visionText ->
            onTextExtracted(visionText.text)
        }
}

Barcode Scanning from Documents

// Scan document with barcode/QR code
onDocumentsScanned = { images ->
    images.forEach { imageUri ->
        scanBarcode(imageUri) { barcodeValue ->
            // Handle barcode data
        }
    }
}

Quick Implementation Checklist

Before shipping document scanning to production:

• ✅ Added ML Kit dependency (~3MB)
• 📱 Tested on devices with/without Play Services
• 🔧 Configured appropriate scanner mode
• 📄 Set reasonable page limits
• 🎨 Handled both image and PDF results
• ⚠️ Implemented error handling
• 💾 Managed URI permissions properly
• 🧪 Tested with various document types
• 📏 Verified image quality/resolution
• 🔄 Added loading states for scanning

Real-World Impact

Before ML Kit:

• ⏱️ Users spent 2-3 minutes per document (capture, crop, adjust)
• 😤 30-40% required retakes due to poor quality
• 📉 High abandonment rates on document upload flows
• 🐛 Constant bug reports about scanning issues

After ML Kit:

• ⚡ 20-30 seconds per document (all automatic)
• ✨ <5% retake rate (AI handles most issues)
• 📈 50-70% improvement in completion rates
• 😊 Positive feedback about scanning experience

🔗 Related Resources

• ML Kit Document Scanner Documentation
• ML Kit Text Recognition
• Google Play Services Setup

💡 Final Thoughts

Stop wasting time building custom document capture solutions. ML Kit Document Scanner gives you professional, AI-powered scanning with minimal code.

The math is simple:

• 🕐 Custom implementation: 2-3 weeks + ongoing maintenance
• ⚡ ML Kit integration: 2-3 hours + zero maintenance
• 🎯 Result quality: ML Kit wins every time

Key takeaways:

1. Stop using basic camera capture for documents
2. ML Kit is tiny (~3MB) for massive functionality
3. 10 lines of code beats 500+ lines
4. Professional results without CV expertise
5. Users notice the difference - completion rates improve significantly

Your users deserve better than blurry, crooked photos. Give them professional document scanning with ML Kit.

That’s it! You now have the knowledge to implement professional document scanning in your Android app. 🎉

Feel free to reach out via my social handles with questions or to share your implementation! 😊

Happy scanning! 📄✨

This article is primarily a self-note that I keep updating as I learn more about Claude Code. The AI tooling landscape evolves rapidly, so some information might be outdated by the time you read this. If you find something that needs updating, feel free to reach out!

Whether you’re a junior developer just getting started or a senior developer looking to boost your workflow, Claude Code has something for everyone.

Why Should You Care?

If you’ve read my Solutionist Mindset talk, you know I believe in using AI as a copilot, not a pilot. Claude Code embodies this philosophy perfectly—it’s a CLI tool that sits alongside your existing workflow, helping you move faster while keeping you in control.

For Android and Compose Multiplatform (KMP) developers like us, having a tool that understands our codebase context is game-changing. Gradle configurations, multi-module architectures, platform-specific implementations—Claude Code can navigate all of this.

What is Claude Code?

Claude Code is Anthropic’s official CLI tool that brings Claude directly into your terminal. Unlike the web interface, it:

• Has full access to your codebase (with your permission)
• Can read, write, and edit files directly
• Runs shell commands for you
• Understands project context across multiple files
• Integrates with Git for version control operations

Think of it as having a senior developer sitting next to you who can:

• Explore your codebase instantly
• Write and refactor code
• Debug issues by reading logs and stack traces
• Create commits and PRs
• Explain complex code sections

Latest Updates (January 2026)

Update available for Claude Code users (v: 2.1.2)!

Model Selection

Opus 4.5 is now available in model selection. While Sonnet is superior for general coding tasks, Opus is amazing for complex features and crazy bugs. You can use -m flag for selecting a specific model for particular task sessions.

[!WARNING] Token Usage Warning: Continuous usage of Opus models will consume your rate limits and quota significantly faster (approx. 5-10x) than Sonnet. Use Opus only for complex debugging or architectural tasks.

# Run with a specific model
claude -m claude-opus-4-20250514

Official Plugins

Check out the official plugins:

• All Plugins
• Code Review Plugin

Getting Started

Installation

# Using npm
npm install -g @anthropic-ai/claude-code

# Using Homebrew (macOS)
brew install claude-code

After installation, run claude in your terminal to start an interactive session. You’ll need to authenticate with your Anthropic API key or use the claude --login command to login via the browser.

Basic Usage

Navigate to your project directory and simply run:

claude

This starts an interactive session where you can ask questions, request code changes, or explore your codebase.

Essential Commands Every Developer Should Know

1️⃣ Slash Commands

Claude Code has built-in slash commands that trigger specific workflows:

2️⃣ The CLAUDE.md File

One of the most powerful features for multi-module Android/KMP projects is the CLAUDE.md file. Create this at your project root:

# Project: MyKMPApp

## Architecture
- Multi-module KMP project
- Shared module: commonMain, androidMain, iosMain
- Android app module with Jetpack Compose UI
- iOS app using SwiftUI

## Key Conventions
- Use Koin for dependency injection
- Room for local database (Android), SQLDelight for shared
- Ktor for networking
- Kotlin Coroutines + Flow for async operations

## Build Commands
- `./gradlew assembleDebug` - Build Android debug
- `./gradlew :shared:build` - Build shared module only
- `./gradlew connectedAndroidTest` - Run instrumented tests

## Module Structure
- :app - Android application entry point
- :shared - KMP shared code
- :feature:home - Home feature module
- :feature:settings - Settings feature module
- :core:network - Networking utilities
- :core:database - Database layer

Claude reads this file and uses it as persistent context for every conversation. This is incredibly useful for:

• Multi-module navigation - Claude knows your module structure
• Consistent coding patterns - Follows your conventions
• Faster builds - Knows the right Gradle commands

3️⃣ Vim-Style Keybindings

For terminal enthusiasts, Claude Code supports vim keybindings:

Practical Use Cases for Android/KMP Developers

Use Case 1: Exploring Unfamiliar Codebases

When you join a new project or inherit legacy code:

You: How is the authentication flow implemented in this app?
     Show me the key files involved.

Claude will search through your codebase, identify relevant files (ViewModels, Repositories, API services), and explain the flow.

Use Case 2: Writing Compose UI Components

You: Create a bottom sheet component for filtering products.
     It should have checkboxes for categories and a price range slider.
     Follow our existing design system in :core:designsystem module.

Claude will:

1. Look at your existing design system
2. Match the patterns and naming conventions
3. Create the component following your architecture

Use Case 3: Debugging Build Issues

You: I'm getting this Gradle error when building the shared module:
     [paste error here]

     Help me understand and fix it.

Claude can read your build.gradle.kts files, understand the dependency graph, and suggest fixes.

Use Case 4: Writing Platform-Specific Implementations

You: I need to implement biometric authentication.
     Create the expect/actual declarations for Android and iOS
     in the :core:auth module.

Claude understands KMP’s expect/actual mechanism and generates appropriate platform-specific code.

Use Case 5: Creating Git Commits

You: /commit

Claude will:

1. Analyze your staged changes
2. Understand the context of modifications
3. Generate a meaningful commit message
4. Create the commit

Use Case 6: Room Database Migrations

You: I need to add a 'lastSyncedAt' column to the UserEntity.
     Create the migration and update the entity.

Claude handles the boilerplate of Room migrations, which can be error-prone manually.

Best Practices for Effective Usage

✅ DO

1. Be specific with context - Instead of “fix this bug”, say “fix the crash in UserRepository.kt when the token expires” make sure you add the file and line-number of the function or scope.

2. Review generated code - Always understand what Claude writes. Don’t blindly accept suggestions.

3. Use it for exploration - Ask Claude to explain complex parts of your codebase or third-party libraries

4. Leverage for boilerplate - Let Claude handle repetitive tasks like:

   • Creating data classes from API responses
   • Writing Room entities and DAOs
   • Setting up Hilt/Koin modules
   • Creating navigation graphs
   • Writing unit test boilerplate

5. Maintain your CLAUDE.md - Keep it updated as your project evolves

6. Use the right model for the task - Haiku for quick questions, Sonnet for general coding, Opus for complex debugging

❌ DON’T

1. Don’t share sensitive data - Avoid passing API keys, secrets, or user data through Claude

2. Don’t skip the review - Especially for security-critical code (authentication, payment processing, encryption etc)

3. Don’t use it as a crutch - You should still understand the fundamentals. AI is a multiplier, not a replacement.

4. Don’t expect perfection - Claude can make mistakes. Treat its output as a starting point.

5. Don’t ignore Gradle sync - After Claude modifies build.gradle.kts, sync manually in Android Studio

Cost Management Tips

Claude Code uses API tokens, which cost money. Here’s how to optimize:

1️⃣ Choose the Right Model

2️⃣ Use /compact Regularly

Long conversations consume more tokens. Use /compact to summarize and reduce context.

3️⃣ Start Fresh for New Tasks

Use /clear when switching to unrelated tasks. No need to carry previous context.

4️⃣ Be Concise

Instead of:

"Hey Claude, I was wondering if you could maybe help me
understand how the user authentication works in this app,
like when someone logs in, what happens step by step?"

Try:

"Explain the login flow. Start from LoginViewModel."

6️⃣ Offload Tasks to Other Models/Tools (Save those Tokens!)

Not everything requires Claude Code’s deep context awareness. Save your tokens by routing tasks to the right tool:

• Use Gemini for Quick Concepts: Need to understand “How LruCache works internally” or “Explain the Builder pattern”? Use Gemini. It’s fast, free/cheap, and great for general knowledge that doesn’t need your private codebase context.
• Use ChatGPT for High-Level Project Questions: If you need advice on “Best practices for modularizing a KMP project” or architecture discussions where providing full code access isn’t necessary, ChatGPT is a great option.
• Use CLI Tools for Quick Answers: If you’re a terminal power user (using tmux, dia, etc.), tools like ddgr (DuckDuckGo from terminal) or Ollama (local models) are fantastic for quick lookups without leaving your flow.

[!TIP] Pro Tip: Reserve Claude Code for tasks that specifically need to read your files, understand your project structure, or perform edits. For everything else, cheaper (or free) alternatives often work just as well!

7️⃣ Check Costs with /cost

Regularly run /cost to monitor your usage.

Integration with Development Workflow

IDE Integration

Claude Code works alongside your IDE, not inside it. A typical workflow:

1. Have your IDE open (Android Studio / Fleet / IntelliJ)
2. Run Claude in a terminal (split screen works great)
3. Ask Claude to make changes
4. Review changes in IDE (they appear instantly)
5. Test and iterate

Git Workflow Integration

Claude Code integrates nicely with Git:

# Start a session
claude

# Create meaningful commits
You: /commit

# Create a pull request
You: Create a PR for these changes. The target branch is develop.

# Review code before pushing
You: Review the changes in the last commit for any issues.

Common Gotchas for Android/KMP Projects

1️⃣ Gradle Sync After Changes

When Claude modifies build.gradle.kts files, you’ll need to sync in Android Studio manually. Claude can’t trigger this for you.

2️⃣ Resource Files

Claude can create/modify XML resources (layouts, strings, drawables), but be careful with:

• Generated resources (R class) - These regenerate on build
• Vector drawables - Complex paths might need manual tweaking

3️⃣ Compose Preview

Claude-generated Compose components might need @Preview annotations added for visibility in Android Studio’s preview pane.

4️⃣ iOS-Specific Code

For KMP projects, Claude can write Swift/Objective-C code for iOS implementations, but:

• You’ll need Xcode to verify it compiles
• Swift interop with Kotlin can be tricky

5️⃣ Version Catalog

If you use libs.versions.toml, make sure Claude knows about it in your CLAUDE.md. Otherwise, it might use hardcoded versions.

My Personal Workflow

Here’s how I typically use Claude Code for Android development:

1. Morning exploration - “What did I work on yesterday? Show me recent changes.”

2. Feature development - Start with asking Claude to explore existing patterns, then implement following those patterns

3. Code review helper - “Review this ViewModel for potential memory leaks or coroutine issues”

4. Documentation - “Generate KDoc comments for the public methods in NetworkClient.kt”

5. Refactoring - “Migrate this callback-based API to use Kotlin Coroutines with Flow”

6. Test writing - “Write unit tests for UserRepository using MockK”

Advanced: MCP Servers

Claude Code supports Model Context Protocol (MCP) servers, which extend its capabilities. For Android developers, interesting MCPs include:

• File system access - Already built-in
• Git operations - Built-in
• Web search - For documentation lookups
• Custom tools - You can create your own MCP servers

Check out the MCP Documentation for more details.

Useful One-Liners

Quick commands I use frequently:

# Start with a specific model for complex tasks
claude -m claude-opus-4-20250514

# Resume last conversation
claude --resume

# Check installation health
claude /doctor

# Quick code review
claude "Review my staged changes for issues"

What’s Next?

This article covers the fundamentals, but Claude Code is constantly evolving. I plan to update this note as I discover:

• New features and capabilities
• Better workflows for KMP development
• Integration patterns with CI/CD
• Team collaboration strategies

Final Thoughts

Claude Code is a powerful addition to the Android/KMP developer toolkit. It’s not about replacing your skills—it’s about amplifying them. Use it to handle boilerplate, explore unfamiliar code, and move faster on repetitive tasks.

But remember: You are still the pilot. Claude is your copilot. Understand what it generates, review its suggestions, and keep learning the fundamentals.

The developers who thrive in the AI age won’t be those who code the fastest—they’ll be the ones who solve problems thoughtfully while leveraging every tool at their disposal.

Resources

• Official Claude Code Documentation
• Claude Code GitHub
• Official Plugins
• Model Context Protocol
• My Solutionist Mindset Talk

Feel free to connect with me on: 📩 Email 🌍 Website

I wish to keep this article as a living document. Last updated: January 2026

The green hyperlinks are clickable

Pretty straightforward, right? Just a bit of text with two clickable links — Privacy Policy and Terms of Service.

But as I started implementing it, I realized: there isn’t a single complete guide explaining how to make part of a text clickable using AnnotatedString in Jetpack Compose — especially with the new LinkAnnotation API and a custom URL handler for better control.

So I’m writing this as both a reference for myself and for anyone else struggling with this tiny, under-documented detail.

Why Custom URL Handling?

By default, Compose can open links using the system browser. But what if you want:

• Better UX with Chrome Custom Tabs (opens links in-app with smooth transitions)
• Graceful fallbacks (handle cases where browsers aren’t installed)
• Full control over how URLs are opened (analytics, deep links, etc.)

That’s exactly what we’ll implement.

Step-by-Step Implementation

1. Add the Browser Library

We’ll use Android Browser Library to implement Chrome Custom Tabs for a better link-opening experience.

Add this to your libs.versions.toml:

[versions]
browser = "1.8.0"

[libraries]
androidx-browser = { group = "androidx.browser", name = "browser", version.ref = "browser" }

Then add the dependency to your app’s build.gradle.kts:

dependencies {
    implementation(libs.androidx.browser)
}

Why Chrome Custom Tabs? Custom Tabs open web content inside your app with a smooth transition, pre-loaded browser engine, and shared cookies/sessions — all without leaving your app’s context.

2. Create a Custom URL Handler

This function handles opening URLs with three layers of fallback:

fun urlHandler(url: String, context: Context) {
    try {
        // First: Try Chrome Custom Tabs (best UX)
        val customTabsIntent = CustomTabsIntent.Builder().build()
        customTabsIntent.launchUrl(context, Uri.parse(url))
    } catch (e: ActivityNotFoundException) {
        try {
            // Second: Fallback to system browser
            val intent = Intent(Intent.ACTION_VIEW, Uri.parse(url))
            context.startActivity(intent)
        } catch (e: Exception) {
            // Third: Show toast if no browser exists
            Toast.makeText(
                context,
                "Browser not installed! visit: $url",
                Toast.LENGTH_LONG
            ).show()
        }
    } catch (e: Exception) {
        e.printStackTrace()
        Toast.makeText(
            context,
            "Unable to open link! visit: $url",
            Toast.LENGTH_SHORT
        ).show()
    }
}

How it works:

1. Chrome Custom Tabs (preferred): Opens in-app with native feel
2. System Browser (fallback): Opens in the default browser if Custom Tabs fail
3. Toast Message (last resort): Shows URL if no browser is available

This ensures your app never crashes when opening links, even on devices without browsers.

3. Building the Clickable Text Component

Now let’s create the actual composable with clickable links.

@OptIn(ExperimentalTextApi::class)
@Composable
internal fun TermsAndCondition() {
    val context = LocalContext.current

    // Define how links should behave when clicked
    val linkInteractionListener = LinkInteractionListener {
        urlHandler((it as LinkAnnotation.Url).url, context)
    }

    // Define link styling (color + underline)
    val linkStyle = TextLinkStyles(
        SpanStyle(
            color = DGreen,
            textDecoration = TextDecoration.Underline
        )
    )

    // Create Privacy Policy link annotation
    val privacyPolicy = LinkAnnotation.Url(
        url = URLS.PRIVACY,
        styles = linkStyle,
        linkInteractionListener = linkInteractionListener
    )

    // Create Terms of Service link annotation
    val toc = LinkAnnotation.Url(
        url = URLS.TOC,
        styles = linkStyle,
        linkInteractionListener = linkInteractionListener
    )

    // Helper functions for reusable link text (supports localization!)
    @Composable
    fun AnnotatedString.Builder.privacyLink() {
        withLink(privacyPolicy) {
            append(stringResource(id = R.string.privacy_policy))
        }
    }

    @Composable
    fun AnnotatedString.Builder.tocLink() {
        withLink(toc) {
            append(stringResource(id = R.string.terms_of_service))
        }
    }

    // Build the complete annotated string with mixed text + links
    val annotatedString = buildAnnotatedString {
        append("Read ")
        privacyLink()  // Clickable Privacy Policy
        append(" and tap on `")
        withStyle(style = SpanStyle(fontWeight = FontWeight.Bold)) {
            append("Agree and Continue")
        }
        append("` to accept the ")
        tocLink()  // Clickable Terms of Service
    }

    Text(
        text = annotatedString,
        style = PannaiTheme.typography.semiBold12.copy(
            color = LGray,
            textAlign = TextAlign.Center
        ),
        modifier = Modifier.fillMaxWidth(0.8f),
    )
}

Breaking Down the Code

LinkInteractionListener

val linkInteractionListener = LinkInteractionListener {
    urlHandler((it as LinkAnnotation.Url).url, context)
}

• This listener gets triggered when any link is clicked
• It extracts the URL from the LinkAnnotation.Url object
• Passes it to our custom urlHandler() for controlled opening

LinkAnnotation.Url

val privacyPolicy = LinkAnnotation.Url(
    url = URLS.PRIVACY,
    styles = linkStyle,
    linkInteractionListener = linkInteractionListener
)

• url: The actual link destination
• styles: How the link looks (color, underline, etc.)
• linkInteractionListener: What happens when clicked

This is the new Compose way of handling links (replaces older pushStringAnnotation approach).

Helper Functions for Localization

@Composable
fun AnnotatedString.Builder.privacyLink() {
    withLink(privacyPolicy) {
        append(stringResource(id = R.string.privacy_policy))
    }
}

Why helper functions? By using stringResource(), the link text automatically updates based on user’s language. This makes your code cleaner, reusable, and supports multi-language apps without duplicating logic.

Building the Final Text

val annotatedString = buildAnnotatedString {
    append("Read ")
    privacyLink()  // This part is clickable!
    append(" and tap on `")
    withStyle(style = SpanStyle(fontWeight = FontWeight.Bold)) {
        append("Agree and Continue")
    }
    append("` to accept the ")
    tocLink()  // This part is also clickable!
}

This combines regular text + clickable links + styled text in one component. withLink() wraps text and makes it interactive, while withStyle() applies visual formatting without making it clickable.

Key Takeaways

• LinkAnnotation API is the modern way to create clickable links in Compose
• Custom URL handler gives you full control over how links open
• Chrome Custom Tabs provides better UX than default browser
• Graceful fallbacks prevent app crashes on edge cases
• Helper functions + stringResource make your code localization-ready

Why This Approach is Better

Compared to older methods using pushStringAnnotation, this approach:

• Type-safe: LinkAnnotation is strongly typed
• Easier styling: Direct style application per link
• Better separation: Link logic separate from text building
• Localization-friendly: Works seamlessly with multi-language apps

Related Resources

• LinkAnitation Documentation
• Chrome Custom Tabs Guide

Thanks for reading! If you found this helpful, feel free to reach out via my social handles.

Let’s dive into what @RawQuery is, when it shines and shuns.

What is @RawQuery?

@RawQuery allows you to execute SQL statements that aren’t validated at compile time. Unlike @Query, which Room parses and validates during compilation, raw queries are evaluated at runtime.

You typically use @RawQuery with either SupportSQLiteQuery (for fully dynamic queries) or plain String (though the latter is limited and discouraged).

@Dao
interface ProductDao {

    @RawQuery 
    suspend fun getProductsWithRawQuery(query: SupportSQLiteQuery): List<Product>


    // This will be called from the repository
    @Transaction
    suspend fun getProductsAbovePrice(minPrice: Int): List<Product> {
    val query = SimpleSQLiteQuery(
        "SELECT * FROM products WHERE price > ?",
        arrayOf(minPrice)
    )
    return productDao.getProductsWithRawQuery(query)
    }
}

✅ When Should You Use @RawQuery?

Despite its risks, there are legitimate use cases for @RawQuery which come handy when the app is completely offline and need to do operations similar to server with available data for example sorting, filtering and searching etc.

There are some cases where you need advanced joins, unions, subqueries Room’s @Query might fall short an example i can think of are expense list screen where you need to get associated budgets,tags, users who created and approved them, etc getting this merged data specific filter and sort type will be extremely hard with conventional methods in cases like these @RawQuery are a boon.

This is one of my dao’s functions that is triggered when the there applies a filter, since there was no network i apply the filter and show the available data assuming the user already knows he is in offline mode,we have an indicator that should handle conveying of the message. So take a look and the params and tell me can we acheve this using conventional method faster than this ? i don’t think so but do share your views.

Lets check out my code for

 @RawQuery // Query runner
    suspend fun getExpensesWithParamsQueryRunner(query: SupportSQLiteQuery): List<LocalExpenseWithDetails>

 @Transaction // this will be called as a fallback option when offline
    suspend fun getExpensesWithParams(
        type: String?,
        budgetId: Long?,
        sessionId: Long?,
        filterParam: FilterParams,
        sortParam: SortParam,
        searchQuery: String?,
        page: Int
    ): List<LocalExpenseWithDetails> {
        val typeId = if (type != null && type != BaseExpenseType.ALL) getExpenseTypeWithName(type.serverKey) else null
        return getExpensesWithParamsQueryRunner(
            query = getExpenseQuery( // query generator
                typeId = typeId,
                budgetId = budgetId,
                sessionId = sessionId,
                filterParam = filterParam,
                sortParam = sortParam,
                search = searchQuery,
                page = page
            )
        )
    }

3. Performance Testing / Debugging During development, you might want to test different raw SQL statements quickly without baking them into DAOs.

⚠️ When NOT to Use @RawQuery

Just because you can doesn’t mean you should. Raw queries come with trade-offs:

• ❌ No Compile-Time Safety

Room won’t validate your SQL. Typos, wrong column names, or invalid SQL will only fail at runtime – often with vague errors.

• ❌ No Type Inference

Unlike @Query, Room won’t know what result type to expect unless you specify it manually and correctly.

• ❌ Risk of SQL Injection If you’re concatenating SQL strings, you open yourself to SQL injection vulnerabilities. Always use parameterized queries or filter the vulnerable queries.

// Bad ❌
val query = SimpleSQLiteQuery("SELECT * FROM products WHERE name = '$name'")

// Good ✅
val query = SimpleSQLiteQuery("SELECT * FROM products WHERE name = ?", arrayOf(name))

📋 Tips for Safely Using Raw Queries

• ✅ Always use SimpleSQLiteQuery with parameterized arguments.
• ✅ Keep the query logic isolated and well-documented.
• ✅ Prefer @Query whenever possible.
• ✅ Avoid user-generated input directly in SQL strings.
• ✅ Write tests to validate dynamic query paths.

🚫 Anti-Patterns to Avoid

• ❌ Using raw queries as your primary query method.
• ❌ Skipping query reuse – dynamic doesn’t mean you can’t structure it.
• ❌ Using @RawQuery when @Query or DAO methods would suffice.
• ❌ Ignoring test coverage for raw query logic.

I’ve even created my own query builder to simplify this process in my codebase. Whether you should use it or not depends on your needs, but I’m sharing it just so you know it exists because it was extremely useful for me. The code for my query builder can be found here: CustomQueryBuilder

🚀 Conclusion

@RawQuery is the escape hatch when Room’s abstraction becomes a cage. Use it when needed, but use it wisely. Think of it like the goto statement of Room – powerful but potentially dangerous if overused or misused.

In most offline-first app cases, well-structured DAOs using Room’s annotations will suffice. But in edge cases where flexibility is key, @RawQuery gives you that last-mile control.

Next up, we’ll explore Query Optimization Tips to keep your Offline-First App lightning fast, even at scale.

Next we will explore Data Access Objects, Stay tuned for the next article in this series! 🚀

Final Thoughts

Raw queries are sharp tools — excellent in skilled hands, but risky for the unprepared. If you’ve got a use case or edge case where @RawQuery saved your app or made something possible, I’d love to hear it!

Feel free to connect and share your stories: 📩 Email
🌍 Website
💫 LinkedIn-Post for comments and feedbacks

🔖 Previous Article in this Series 🚀 Stay tuned for Part 7! 🚀

What is a DAO?

A DAO is an interface annotated with @Dao that defines methods for interacting with the database. The Room compiler generates the necessary implementation for these interfaces and its methods, which enables us to access the database efficient and type safe.

A typical DAO will look simar as the code below:

@Dao
interface ProductDao {

 @Query("SELECT * FROM products")
 suspend fun getAllProducts(): List<Product>

 @Query("SELECT * FROM products WHERE id = :productId")
 suspend fun getProductById(productId: Long): Product?

 @Insert
 suspend fun insertProduct(product: Product)

 @Insert
 suspend fun insertProducts(products: List<Product>)
    
 @Update
 suspend fun updateProduct(product: Product)

 @Delete
 suspend fun deleteProduct(product: Product)

 @Upsert
 suspend fun upsertProduct(product: Product)
}

While the @Dao interface is created by the developer the instance/Implementation of the DAO’s are created by the compiler when the Database is created and the generated implementation file can be looked at the following path:

app/build/generated/source/kapt/debug/YOUR_PACKAGE_NAME/database/ProductDao_Impl.java

The file will contain the instance with impl as post fix and all the corresponding functions will have its own implementation accessing the SQLLite Database for example the select query annotated with @Query on the above DAO will generate an implementation code that is shared below, if you are to use SQLLite Directly this is the code you would have to write manually for each query:

The implementation of select query will look like this:

@Override
public Object getAllProducts(Continuation<? super List<Product>> continuation) {
    final String _sql = "SELECT * FROM products";
    final RoomSQLiteQuery _statement = RoomSQLiteQuery.acquire(_sql, 0);
    return CoroutinesRoom.execute(__db, false, continuation, new Callable<List<Product>>() {
 @Override
        public List<Product> call() throws Exception {
            Cursor _cursor = DBUtil.query(__db, _statement, false, null);
            try {
                List<Product> _result = new ArrayList<>();
                while (_cursor.moveToNext()) {
                    Product _item = new Product();
                    _item.id = _cursor.getLong(_cursor.getColumnIndexOrThrow("id"));
                    _item.name = _cursor.getString(_cursor.getColumnIndexOrThrow("name"));
                    _item.price = _cursor.getFloat(_cursor.getColumnIndexOrThrow("price"));
                    _result.add(_item);
 }
                return _result;
 } finally {
                _cursor.close();
                _statement.release();
 }
 }
 });
}

Isn’t it so nice how instead of writing 24 lines we just have to write 1

🙏 Thank You, Android and Google Team for making this extremely robust and performant.

Now that we got an intro on Dao and what happens behind the scenes, let’s go through the supported query annotations.

Supported Query Annotations

In the previous section of DAO example code, you might have noticed the annotations (@Insert,@Delete…) on each functions, these annotations help the compiler to generate query object on your behalf so we can smoothly interact with the database, Let’s go through each of them to understand how and when to use them effectively.

@Insert - Insert Data into the Database

Used for inserting single or multiple entries to a table, this will skip validation of checking if a duplicate entry with the same primary id exists, so it’s faster for insertion when you are clear that duplicate entries are impossible. In case you inset a duplicate entry the app will crash with the exception primary key already exists.

Here is an example of how the @Insert can be used:

...
 //Inserting single item
 @Insert(onConflict = OnConflictStrategy.REPLACE)
 suspend fun insertProduct(product: Product)     
 
 //Inserting multiple items
 @Insert
 suspend fun insertProducts(products: List<Product>)     
...

Conflict Strategy

Defining the conflict strategy on the query tells the room how to handle the conflict effectively by default it NONE:

• NONE: Default strategy when you insert duplicate it crashes the app.
• REPLACE: Keep the old data and ignore the new data.
• ABORT: Aborts the transaction entirely so none of the entries will be updated.
• IGNORE: Skip the entry and proceed to next

You can set your preference as per your requirement, but if you want the behavior of REPLACE hold on there is another annotation that we will learn about soon that is a better option.

⚠️ Beware: inserting duplicate entries will crash the app if you don’t provide a conflict strategy.

@Update - Modify Existing Data

Used for updating all columns of an existing row where the primary key matches, If the table does not contain a matching primary key, the update fails silently (no error or no exception) but the unmatched entries remain unchanged (they are not inserted or modified).

Like the @insert you can @update single or multiple entries, a sample code will look something like this:

...
 //Updating single item
 @Update
 suspend fun updateProduct(product: Product)   
 
 //Updating multiple items
 @Update
 suspend fun updateProducts(products: List<Product>)     
...

The update overrides the provided value to matched entries so if you accidentally provide a null value, that is exactly what the matched row’s column will be, for example, if you want to mark the product as sold-out you will think you have to send only a product object with id and the sold value but if you do that all other values like name, date, and other values will be set as null so ensure you provide all values.

⚠️ You are overriding all values, so ensure you provide all values in each entry.
⚠️ Unmatched rows will not be inserted, no errors or exceptions will be thrown

@Upsert - Insert or Update in One Call

@Upsert is a combination of @Insert and @Update, if the entry matches the primary-key it updates them, otherwise it inserts them smoothly, you could use @Insert with REPLACE if your table has no primary key otherwise this is better.

This is an example of how the ``@Upsert` will be used in a dao

// upsert single item
@Upsert
suspend fun upsertProduct(product: Product)

// upsert bulk Item
@Upsert
suspend fun upsertProducts(products: List<Product>)

One thing to note is that the conflict is handled only for the primary key, if your table has other columns that are set as unique the upsert may still fail if that rule is ever broken due to new data.

⚠️ Requires the primary key
⚠️ If your table has unique constraints on other columns, @Upsert may still fail.

@Delete - Remove Entries from the Database

Enables you to delete single and multiple entities blissfully, if the row does not exist it fails silently which means that the entries that exist will be deleted and the other will not since it does not exist, here is how typical delete functions will look like:

// delete single item
@Delete
suspend fun deleteProduct(product: Product)

// delete bulk Item
@Delete
suspend fun deleteProducts(products: List<Product>)

I don’t like to pass the entire entity for deletions so I prefer to use @Query for it so I can just pass the primary keys for deletion, but for simplicity, you can use the @Delete as well.

@Query - The Most Powerful Annotation

The @Query Swiss knife allows you to write custom SQL queries to interact with your database. It provides more flexibility than other annotations (@Insert, @Update, @Delete) and is essential for performing simple/complex operations depending on our use cases.

...
// bulk get
@Query("SELECT * FROM products")
suspend fun getAllProducts(): List<Product>

// single get 
@Query("SELECT * FROM products WHERE id = :productId")
suspend fun getProductById(productId: Long): Product?

// search Query
@Query("SELECT * FROM products WHERE name LIKE '%' || :searchQuery || '%'")
suspend fun searchProducts(searchQuery: String): List<Product>

// deleting item with ID
@Query("DELETE FROM products WHERE id = :productId")
suspend fun deleteProductById(productId: Long)

// delete multiple items
@Query("DELETE FROM products WHERE id IN (:productIds)")
suspend fun deleteProductById(productIds: List<Long>)

// deleting all entries (truncates)
@Query("DELETE FROM products")
suspend fun deleteAllProducts()
...

Swiss Knife it is, you can do all kinds of operations with it, its gives us more flexibility but as we know “With Great Power comes to Great Responsibility”. Although @Query is powerful, it can fail in various ways due to syntax errors, missing data, type mismatches, database constraints, etc.. so use it cautiously and expect exceptions and app crashes.

@RawQuery - Fully Dynamic SQL Execution

The @RawQuery annotation in Room allows you to write and execute fully dynamic SQL queries, will will explore this later in this series it breaks the simplicity boundary because there is no compile-time safety on this.

🚀 Conclusion

Data Access Objects (DAOs) are the backbone of efficient database operations in Room. They provide a clean, structured way to interact with your database while leveraging compile-time safety and reducing boilerplate SQL code. With annotations like @Insert, @Update, @Delete, @Upsert, and @Query, DAOs make it easier to perform CRUD operations while maintaining performance and maintainability.

By using DAOs, you ensure that your Offline-First App has a seamless data layer, enabling a smooth and efficient user experience.

Next, we will discuss about @RawQuery and its pro’s and cons…

Final Thoughts

This is my journey in building an offline-first app. I’d love to hear your feedback, suggestions, or questions!

Feel free to connect with me on:
📩 Email
🌍 Website
💫 LinkedIn-Post for comments and feedbacks

🔖 Previous Article in this Series 🚀 Stay tuned for Part 6! 🚀

🔖 Next Article in this Series

Entities are the foundation of Room—they define how your data is stored in the database. Properly structuring your entity ensures efficient querying, maintainability, and scalability. Let’s break it down! 🛠️

🏗️ What is an Entity?

An Entity in Room represents a table in the database. Each instance of the entity corresponds to a row in the table, Room generates corresponding SQL table schema based on how you create an entity class.

Defining an Entity:

@Entity
data class LocalHabitTracker(
    @PrimaryKey(autoGenerate = true) val id: Long,
    val associatedHabitId: Long,
    val positionX: Int,
    val positionY: Int,
    val note: String
)

Breaking It Down:

• @Entity tells Room that this class is a database table.
• @PrimaryKey is used to uniquely identify each row.
• autoGenerate = true ensures Room generates unique IDs automatically.
• @Ignore → Excludes a field from being stored in the database.

Before we procced further, Lets check out the sql query generated by the room

CREATE TABLE LocalHabitTracker (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    associatedHabitId INTEGER NOT NULL,
    positionX INTEGER NOT NULL,
    positionY INTEGER NOT NULL,
    note TEXT NOT NULL
);

Since its a simple entity it might look workable but think of adding indexes, relations and other complicated relations it can quickly get complicated and prone errors. That being said this is just to show you how room is doing most of the heavy lifting for you, lets move on to customizing our entities.

🔄 Customizing Entities

Room provides several ways to customize entities to fit your data structure requirements. Let’s explore these!

1️⃣ Custom Table and Column Names

By default, Room uses the class name as the table name and variable names as column names. You can override this using annotations:

@Entity(tableName = "habit_tracker")
data class LocalHabitTracker(
    @PrimaryKey(autoGenerate = true) val id: Long,
    @ColumnInfo(name = "habit_id") val associatedHabitId: Long,
    @ColumnInfo(name = "pos_x") val positionX: Int,
    @ColumnInfo(name = "pos_y") val positionY: Int,
    val note: String
)

• tableName changes the SQL table name while keeping the DataClass name as per your requiremnt.
• @ColumnInfo(name = “custom_name”) changes the column name in the table.

⚠️ These customizations are for the DataBase Tables which means when writing the query you must use the customized name for the query to work properly.

This is extremely useful when you want to Name your tables and columns differently, in kotlin we use camelcase but on sql its common to use underscore to split worlds like habit_tracker instead of LocalHabitTracker it simplifies the query and expedites debugging process.

Using custom name for table and column is optional so if you are comfortable with the existing name you can use just that, next up lets see how can we ensure the entities can be indexed faster.

2️⃣ Indexing for Faster Queries

Indexes speed up query performance, especially for large datasets. Use @Index for frequently queried columns, for example here the associated_habit_id will be used most frequently by me in different queries so i am adding indices property on the @Table annotation, here is an example:

@Entity(
    tableName = "habit_tracker",
    indices = [Index(value = ["associated_habit_id"])]
)
data class LocalHabitTracker(
    @PrimaryKey(autoGenerate = true) val id: Long,
    @ColumnInfo(name = "associated_habit_id")val associatedHabitId: Long,
    val positionX: Int,
    val positionY: Int,
    val note: String
)

• Indexing habit_id speeds up lookup queries on this column.

When Should You Use an Index?

✅ Use indexing if:

• The column is used frequently in WHERE, JOIN, or ORDER BY.
• The column is a foreign key linking to another table.

🚫 Avoid indexing if:

• The table is small (indexing overhead isn’t worth it).
• The column has many unique values (like id, which is already indexed as PRIMARY KEY).

What actually happens?

When you add an index to a column in Room, Room creates a separate data structure called a B-tree index. This makes queries that search for specific values in the indexed column much faster.

If you want to know more about B-tree Index: check this out B-Tree Index

Now we have learned about indexing lets checkout how to ensure the columns stays unique

3️⃣ Unique Constraints

Preventing duplicate values on an indexed column is sometimes necessary and we can achieve that by setting the property unique = true if the Index class, lets checkout an example to see how to apply this:

@Entity(
    tableName = "habit_tracker",
    indices = [
        Index(value = ["entry_data"], unique = true),
        Index(value = ["associated_habit_id"])
    ]
)
data class LocalHabitTracker(
    @PrimaryKey(autoGenerate = true) val id: Long,
    @ColumnInfo(name = "associated_habit_id")val associatedHabitId: Long,  
    val positionX: Int,
    val positionY: Int,
    val note: String,
    @ColumnInfo(name = "entry_data")val entryDate: String
)

• Ensures habit_id remains unique across all rows.

The unique = true ensures there is no duplicate value in that particular indexed row, this can be extremely helpful in some cases in our case we are building a habit tracking app where users log their habits daily. We want to ensure that a user cannot log the same habit more than once per day so this property help us to achieve that blissfully.

Lets move on to Keys and Relationships,i meant between the Entities 😜

4️⃣ Foreign Keys for Relationships (@ForeignKey)

Define relationships between tables using @ForeignKey.

@Entity(
    tableName = "habit_tracker",
    foreignKeys = [
        ForeignKey(
            entity = Habit::class,
            parentColumns = ["id"],
            childColumns = ["habit_id"],
            onDelete = ForeignKey.CASCADE
        )
    ]
)
data class LocalHabitTracker(
    @PrimaryKey(autoGenerate = true) val id: Long,
    val habit_id: Long,
    val positionX: Int,
    val positionY: Int,
    val note: String
)

🔷 habit_id references id from the Habit table. 🔷 onDelete = CASCADE ensures that deleting a Habit deletes all related LocalHabitTracker records.

The @ForeignKey is a primary key of an associated entity in the context of current entity the associated entity is referred as parent entity, using @ForeignKey help us to create relations and trigger changes depending on the event triggered, most commonly used trigger event is onDelete the other one is onUpdate the actions supported are as follows:

Supported Actions:

This table should have given you a clear picture of what each action’s behavior and next lets checkout how to select them and when to use them effectively:

When to Use Each Action

You can add any number of foreign keys so make use of it for simplifying and automate your preferred action when the parent entity is modified.

5️⃣ Embedded Objects (@Embedded)

Instead of creating separate tables, you can embed objects inside an entity, this does not mean that the table will hold your embedded object as is, it basically flattens the properties into the Entity, first lets see how to use @Embedded:

data class Position(
    val x: Int,
    val y: Int
)

@Entity
data class LocalHabitTracker(
    @PrimaryKey(autoGenerate = true) val id: Long,
    val associatedHabitId: Long,
    @Embedded val position: Position,
    val note: String
)

• The Position object is embedded as separate columns (x, y) in LocalHabitTracker,

This helps with structuring data efficiently without creating a separate table for nested objects, It is primarily used to flatten objects into separate columns within the same table this helps us to avoid using TypeConverters, extra Table, faster queries as we don’t have to deal with JOINS and other complications.

When to Use @Embedded:

1. You have small nested objects (e.g., Position, Address, Metadata).
2. You don’t need a separate table for the object.
3. You want to avoid TypeConverters for simple objects.
4. The embedded object is always used with the parent (it has no independent existence).

When to Avoid it:

1. The embedded object is large or frequently updated → Use a separate table.
2. The object has relationships with other entities → Use @Relation instead.
3. The object needs to be referenced from multiple entities → Use Foreign Keys.

I hope this made sense, simply put the @Embedded is only a output structure, while creating the SQL query room will flatten the properties into the entity table, Now if you want to store complex objects like lets say List event that is possible, lets see how to achieve it.

6️⃣ Storing Objects as is (TypeConverters)

Room only supports primitive data types (Int, Long, String, Boolean, etc.) by default. If you want to store complex data types (e.g., List, Date, Enum), you need Type Converters to convert them into a format Room understands ie String, lets look at an example of @TypeConverter:

import androidx.room.TypeConverter
import com.google.gson.Gson
import com.google.gson.reflect.TypeToken
import java.util.Date

class Converters {

    // Convert Date -> Long (for storage)
    @TypeConverter
    fun fromDate(date: Date?): Long? {
        return date?.time
    }

    // Convert Long -> Date (for retrieval)
    @TypeConverter
    fun toDate(timestamp: Long?): Date? {
        return timestamp?.let { Date(it) }
    }

    // Convert List<String> -> JSON String (for storage)
    @TypeConverter
    fun fromStringList(list: List<String>?): String {
        return Gson().toJson(list)
    }

    // Convert JSON String -> List<String> (for retrieval)
    @TypeConverter
    fun toStringList(json: String?): List<String> {
        return Gson().fromJson(json, object : TypeToken<List<String>>() {}.type)
    }
}

Once a converter is defined it must be added to the DataBase class,here is an example:

@Database(entities = [User::class], version = 1)
@TypeConverters(Converters::class)  // Register converters
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

now you can add it to the entity by annotating it with the the @TypeConverter, here is an example for it:

@Entity(tableName = "users")
data class User(
    @PrimaryKey(autoGenerate = true) val id: Int,
    val name: String,

    @TypeConverters(Converters::class) // Apply TypeConverter here
    val hobbies: List<String>
)

The best use-case for this is when you want to store Enums, Dates and List of items, do note the values in the object will be stored but cannot be queried which means you can’t search, sort or filter the values so ensure you use them only when absolutely need to like for Storing simple objects (e.g., Address, Date, Enum)

These cover the most important aspects of the @Entity and its properties and how to use them effectively, if you think i have missed any please feel free to add comment and ill definitely add them here so it can be helpful for me and others, before you go lets check the best practices.

🔍 Best Practices

✅ Use autoGenerate = true for @PrimaryKey to avoid conflicts if you don’t have a server that provides it.
✅ Optimize query performance with @Index.
✅ Define @ForeignKey relationships to maintain integrity but optional for complex cases.
✅ Use @Ignore for transient fields that shouldn’t be stored in the database.
✅ Keep entity classes small and focused—avoid unnecessary logic inside them.
✅ Ensure Proper Indexing: Index frequently queried columns to improve performance.
✅ Use Primitive Types: Room doesn’t support custom objects directly. Use @TypeConverter if needed.

🚀 Conclusion

Room Entities form the foundation of Android’s database layer, allowing structured and efficient data management. By following best practices, you ensure scalable and maintainable database architectures.

Next we will explore Data Access Objects, Stay tuned for the next article in this series! 🚀

Final Thoughts

This is my journey in building an offline-first app. I’d love to hear your feedback, suggestions, or questions!

Feel free to connect with me on:
📩 Email
🌍 Website
💫 LinkedIn-Post for comments and feedbacks

🔖 Previous Article in this Series 🚀 Stay tuned for Part 5! 🚀

🔖 Next Article in this Series

On the previous article we have set-up the Room dependencies and plugins, Now lets get into the primary key components of a room library.

There are three important components: Entity, DAO’s, and Database.

• Entity represents a single row of a table. (Table structure)
• DAO’s (Data Access Objects) are interfaces to write queries and define operations.
• Database is where you associate entities and include the DAO’s you’d like to access from outside.

Let’s check it out one by one! 🔍

🏗️ Entities: Defining Your Data Structure

Any class annotated with @Entity is called a entity, it represents a table in a database, while designing the entity ensure you follow Normalizations Rules to keep it simple and future proof. Let’s look checkout a sample entity in a Habit Tracker app.

Example:

@Entity
data class LocalHabitTracker(
    @PrimaryKey(autoGenerate = true) val id: Long,
    val associatedHabitId: Long,
    val positionX: Int,
    val positionY: Int,
    val note: String
)

Key Points:

✅ An entity must have at least one parameter annotated with @PrimaryKey.
✅ The primary key must be unique the primaryKey column can’t have a duplicate key.
✅ If you want Room to auto-generate the primary key, set autoGenerate = true otherwise to false.
✅ Stick to primitive types like Long or Int as PrimaryKey.

The entity can be further customized with table names, indexing, custom column names, keys and more, which we’ll cover in next article. 🎯

🔗 DAOs: Your Data Gateway

DAOs or Data Access Objects serve as the interface between your app and the database, providing an abstraction layer. This is a bridge between you the developer and the Database all your interactions you intend to have table must be defined here later at compile time the compiler will generate the concrete classes for these at compile time, lets see an example how to define these interactions.

✍️ Example:

@Dao
interface HabitTrackerDao {

    // Query to get all habit trackers
    @Query("SELECT * FROM LocalHabitTracker")
    suspend fun getAll(): List<LocalHabitTracker>

    // Query to get a habit tracker by ID
    @Query("SELECT * FROM LocalHabitTracker WHERE id = :id")
    suspend fun getById(id: Long): LocalHabitTracker

    // Insert a new row into the table (fails if duplicate)
    @Insert
    suspend fun insert(habitTracker: LocalHabitTracker)

    // Update an existing row
    @Update
    suspend fun update(habitTracker: LocalHabitTracker)

    // Upsert: If exists, update; otherwise, insert
    @Upsert
    suspend fun upsert(habitTracker: LocalHabitTracker)

    // Delete a row from the table
    @Delete
    suspend fun delete(habitTracker: LocalHabitTracker)
}

Best Practices:

✅ One entity per DAO: It’s best to separate interaction with each table into its own DAO for maintainability.
✅ Keep queries optimized to avoid performance issues as your app scales.
✅ Inheritance if some of the interactions are common to other Dao’s create a new Dao with Common as prefix for exampleCommonHabitTrackerDao.

We’ll cover complex cases like @RawQuery, Junctions, and TableViews in later articles as to not over-complicate this! 🔮

🏛️ Database: The Central Hub

Now that we have defined the entities and DAOs, we need to create a database to integrate thee entity and Dao’s into its domain. Now the room can effectively generate its contents when instantiated along with this the database also manages the integrity validation, migrations and works as a central hub of control for our interactions with this database and its entities.

Here is an example of a database class:

@Database(
    entities = [LocalHabitTracker::class], // Add all your entities here
    version = 1 // Update this when modifying the schema
)
abstract class HabitTrackerDataBase : RoomDatabase() {

    // Room will auto-implement this function and return the DAO implementation
    abstract fun habitTrackerDao(): HabitTrackerDao

}

Important Notes:

✅ Always increase the version when modifying entities, it enables room to validate the integrity of tables and run migrations effectively.
✅ Room doesn’t know how to handle schema changes unless you define a migration strategy.
✅ Multiple databases can exist in an app, so this class serves as an entry point of the particular database.

Migrations and schema updates are crucial for real-world apps to prevent data loss. We’ll cover on later articles. 🔄

🎛️ Manually Creating and Using the Database

Now, let’s see how to manually create and interact with the database in our app.

✍️ Example:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // Creating the database manually
        val habitTrackerDB = Room.databaseBuilder(
            context = this, // ApplicationContext
            klass = HabitTrackerDataBase::class.java, // Database abstract class
            name = "habbit_tracker" // Custom database name
        ).build() 
        
        // Get the DAO implementation
        val habitTrackerDao = habitTrackerDB.habitTrackerDao()

        setContent {
            AppTheme {
                AppNav(activity = this, habitLocalService = habitTrackerDao)
            }
        }
    }
}

⚡ Pro Tips:

✅ Don’t use the UI thread for database operations; always use coroutines or background threads.
✅ In real-world apps, use Dependency Injection (DI) for managing database instances efficiently.
✅ Avoid creating multiple database instances, as it can lead to memory leaks and performance issues.

Mostly this is enough for creating simple CRUD apps, though it looks simple the entities will be converted into a query to create tables, A concrete classes will be created for each Dao’s and other essential tasks will be carried by room it self easing our development and debug process.

🚀 What’s Next?

This was a quick run through of some of the key components of room, on the next article we will dive a little deeper into @Entity its keys and customizations,as we have a larger purpose to explore them each in detail.

Final Thoughts

This is my journey in building an offline-first app. I’d love to hear your feedback, suggestions, or questions!

Feel free to connect with me on:
📩 Email
🌍 Website 💫 LinkedIn-Post for comments and feedbacks

🔖 Previous Article in this Series

🔖 Next Article in this Series

✅ Compile-time SQL Validation – Catches errors early by verifying SQL queries at compile time.
✅ Kotlin-first Approach – Supports coroutines, Flow, and LiveData natively.
✅ Less Boilerplate Code – Simplifies database interactions while maintaining SQLite’s power.
✅ Seamless Migration Handling – Built-in support for database migrations.

For a more detailed explanation, refer to the official Android documentation.

Official Documentation

Google keeps its documentation up to date with a simple setup guide. However, you might wonder why we need this article if the documentation is available.

Google’s documentation caters to both Java and Kotlin developers, but since most of us have migrated to Kotlin, we don’t need Java-specific instructions. This article focuses on a Kotlin-first approach to setting up Room.

📖 Official Guide on Setting up Room Dependencies and Plugins.

Setting up Dependencies

1️⃣ Configure Project-Level build.gradle.kts

Ensure your project-level build.gradle.kts file includes Google’s Maven repository and Maven Central, as these are where Room dependencies are hosted.

buildscript {
    repositories {
        google()
        mavenCentral()
    }
}

2️⃣ Add Room Dependencies

Head to your module-level build.gradle.kts file and add only the required Room dependencies inside the dependencies block:

dependencies {
    // Other dependencies 

    // Room Dependencies
    val room_version = "2.6.1"

    // Room Database Core
    implementation("androidx.room:room-runtime:$room_version")

    // Annotation Processor (KSP)
    ksp("androidx.room:room-compiler:$room_version")

    // Kotlin Extensions and Coroutines support for Room (Optional)
    implementation("androidx.room:room-ktx:$room_version")

}

🔎 Check for Latest Versions Always use the latest stable version of Room and KSP:

📌 Maven Central - Room Runtime 📌 kotlin-ksp-releases

3️⃣ Add the Room Plugin

Project-Level build.gradle.kts Add the Room plugin reference to the project-level build.gradle.kts file:

plugins {
    id("androidx.room") version "$room_version" apply false 
    id("com.google.devtools.ksp") version "2.0.21-1.0.27" apply false 
    // Other plugins...
}

Module-Level build.gradle.kts Add this to the module-level build.gradle file:

plugins {
    id("androidx.room")
    id("com.google.devtools.ksp")
}

4️⃣ Configure Schema Directory

Room allows schema export for better version control and database migrations. Let’s specify a schema directory inside the android {} block:

android {
    ...
    room {
        schemaDirectory("$projectDir/schemas")
    }
}

Sync & Verify Installation

Once you’ve added the dependencies and plugin, sync your Gradle project. If everything is set up correctly, you should have Room ready for use in our project! 🎉

./gradlew build 

Sample Code for a quick reference

I hope you had no issues setting up the dependencies, if you need a sample app to compare the change-set feel free to checkout this commit.

What’s Next?

This short article we have learned how to set-up the room dependencies to our projects and hopefully this was helpful: 📌 In the next part of this series, we’ll dive into:

1️⃣ Key Components of Room

• @Entity: Defines how data is stored in the table.
• @Dao: Specifies how to interact with the table (CRUD operations).
• @Database: Configures the database and associates Entities and DAOs.

2️⃣ How to create, access and interact with a simple database.

Final Thoughts

This is my journey in building an offline-first app. I’d love to hear your feedback, suggestions, or questions!

Feel free to connect with me on:
📩 Email
🌍 Website
💫 LinkedIn-Post for comments and feedbacks

🔖 Previous Article in this Series

🔖 Next Article in this Series

Making your app offline-first is essential if you want to provide the best user experience. It makes your app significantly faster by reducing the number of network calls, which in turn also reduces server costs.

What does Offline-First mean?

The core idea is to persist/store remote-fetched data on the device. This allows users to access the data instantly, skipping unnecessary network requests—until the data expires or is invalidated.

If your app has this feature then your app is offline-first if it does not then lets make it one.

While offline-first apps come with some complexities, the benefits far outweigh the challenges. but before we start a small disclaimer.

A Quick Disclaimer

There are multiple ways to approach offline-first implementation. What I discuss here is my approach, tailored to my requirements. There might be better methods for different scenarios so take these as suggestions and not rules.

If you have suggestions, feedback, or alternative approaches, I’d love to discuss them! Let’s learn and refine this together. As I explore further, I will actively update these articles with new insights/approaches/strategies.

Now, let’s get started. 🚀

Offline Strategies: Partial vs. Full Offline Mode

There are two main strategies for implementing offline-first functionality:

1. Fully Offline Mode
2. Partial Offline Mode

The main difference between them is whether the user can modify their data offline.

1️⃣ Fully Offline Mode (CRUD Operations Offline)

In this approach, users can:
✅ Create, Read, Update, and Delete (CRUD) without an internet connection.
✅ Sync data to the cloud when online.

🔴 Major Challenge:

• If a user forgets to sync data from one device (e.g., a tablet) and later accesses their account from another device (e.g., a phone), they might think the data is lost.
• This can frustrate users, leading to complaints or abandoning our app.

🔵 Idea Use case:

Best option for apps that does not support multi user and has single device login, but ⚠️ The data loss % is still significantly high if user forgets to connect online after the initial login and loses his device etc, but thats a tradeoff you have to live with.

While this approach offers true offline functionality, it introduces complex synchronization issues, making it harder to maintain data consistency across devices.

2️⃣ Partial Offline Mode (Read-Only When Offline)

In this approach, users can:
✅ View/Read data offline.
❌ Modify data (Create, Update, Delete) only when online.

🔹 Why We Chose This Approach:

• Multi-device users won’t face sync issues since data is always available in cloud.
• Less complexity & better error handling & almost no possibility of data loss.
• Data remains clean and consistent with the server.

🔵 Idea Use case:

Best option for most use-cases simple or complex or extremely complex data set apps, with or without multi-user or multiple-device-logins and what not.

This is most preferred due to its data-consistency point and much simpler to implement, Now checkout the next one.

3️⃣ Hybrid Offline Mode (Partially-restricted Write operations)

The Hybrid mode is using both discussed strategies depending on the use cases, for example you may allow the user to update their profile details or personal notes etc but not the public contents that can cause issue with other uses on the same org/team.

✅ View/Read data offline.
✅ Modify some data even if offline.
❌ Modify most data only if online.

🔵 Idea Use case:

Best option for most simple or complex apps, with or without multi-user but strictly allow only single-device-login, this enables the user to do write-operations to user specific data while restricting the same for other parts of the app, there are tradeoffs here as well but only a particular user will be affected in the org/team.

For me the partial offline mode stands out as best option and would suggest the same for most use-cases, we will be sticking with this through out this journey.

Now, let’s dive into how we fetch and synchronize data.

Data Synchronization Strategies

Once we are decided on partial offline mode, the next question is:
👉 How do we fetch data from the server and keep it updated?

There are two main synchronization approaches:

1️⃣ On-Demand (Pull-Based Synchronization)

• Data is fetched only when the user requests it.
• Data is invalidated when it expires or is manually deleted.
• Lightweight & user-centric—fetches only relevant data.

2️⃣ Clone (Push-Based Synchronization)

• The local database mirrors the entire remote database.
• Auto-updates when the server sends a flag indicating it was modified.
• Heavy & resource-intensive, as it may download unnecessary data.

🔹 Which One Did We Pick?
We chose On-Demand Synchronization since it’s:
✅ Efficient (fetches only what’s needed).
✅ Faster & lightweight (minimizes unnecessary data transfers).

However, we use mox of both lets call it a hybrid approach, we loaded some data that user will need on the navigating screen to ensure a better user experience. After that, everything is strictly on-demand the data is synced only based on user.

Which Local Database Library Should You Choose?

There are several local database solutions available, but we chose Google’s Room Persistence Library. Here’s why:

✅ Built on SQLite – but with a modern, developer-friendly API.
✅ Works seamlessly with Kotlin (supports data classes).
✅ Compile-time SQL query verification (reduces errors).
✅ Built-in support for LiveData, Flow, and Paging.
✅ Faster development (less boilerplate, easy migrations).

Using Room significantly accelerates development while maintaining a structured and reliable database. It’s my go-to solution, and I highly recommend it for Android and Kotlin Multiplatform (KMP) projects.

What’s Next?

This article laid the foundation for an offline-first architecture and explained why we chose partial offline mode & on-demand synchronization.

📌 In the next part of this series, we’ll dive into:

• Setting up Room in an Android.
• Exploring Key Components of Room.

Final Thoughts

This is my journey in building an offline-first app. I’d love to hear your feedback, suggestions, or questions!

Feel free to connect with me on:
📩 Email
🌍 Website
💫 LinkedIn-Post for comments and feedbacks

🔖 Next Article in this Series