Forem: boryanz

I Let AI Agents Build My Android Feature. Zero Working App

boryanz — Mon, 19 Jan 2026 21:33:49 +0000

Seeing all the hype about agentic coding sparked my interest to give "Vibe Coding" a shot. I set a single rule for myself: don't touch the code by hand. Do it only with Claude Code straight from my terminal using the Claude Sonnet model.

The Task

Implement EDIT functionality in a very simple CRUD (single module) Android app.

On the home screen, the app fetches all food orders the user made.
User can see all items listed and click the edit button to enter the CreateOrder screen, which will be populated with existing data so it can be modified and updated.
The screen must be reused and the ViewModel should differentiate whether to POST or PUT.

The approach for this is very simple. Pass id to the details screen, fetch data by id and populate the screen. When the user edits the content, make a PUT API call instead of POST.

The Setup

I'm using the Anthropic Pro plan which gives me around 44k tokens until I hit the 5 hour limit. I added 5 agents in .claude/agents:

Agent	Role
`android-architect-agent.md`	Understands the feature, makes decisions and explains trade offs to the senior android engineer agent, which takes over next.
`senior-android-engineer-agent.md`	Handles the implementation of the code while caring about clean architecture, code maintainability and unidirectional data flow.
`refactoring-agent.md`	Applies the boy scout rule after the senior agent implements the flow, caring about code readability, maintainability etc.
`test-engineer-android-agent.md`	Writes unit tests for ViewModels and domain logic.
`meta-orchestrator-agent.md`	Plays the role of Engineering Manager who orchestrates all the agents mentioned above.

I polished the agents as much as I could with clear instructions about roles, hard rules and responsibilities. I like how Claude Code guides the creation of agents inside the terminal. It's easy to set which tools and permissions each agent can use. It really feels like assembling a whole engineering team.

The Prompt

I gave full responsibility to the agents to approach the problem however they wanted. The prompt I used was:

I want to extend CreateOrderViewModel to support editing of the order. At the moment only an order can be created, but the user can navigate to this screen by clicking the edit button on an existing order.

User should be able to click the edit button on the order item and land in the create order screen.

Screen must be populated with the data from the existing order.

To get the order, use new API call (GET /api/v1/orders/{id})

If user edits the order, then new backend call should happen. (PUT) instead of POST.

Edge cases must be handled.

Apply boy scout rule along the way to refactor bad code.

ViewModel must be fully tested.

At this point, after setting all of this up, I got really hyped about what Claude Code would cook.

I prepared coffee and fired the main meta-orchestrator-agent.md with the prompt and the show was on...

The Results

After about 22 minutes of cooking, here's what Claude produced:

The Good

orderId was passed via constructor parameter in the VM
ViewModel test coverage was around 90%
It handled the process death scenario with SavedStateHandle in the ViewModel (this was not mentioned in the prompt)
It wired the existing Type Safe Navigation 2 by adding orderId as a parameter to the serialized data class destination
Connected the UI state with the UI without any issues
Easily wired existing Koin DI

The Bad

ViewModel exceeded 300 lines of total logic. Extra classes weren't extracted.
Scattered try-catch blocks everywhere, with a lot of early returns like null checks or parameter validations
Init block with heavy api operations.

The code looked a bit messy based on my preference. Error handling could be hidden somewhere else or at least use some DSL style handling. Also, the ViewModel was screaming for extraction.

I also noticed this piece of code which didn't make a lot of sense. It updates state twice in the same onSuccess block.

Example of one function in the VM which looks bloated.

The Debugging

First Run

First run crashed! Claude forgot to add the @Serializable annotation on the navigation. I prompted the error message and it started fixing.

Second Run

The Edit button wasn't doing anything. I prompted the issue again. It cooked for a bit and found out it was using tryEmit on the SharedFlow without buffer capacity, so the collector missed the emission. The fix was to add replay of 1 to the SharedFlow, which actually behaves exactly like StateFlow.

Third Run

It didn't happen. I hit the 5 hour limit with all 44k tokens used. Which means I need to manually refactor and make the app work, or wait 5 hours, or pay 100 bucks for more tokens monthly.

Conclusion

I'm still not convinced about agentic coding, especially for Android apps with complex modular architecture. For this whole task I would need 40 to 60 minutes including the test cases.

Some people are too religious about it. But maybe I haven't configured the agents correctly, or should use Opus instead of Sonnet? Or maybe it needs a smaller context first, then expand more to create a snowball effect?

I leave those questions open. There are good discussions about these topics, and I'm sure there are more experienced AI people who have different experiences than mine.

Feel free to send me a DM if you have more experience and want to discuss this.

The Hidden Performance Trap in Your Jetpack Compose Modifiers

boryanz — Thu, 28 Aug 2025 13:57:08 +0000

You've mastered Compose basics. You chain modifiers like a pro: padding here, background there, maybe a click handler at the end. It feels natural, almost meditative. But, identical UIs can perform drastically differently based solely on how you order and structure your modifiers.

Think of it like cooking. You can make the same dish using different techniques, one way leaves you with smooth workflow and minimal cleanup, another creates unnecessary mess and takes twice as long. Same end result, completely different efficiency.

The Innocent Mistake

Consider this everyday chat interface element:

// Looks perfectly reasonable, right?
Box(
    modifier = Modifier.padding(16.dp) // First modifier
) {
    Column(
        modifier = Modifier.padding(16.dp) //redundant!
    ) {
        Text(
            "Breaking News",
            modifier = Modifier.padding(bottom = 8.dp)
        )
        Text(
            "Latest updates from tech world...",
            modifier = Modifier.padding(top = 8.dp) 
        )
    }
}

This renders perfectly. Users see exactly what you intended. But under the hood, Compose is working overtime like a factory with four separate assembly stations all doing spacing work when one would suffice.

What's Really Happening

Each padding() modifier creates its own layout node. Imagine you're painting a room and instead of measuring once and painting efficiently, you keep stopping to remeasure the same walls. That's what's happening here. Compose measures and positions elements multiple times for what should be a single spacing operation.

The performance impact isn't theoretical. In a scrolling list, this inefficiency multiplies. Every new item that slides into view triggers these redundant layout passes. On devices already struggling to maintain that crucial 16.67ms frame budget for smooth 60fps scrolling, these extra calculations become the difference between butter-smooth scrolling and janky, dropped frames.

The Streamlined Solution

// Optimized: single source of truth for spacing
Card {
    Column(
        modifier = Modifier.padding(32.dp), // One padding operation
        verticalArrangement = Arrangement.spacedBy(8.dp) // Built-in spacing
    ) {
        Text("Breaking News")
        Text("Latest updates from tech world...")
    }
}

This achieves identical visual results but consolidates all spacing logic into one place. Think of it as the difference between a professional kitchen where each chef has their station optimized, versus a chaotic setup where everyone keeps bumping into each other doing the same tasks.

The Cascading Benefits

Here's where optimization becomes powerful: fix it at the item level, and the benefits ripple through your entire list. That single chat bubble optimization might save a few milliseconds, but multiply that across dozens of items scrolling past per second, and you've transformed a stuttering user experience into something that feels premium and responsive.

The beauty is that this principle extends beyond just padding. Any modifier that manipulates layout or appearance can benefit from thoughtful consolidation. Group related visual modifications together, minimize redundant operations, and always consider the order of your modifier chain.

The Takeaway

Your modifier chains are like recipe instructions. You can throw ingredients together in any order and sometimes get lucky, or you can follow a logical sequence that consistently produces the best results with minimal waste.

The golden rule: Treat spacing and visual modifications as centralized concerns rather than scattered, individual decisions. Your future self debugging performance issues will thank you, and your users will feel the difference in every smooth scroll.

Next time you're chaining modifiers, pause for a moment. Ask yourself: "Am I creating unnecessary work here?" Often, the most elegant code isn't just more readable - it's measurably faster too.

Rule of Thumb for chaining:
Layout → Appearance → Interactions

Thanks a lot for reading this article!

If you're interested in digging deeper into other areas like multi modular architecture or perhaps you want to ship Android apps 10x faster, then check this product - AndroidBlitz

Understanding Coroutine Context and Dispatchers in Android

boryanz — Sun, 06 Jul 2025 06:15:00 +0000

One thing that confused me early on, was understanding the relationship between coroutine context and dispatchers. But once you get it, it makes your Android development much smoother.

What is Coroutine Context?

Think of coroutine context as a map that holds information about your coroutine. It contains elements like the Job, dispatcher, exception handler, and other metadata. Each coroutine has its own context.

// Simple coroutine with context
viewModelScope.launch {
    // This coroutine inherits context from viewModelScope
    // which includes Dispatchers.Main.immediate
}

The context is inherited from parent to child coroutines. But you can also combine contexts using the + operator:

val customContext = Dispatchers.IO + SupervisorJob()
launch(customContext) {
    // This coroutine runs on IO dispatcher with SupervisorJob
}

Understanding Dispatchers

Dispatchers determine which thread or thread pool your coroutine runs on. Android provides several built-in dispatchers, each optimized for different types of work.

Dispatchers.Main

This runs coroutines on the main UI thread. Use it for UI updates and quick operations.

viewModelScope.launch(Dispatchers.Main) {
    textView.text = "Updated on main thread"
    progressBar.visibility = View.GONE
}

Dispatchers.IO

Designed for I/O operations like network requests, database queries, and file operations. It uses a shared pool of threads that can grow as needed.

viewModelScope.launch(Dispatchers.IO) {
    val response = apiService.getData()
    val result = database.insert(response)

    withContext(Dispatchers.Main) {
        updateUI(result)
    }
}

Dispatchers.Default

Best for CPU-intensive work like parsing large JSON, complex calculations, or image processing. It uses a thread pool sized to the number of CPU cores.

viewModelScope.launch(Dispatchers.Default) {
    val processedData = heavyDataProcessing(rawData)

    withContext(Dispatchers.Main) {
        displayProcessedData(processedData)
    }
}

Dispatchers.Unconfined

This one is tricky. The coroutine starts in the caller thread but can resume in any thread. Generally avoid this unless you know what you're doing.

// Not recommended for most use cases
launch(Dispatchers.Unconfined) {
    println("Before suspend: ${Thread.currentThread().name}")
    delay(100)
    println("After suspend: ${Thread.currentThread().name}")
}

Custom Dispatchers

Sometimes you need a custom dispatcher for specific requirements:

// Custom dispatcher with limited thread pool
val customDispatcher = Executors.newFixedThreadPool(4).asCoroutineDispatcher()

launch(customDispatcher) {
    // Your work here
}

// Don't forget to close it when done
customDispatcher.close()

Switching Context with withContext

One of the most useful patterns is switching contexts within a coroutine:

suspend fun loadUserData(): User {
    return withContext(Dispatchers.IO) {
        // Network call on IO dispatcher
        val userData = userApi.getUser()

        // Database operation also on IO
        userDatabase.saveUser(userData)

        userData
    }
    // Function returns on the original dispatcher
}

Common Mistakes I've Made

Mistake 1: Using Dispatchers.Main for heavy operations

// Wrong - blocks UI thread
viewModelScope.launch(Dispatchers.Main) {
    val result = processLargeFile() // This blocks UI
    updateUI(result)
}

// Right - process on Default, update on Main
viewModelScope.launch(Dispatchers.Default) {
    val result = processLargeFile()
    withContext(Dispatchers.Main) {
        updateUI(result)
    }
}

Mistake 2: Creating unnecessary context switches

// Inefficient - unnecessary context switches
viewModelScope.launch(Dispatchers.IO) {
    withContext(Dispatchers.Default) {
        withContext(Dispatchers.IO) {
            // Just stay on IO if you're doing I/O work
        }
    }
}

Testing with Dispatchers

When writing tests, you often need to replace dispatchers:

@ExperimentalCoroutinesApi
class MyViewModelTest {

    @get:Rule
    val mainDispatcherRule = MainDispatcherRule()

    @Test
    fun testDataLoading() = runTest {
        // Test runs on TestDispatcher automatically
        viewModel.loadData()

        // Assertions here
    }
}

The key thing to remember is that coroutine context and dispatchers work together to control where and how your coroutines execute. Choose the right dispatcher for your work type, and don't be afraid to switch contexts when needed.

Most Android development follows this pattern: start UI operations on Main, switch to IO for network/database work, use Default for heavy processing, then switch back to Main for UI updates. Once you get comfortable with this flow, coroutines become much more predictable.

WebView's download listener on Android: How it works?

boryanz — Sun, 06 Jul 2025 06:00:00 +0000

When users tap a download link in your WebView, nothing happens by default. The WebView just sits there. That's where setDownloadListener comes in.

The Problem

Let's say you have a simple WebView displaying a webpage with PDF downloads. Without a download listener, tapping those links does nothing. Users get frustrated because they expect the file to download, just like in a regular browser.

val webView = findViewById<WebView>(R.id.webView)
webView.loadUrl("https://example.com/page-with-downloads")
// Downloads won't work yet

How setDownloadListener Works

The setDownloadListener method lets you intercept download requests before they happen. When a user taps a download link, Android calls your listener instead of trying to handle the download itself.

webView.setDownloadListener { url, userAgent, contentDisposition, mimeType, contentLength ->
    // Handle the download here
    downloadFile(url, userAgent, contentDisposition, mimeType, contentLength)
}

The listener gives you several parameters:

url - The direct download URL
userAgent - Browser identification string
contentDisposition - Filename and attachment info from the server
mimeType - File type (like "application/pdf")
contentLength - File size in bytes

Under the Hood

When you set a download listener, the WebView's internal download handling changes. Here's what happens:

User taps a download link
WebView checks if it can handle the content type
If it can't (or if it's marked as a download), it calls your listener
Your listener receives the download parameters
You decide what to do next

The WebView doesn't actually download anything at this point. It just hands you the information and says "your turn."

Simple Implementation

Here's a basic implementation that uses Android's DownloadManager:

private fun setupDownloadListener() {
    webView.setDownloadListener { url, userAgent, contentDisposition, mimeType, contentLength ->
        val request = DownloadManager.Request(Uri.parse(url))

        // Extract filename from contentDisposition or URL
        val filename = getFileName(contentDisposition, url)

        request.apply {
            setTitle(filename)
            setDescription("Downloading file...")
            setNotificationVisibility(DownloadManager.Request.VISIBILITY_VISIBLE_NOTIFY_COMPLETED)
            setDestinationInExternalPublicDir(Environment.DIRECTORY_DOWNLOADS, filename)
            setMimeType(mimeType)
        }

        val downloadManager = getSystemService(Context.DOWNLOAD_SERVICE) as DownloadManager
        downloadManager.enqueue(request)

        Toast.makeText(this, "Download started", Toast.LENGTH_SHORT).show()
    }
}

private fun getFileName(contentDisposition: String?, url: String): String {
    return if (contentDisposition != null && contentDisposition.contains("filename=")) {
        contentDisposition.substringAfter("filename=").replace("\"", "")
    } else {
        url.substringAfterLast("/")
    }
}

Permission Requirements

Don't forget about permissions. For downloads to work, you need storage permissions:

// In your manifest
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

// For Android 10+ (API 29+), you might also need:
<uses-permission android:name="android.permission.MANAGE_EXTERNAL_STORAGE" />

And request them at runtime:

if (ContextCompat.checkSelfPermission(this, Manifest.permission.WRITE_EXTERNAL_STORAGE) 
    != PackageManager.PERMISSION_GRANTED) {
    ActivityCompat.requestPermissions(this, 
        arrayOf(Manifest.permission.WRITE_EXTERNAL_STORAGE), 
        PERMISSION_REQUEST_CODE)
}

Common Issues

Downloads not triggering: Make sure your WebView has JavaScript enabled and the correct user agent set. Some servers check these before serving downloads.

webView.settings.apply {
    javaScriptEnabled = true
    userAgentString = "Mozilla/5.0 (Linux; Android 10) AppleWebKit/537.36"
}

Filename extraction failing: The contentDisposition parameter isn't always reliable. Sometimes it's null, sometimes it's malformed. Always have a fallback that extracts the filename from the URL.

Large file handling: The DownloadManager is great for most cases, but for very large files or when you need more control, consider using OkHttp or similar libraries.

Alternative Approaches

If you need more control over the download process, you can skip DownloadManager and handle it yourself:

webView.setDownloadListener { url, _, _, _, _ ->
    // Use a custom download implementation
    startCustomDownload(url)
}

private fun startCustomDownload(url: String) {
    // Implement with OkHttp, Retrofit, or similar
    // This gives you progress callbacks, retry logic, etc.
}

Testing Downloads

Testing download functionality can be tricky. I usually create a simple HTML page with different types of download links:

<!DOCTYPE html>
<html>
<body>
    <a href="sample.pdf" download>PDF Download</a>
    <a href="image.jpg" download>Image Download</a>
    <a href="document.docx">Document Download</a>
</body>
</html>

Load this in your WebView and test each link type to make sure your download listener handles them correctly.

Final Thoughts

The setDownloadListener is essential for any app that uses WebViews and needs to handle downloads. It's not complicated once you understand that the WebView is just passing the download responsibility to you.

The key is handling the different parameter combinations gracefully and providing good user feedback. Users should know when a download starts, when it completes, and where to find the file.

Most importantly, test with different file types and servers. Not all websites handle downloads the same way, and you'll want to make sure your implementation works across different scenarios.

Want to connect? You can follow me on X here.

Why every Android dev needs a template repository? 💻

boryanz — Sun, 29 Jun 2025 09:19:28 +0000

Why Every Android Developer Should Have a Jetpack Compose Boilerplate Template Repository

Starting new projects from scratch is tedious. And when you're working with Jetpack Compose, setting up the same dependencies, navigation, themes, and basic structure every time makes you bang your head against the wall.

That's why I created AndroidBlitz boilerplate.

The Problem with Starting from Scratch

...you need navigation, state management, dependency injection, network calls, proper theming, and testing setup. Setting this up every time wastes hours, sometimes days! It drains my whole motivation to continue with the app develpment.

I tracked once, it takes me about 3-4 hours to set up a proper project structure with all the essentials. That's half a working day gone before writing any actual feature code.

What Should Your Boilerplate Include?

Based on my experience, here's what your template should have:

Core Dependencies

Your build.gradle.kts should include the essentials:

dependencies {
    implementation(libs.androidx.core.ktx)
    implementation(libs.androidx.lifecycle.runtime.ktx)
    implementation(libs.androidx.activity.compose)
    implementation(platform(libs.androidx.compose.bom))
    implementation(libs.androidx.compose.ui)
    implementation(libs.androidx.compose.ui.tooling.preview)
    implementation(libs.androidx.compose.material3)
    implementation(libs.androidx.navigation.compose)
    implementation(libs.hilt.android)
    implementation(libs.hilt.navigation.compose)
    kapt(libs.hilt.compiler)
    implementation(libs.retrofit)
    implementation(libs.retrofit.converter.gson)
    implementation(libs.okhttp.logging.interceptor)
    testImplementation(libs.junit)
    androidTestImplementation(libs.androidx.junit)
    androidTestImplementation(libs.androidx.espresso.core)
}

Navigation Setup

Set up navigation with proper route handling:

@Composable
fun AppNavigation() {
    val navController = rememberNavController()

    NavHost(
        navController = navController,
        startDestination = "home"
    ) {
        composable("home") {
            HomeScreen(
                onNavigateToDetails = { id ->
                    navController.navigate("details/$id")
                }
            )
        }
        composable(
            "details/{id}",
            arguments = listOf(navArgument("id") { type = NavType.StringType })
        ) { backStackEntry ->
            val id = backStackEntry.arguments?.getString("id") ?: ""
            DetailsScreen(
                id = id,
                onBack = { navController.popBackStack() }
            )
        }
    }
}

Dependency Injection Structure

Hilt modules for common dependencies:

@Module
@InstallIn(SingletonComponent::class)
object NetworkModule {

    @Provides
    @Singleton
    fun provideOkHttpClient(): OkHttpClient {
        return OkHttpClient.Builder()
            .addInterceptor(HttpLoggingInterceptor().apply {
                level = if (BuildConfig.DEBUG) {
                    HttpLoggingInterceptor.Level.BODY
                } else {
                    HttpLoggingInterceptor.Level.NONE
                }
            })
            .build()
    }

    @Provides
    @Singleton
    fun provideRetrofit(okHttpClient: OkHttpClient): Retrofit {
        return Retrofit.Builder()
            .baseUrl("https://api.example.com/")
            .client(okHttpClient)
            .addConverterFactory(GsonConverterFactory.create())
            .build()
    }
}

Theme and Styling

A proper Material 3 theme setup:

@Composable
fun AppTheme(
    darkTheme: Boolean = isSystemInDarkTheme(),
    content: @Composable () -> Unit
) {
    val colorScheme = when {
        darkTheme -> DarkColorScheme
        else -> LightColorScheme
    }

    MaterialTheme(
        colorScheme = colorScheme,
        typography = Typography,
        content = content
    )
}

Testing Setup

Include basic testing utilities:

@RunWith(AndroidJUnit4::class)
@HiltAndroidTest
class ExampleInstrumentedTest {

    @get:Rule
    val hiltRule = HiltAndroidRule(this)

    @get:Rule
    val composeTestRule = createAndroidComposeRule<MainActivity>()

    @Test
    fun testExample() {
        composeTestRule.setContent {
            AppTheme {
                HomeScreen()
            }
        }

        composeTestRule.onNodeWithText("Hello").assertIsDisplayed()
    }
}

Why This Saves Time

With a proper boilerplate, starting a new project takes 10 minutes instead of hours. You clone the template, rename the package, update the app name, and you're ready to build features.

I've used my template for 5 different projects now. Each time, I just focus on the business logic instead of setting up the same infrastructure over and over.

The reasons I created AndroidBlitz, and why you should have it

Core Value Proposition

AndroidBlitz accelerates Android development by providing a production-ready foundation that eliminates the need to build common functionality from scratch. Save a ton of hours in setting up the projects.

Technical Foundation

The template includes enterprise-grade architecture with Jetpack Compose and Material Design 3, Firebase integration, multiple dashboard options, advanced networking through Retrofit/Ktor, biometric security features, and over 20 pre-built UI components.

Customization

The standout feature is the configurable features_config.json system that lets you pick and choose exactly which components you need, like Firebase services, Google Maps, authentication flows, or testing utilities. The package removal system then strips out everything you don't use, keeping your final app optimized and lightweight.

This approach solves the common problem of boilerplate projects that force you to carry dead weight from unused features while still providing comprehensive functionality when you need it.

Compose Multiplatform looks promising 🚀

boryanz — Sun, 29 Jun 2025 08:48:07 +0000

Jetpack Compose Multiplatform in 2025

Jetpack Compose Multiplatform is transforming how we think about cross-platform development, and it's finally ready for production use. I played around a bit, and found out it's really easy for setting the project. I also found some interesting statistics about CMP

Why Compose Multiplatform is Taking Over

Built by JetBrains and leveraging Google's Jetpack Compose foundation, it allows you to share up to 80% of your codebase across Android, iOS, desktop, and the declarative UI paradigm you already understand.

60% of the top 1,000 apps in the Play Store already use Jetpack Compose, and with Compose for iOS moving toward production readiness, major companies are making the switch.
The timing couldn't be better for intermediate Android developers to expand their skill set.

What Makes It Different from Other Cross-Platform Solutions

Unlike React Native or Flutter, Compose Multiplatform doesn't ask you to learn a new mental model. If you've written this in Android:

@Composable
fun UserProfile(user: User) {
    Card(
        modifier = Modifier
            .fillMaxWidth()
            .padding(16.dp)
    ) {
        Column(
            modifier = Modifier.padding(16.dp)
        ) {
            Text(
                text = user.name,
                style = MaterialTheme.typography.headlineSmall
            )
            Text(
                text = user.email,
                style = MaterialTheme.typography.bodyMedium,
                color = MaterialTheme.colorScheme.onSurfaceVariant
            )
        }
    }
}

That same code works across all platforms in Compose Multiplatform. No platform-specific adaptations, no different API patterns—just the same @Composable functions, state management, and UI patterns you already know.

Setting Up Your First Multiplatform Project

The easiest way to get started is using the Kotlin Multiplatform wizard or the official template:

// shared/src/commonMain/kotlin/App.kt
import androidx.compose.foundation.layout.*
import androidx.compose.material3.*
import androidx.compose.runtime.*
import androidx.compose.ui.Alignment
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp

@Composable
fun App() {
    MaterialTheme {
        var count by remember { mutableIntStateOf(0) }

        Column(
            modifier = Modifier
                .fillMaxSize()
                .padding(16.dp),
            horizontalAlignment = Alignment.CenterHorizontally,
            verticalArrangement = Arrangement.Center
        ) {
            Text("You clicked $count times")

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

            Button(onClick = { count++ }) {
                Text("Click me!")
            }
        }
    }
}

This single file creates a working app for all supported platforms. The project structure follows Kotlin Multiplatform conventions:

project/
├── shared/
│   ├── src/
│   │   ├── commonMain/kotlin/    # Shared UI and logic
│   │   ├── androidMain/kotlin/   # Android-specific code
│   │   └── iosMain/kotlin/       # iOS-specific code
├── androidApp/                   # Android application
├── iosApp/                       # iOS application (Xcode project)
└── desktopApp/                   # Desktop application

Handling Platform-Specific Requirements

Real-world apps need platform-specific functionality. Compose Multiplatform handles this elegantly through expect/actual declarations:

// commonMain
expect class PlatformContext

expect fun showToast(context: PlatformContext, message: String)

@Composable
expect fun StatusBarColor(color: Color)

// androidMain
import android.content.Context
import android.widget.Toast

actual typealias PlatformContext = Context

actual fun showToast(context: PlatformContext, message: String) {
    Toast.makeText(context, message, Toast.LENGTH_SHORT).show()
}

@Composable
actual fun StatusBarColor(color: Color) {
    val systemUiController = rememberSystemUiController()
    LaunchedEffect(color) {
        systemUiController.setStatusBarColor(color)
    }
}

// iosMain
import platform.UIKit.UIApplication

actual class PlatformContext

actual fun showToast(context: PlatformContext, message: String) {
    // iOS implementation using native alerts or third-party library
}

@Composable
actual fun StatusBarColor(color: Color) {
    // iOS status bar color implementation
}

Advanced Patterns: Navigation and State Management

For complex apps, you'll want proper navigation and state management. Compose Multiplatform works seamlessly with popular libraries:

// Using Voyager for navigation
sealed class Screen {
    object Home : Screen()
    data class Details(val itemId: String) : Screen()
}

@Composable
fun AppNavigation() {
    Navigator(HomeScreen()) { navigator ->
        SlideTransition(navigator) { screen ->
            when (screen) {
                is Screen.Home -> HomeScreen(
                    onNavigateToDetails = { itemId ->
                        navigator.push(Screen.Details(itemId))
                    }
                )
                is Screen.Details -> DetailsScreen(
                    itemId = screen.itemId,
                    onBack = { navigator.pop() }
                )
            }
        }
    }
}

For state management, you can use familiar patterns like ViewModels with shared business logic:

// shared/src/commonMain/kotlin/presentation/UserViewModel.kt
class UserViewModel : ViewModel() {
    private val _users = MutableStateFlow<List<User>>(emptyList())
    val users = _users.asStateFlow()

    private val _isLoading = MutableStateFlow(false)
    val isLoading = _isLoading.asStateFlow()

    fun loadUsers() {
        viewModelScope.launch {
            _isLoading.value = true
            try {
                _users.value = userRepository.getUsers()
            } catch (e: Exception) {
                // Handle error
            } finally {
                _isLoading.value = false
            }
        }
    }
}

Performance Considerations and Best Practices

Compose Multiplatform uses Skia for rendering, which provides excellent performance across platforms. However, there are some best practices to follow:

1. Optimize Recomposition

@Composable
fun UserList(users: List<User>) {
    LazyColumn {
        items(
            items = users,
            key = { user -> user.id } // Important for performance
        ) { user ->
            UserItem(
                user = user,
                modifier = Modifier.animateItemPlacement()
            )
        }
    }
}

2. Use Derivations for Complex State

@Composable
fun SearchableUserList(users: List<User>) {
    var searchQuery by remember { mutableStateOf("") }

    val filteredUsers by remember {
        derivedStateOf {
            if (searchQuery.isBlank()) {
                users
            } else {
                users.filter { it.name.contains(searchQuery, ignoreCase = true) }
            }
        }
    }

    // UI implementation
}

3. Handle Large Lists Efficiently

@Composable
fun LazyUserGrid(users: List<User>) {
    LazyVerticalGrid(
        columns = GridCells.Adaptive(minSize = 150.dp),
        contentPadding = PaddingValues(16.dp),
        verticalArrangement = Arrangement.spacedBy(8.dp),
        horizontalArrangement = Arrangement.spacedBy(8.dp)
    ) {
        items(users) { user ->
            UserCard(user = user)
        }
    }
}

Benefits

From a practical standpoint, Compose Multiplatform delivers compelling benefits:

Reduced Development Time: Share 80%+ of your UI code across platforms
Consistent User Experience: Same animations, interactions, and visual design
Leverage Existing Skills: No need to learn new languages or paradigms
Easier Maintenance: One codebase to update, test, and debug
Native Performance: Built on native rendering engines, not web views

The ecosystem is mature enough for production use. Start small.

The learning curve is gentle if you already know Jetpack Compose, and the productivity gains are substantial once you're comfortable with the multiplatform patterns.

Five Jetpack Compose state management mistakes I made

boryanz — Sun, 29 Jun 2025 08:36:01 +0000

5 State Management Mistakes That Are Killing Your Jetpack Compose Performance

I keep seeing the same performance mistakes over and over. These aren't syntax errors or crashes. They're silent killers that make your app feel sluggish.

Most developers know about state management. But knowing and doing it right are different things. Here are the mistakes I made and sometimes I'm still making. (The reason why this post is written is to remind myself)

Mistake #1: Reading State in the Wrong Place

This one trips up everyone. You put state at the top of your composable, then wonder why everything recomposes.

@Composable
fun UserProfile(userId: String) {
    val user by viewModel.userState.collectAsState()
    val posts by viewModel.postsState.collectAsState()

    Column {
        ProfileHeader(user) // Recomposes when posts change
        PostsList(posts)    // Recomposes when user changes
    }
}

The fix? Move state reads closer to where you use them.

@Composable
fun UserProfile(userId: String) {
    Column {
        ProfileHeader { 
            val user by viewModel.userState.collectAsState()
            UserHeaderContent(user)
        }
        PostsList { 
            val posts by viewModel.postsState.collectAsState()
            PostsContent(posts)
        }
    }
}

Now each section only recomposes when its own data changes.

Mistake #2: Forgetting About Stability

Compose has this thing called "stability." If your data isn't stable, Compose assumes it might change and skips important optimizations.

data class UserProfile(
    val name: String,
    val avatar: String,
    val preferences: MutableMap<String, Any> // This kills stability
)

@Composable
fun ProfileCard(profile: UserProfile) {
    // This will recompose way more than needed
    Card {
        Text(profile.name)
        AsyncImage(url = profile.avatar)
    }
}

The MutableMap makes the whole class unstable. Here's the fix:

@Immutable
data class UserProfile(
    val name: String,
    val avatar: String,
    val preferences: Map<String, String> // Immutable now
)

Or use the @Stable annotation if you need some mutability:

@Stable
class UserProfileState {
    var name: String by mutableStateOf("")
    var avatar: String by mutableStateOf("")
    val preferences: Map<String, String> = emptyMap()
}

Mistake #3: Creating State in Composables

I see this everywhere. People create ViewModels or state holders inside composables.

@Composable
fun ProductList() {
    val viewModel = ProductViewModel() // New instance every recomposition
    val products by viewModel.products.collectAsState()

    LazyColumn {
        items(products) { product ->
            ProductItem(product)
        }
    }
}

Every recomposition creates a new ViewModel. Your data gets reset. Your app feels broken.

Use hiltViewModel() or viewModel() instead:

@Composable
fun ProductList(
    viewModel: ProductViewModel = hiltViewModel()
) {
    val products by viewModel.products.collectAsState()

    LazyColumn {
        items(products) { product ->
            ProductItem(product)
        }
    }
}

Mistake #4: Heavy Calculations in Composable Bodies

Composables can run on every frame during animations. Don't do expensive work in them.

@Composable
fun ExpensiveCalculation(data: List<DataPoint>) {
    val result = data
        .filter { it.isValid() }
        .groupBy { it.category }
        .mapValues { it.value.sumOf { point -> point.value } } // Runs every recomposition

    DisplayResult(result)
}

Use remember to cache expensive calculations:

@Composable
fun ExpensiveCalculation(data: List<DataPoint>) {
    val result = remember(data) {
        data
            .filter { it.isValid() }
            .groupBy { it.category }
            .mapValues { it.value.sumOf { point -> point.value } }
    }

    DisplayResult(result)
}

The calculation only runs when data actually changes.

Mistake #5: Not Using Derivations

Sometimes you need computed state based on other state. Don't create separate state for this.

@Composable
fun ShoppingCart() {
    var items by remember { mutableStateOf(emptyList<CartItem>()) }
    var total by remember { mutableStateOf(0.0) } // Separate state for total

    // Manually updating total everywhere
    Button(
        onClick = { 
            items = items + newItem
            total = items.sumOf { it.price } // Easy to forget
        }
    ) {
        Text("Add Item")
    }
}

Use derivedStateOf instead:

@Composable
fun ShoppingCart() {
    var items by remember { mutableStateOf(emptyList<CartItem>()) }
    val total by remember {
        derivedStateOf { items.sumOf { it.price } }
    }

    Button(
        onClick = { items = items + newItem }
    ) {
        Text("Add Item")
    }
}

Total updates automatically. No manual syncing needed.

The Real Impact

These mistakes don't just slow down your app. They make development harder too. When everything recomposes, debugging becomes a nightmare. Performance tools show red everywhere. Users complain about battery drain.

I learned this stuff the hard way. My first Compose app was a disaster. Everything lagged. The team spent weeks hunting performance issues. Turns out, it was all state management.

What's Next?

Start with one mistake at a time. Don't try to fix everything at once. I usually start with stability annotations. They're easy to add and give immediate benefits.

Use the Compose compiler reports to see what's actually stable in your code. Add this to your build file:

android {
    compileOptions {
        freeCompilerArgs += listOf(
            "-P",
            "plugin:androidx.compose.compiler.plugins.kotlin:reportsDestination=${project.buildDir.absolutePath}/compose_compiler"
        )
    }
}

Run a build and check the reports. You'll be surprised what's unstable.

Performance in Compose isn't magic. It's about understanding how recomposition works and writing code that works with it, not against it. These five mistakes are where most problems start. Fix them, and your app will feel completely different.

OnNewIntent() in Android

boryanz — Sun, 29 Jun 2025 08:23:01 +0000

What is onNewIntent, issues with it and how to use it properly without sacrificing security?

I've been working on Android development since 2021, and one method that caught my eye these days was onNewIntent().

Let me explain what it is, why it can be dangerous, and how to use it safely.

What is onNewIntent?

onNewIntent() gets called when your activity is already running and a new intent tries to start it. Instead of creating a new instance, Android delivers the new intent to your existing activity through this method.

Here's a basic example:

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        handleIntent(intent)
    }

    override fun onNewIntent(intent: Intent?) {
        super.onNewIntent(intent)
        intent?.let { handleIntent(it) }
    }

    private fun handleIntent(intent: Intent) {
        // Process the intent data
        val data = intent.getStringExtra("user_data")
        // Do something with the data
    }
}

This happens when your activity has launch modes like singleTop, singleTask, or singleInstance in the manifest.

The Security Problem

Here's where things get tricky. Other apps can send intents to your activity if it's exported or has intent filters. And if you're not careful, they can pass malicious data.

I've seen developers do this:

override fun onNewIntent(intent: Intent?) {
    super.onNewIntent(intent)

    // DON'T DO THIS - Direct access without validation
    val userId = intent?.getStringExtra("user_id")
    val accountData = intent?.getParcelableExtra<Account>("account")

    // Directly using the data without checks
    loadUserProfile(userId!!)
    processAccount(accountData!!)
}

This is dangerous because any app can craft an intent with malicious data and send it to your activity.

Common Attack Scenarios

Data Injection: Malicious apps can pass harmful strings that might break your app or cause crashes.

Intent Spoofing: Apps can pretend to be legitimate sources and pass fake data.

State Manipulation: Attackers might try to manipulate your app's state by sending unexpected intents.

How to Use onNewIntent Safely

Here's how I handle onNewIntent() securely:

class SecureActivity : AppCompatActivity() {

    private companion object {
        const val EXPECTED_ACTION = "com.yourapp.SECURE_ACTION"
        const val TRUSTED_PACKAGE = "com.yourapp.trusted"
    }

    override fun onNewIntent(intent: Intent?) {
        super.onNewIntent(intent)
        intent?.let { 
            if (isIntentSafe(it)) {
                handleSecureIntent(it)
            } else {
                Log.w("SecureActivity", "Rejected unsafe intent")
            }
        }
    }

    private fun isIntentSafe(intent: Intent): Boolean {
        // Check the action
        if (intent.action != EXPECTED_ACTION) {
            return false
        }

        // Verify the calling package if needed
        val callingPackage = callingActivity?.packageName
        if (callingPackage != null && callingPackage != TRUSTED_PACKAGE) {
            return false
        }

        // Validate data types and ranges
        val userId = intent.getStringExtra("user_id")
        if (userId.isNullOrBlank() || !isValidUserId(userId)) {
            return false
        }

        return true
    }

    private fun handleSecureIntent(intent: Intent) {
        val userId = intent.getStringExtra("user_id")
        // Safe to use now
        userId?.let { loadUserProfile(it) }
    }

    private fun isValidUserId(userId: String): Boolean {
        // Your validation logic here
        return userId.matches(Regex("^[a-zA-Z0-9_-]+$")) && userId.length <= 50
    }
}

Best Practices

Always validate: Never trust data from intents without validation.
Use explicit intents: When possible, use explicit intents instead of implicit ones.
Limit exported activities: Only export activities that really need to be accessible from other apps.

// In AndroidManifest.xml
<activity
    android:name=".MainActivity"
    android:exported="false"  // This prevents other apps from starting it
    android:launchMode="singleTop" />

Check calling activity: Use callingActivity to verify who's sending the intent.
Sanitize data: Clean and validate all incoming data before processing.

When to Use Different Launch Modes

singleTop: Use when you want to avoid creating duplicate activities on top of the stack
singleTask: Use for main activities that should have only one instance
singleInstance: Use rarely, only for special cases like phone dialer

Each of these will trigger onNewIntent() under certain conditions.

Real-World Example

I once worked on a banking app where we had to handle deep links. The initial implementation was vulnerable because it trusted all incoming intents. We fixed it by:

Validating the deep link format
Checking if the user was authenticated
Sanitizing all parameters
Using a whitelist of allowed actions

private fun handleDeepLink(intent: Intent) {
    val uri = intent.data ?: return

    // Validate the URI scheme and host
    if (uri.scheme != "bankapp" || uri.host != "secure") {
        return
    }

    // Check authentication first
    if (!userManager.isAuthenticated()) {
        redirectToLogin()
        return
    }

    // Process only allowed paths
    when (uri.path) {
        "/transfer" -> handleTransfer(uri)
        "/balance" -> showBalance()
        else -> showError("Invalid deep link")
    }
}

Takeaway

onNewIntent() is useful but comes with security risks. Always validate incoming data, limit activity exposure, and never trust external intents blindly.
The key is treating every intent as potentially malicious until proven otherwise. It might seem paranoid, but it's better than dealing with security vulnerabilities later.
And remember, security isn't just about preventing crashes. It's about protecting your users' data and maintaining trust in your app.

New shiny things in Android development in 2025

boryanz — Sat, 28 Jun 2025 12:53:40 +0000

Building apps should be fun, not a marathon. If you're still wrestling with complex setups and slow development cycles, Google I/O 2025 and Android 16 brought some game-changing tools that'll make your life easier. I wouldn't bother with fancy optimizations if you're building a simple MVP, but when you're working on something serious, these practices will save you weeks.

Speed Through Smart Automation

Remember when upgrading dependencies felt like navigating a minefield? Android Studio's Version Upgrade Agent handles this now. It analyzes your libs.versions.toml file and suggests updates automatically. No more manual checking of compatibility matrices or hunting down breaking changes.

// Before: Manual dependency management nightmare
implementation "androidx.compose.ui:ui:1.4.3"
implementation "androidx.compose.ui:ui-tooling:1.4.3"
// ... and 20 more lines to update manually

// Now: Version Upgrade Agent handles this
// Just accept the suggested updates

The downsides of manual dependency management are:

you waste hours checking compatibility
you miss important security updates
you break things by mixing incompatible versions

Composition Over Complexity in UI

Android 16 pushes adaptive apps hard, and for good reason. Instead of building separate layouts for tablets, phones, and foldables, Jetpack Compose lets you compose responsive UIs from the ground up.

@Composable
fun AdaptiveLayout(windowSize: WindowSizeClass) {
    when (windowSize.widthSizeClass) {
        WindowWidthSizeClass.Compact -> SinglePaneLayout()
        WindowWidthSizeClass.Medium -> TwoPaneLayout()
        WindowWidthSizeClass.Expanded -> ThreePaneLayout()
    }
}

This isn't just cleaner code - it's faster development. You write once, adapt everywhere. No more maintaining separate layouts for different screen sizes.

Testing with Natural Language

The new Journeys feature in Android Studio lets you describe user flows in plain English instead of writing complex UI tests:

// Old way: Complex UI test setup
@Test
fun loginFlow() {
    onView(withId(R.id.username))
        .perform(typeText("user@example.com"))
    onView(withId(R.id.password))
        .perform(typeText("password123"))
    onView(withId(R.id.loginButton))
        .perform(click())
    // ... more boilerplate
}

// New way: Natural language journeys
// "User enters email, types password, taps login, sees dashboard"

Requirements change fast. Your testing shouldn't be the bottleneck.

Cross-Platform Without the Headache

Kotlin Multiplatform is finally ready for prime time. Share your business logic between Android and iOS without compromising on platform-specific UI:

// Shared business logic
class UserRepository {
    suspend fun getUser(id: String): User {
        // Platform-agnostic implementation
    }
}

// Platform-specific UI stays native
// Android: Compose
// iOS: SwiftUI

The beautiful thing about this approach is you're not building a hybrid app that feels foreign on both platforms. You get native performance with shared logic.

Performance Monitoring That Actually Helps

Android 16 introduces APIs that tell you exactly where your app is struggling:

val performanceMonitor = PerformanceMonitor.getInstance()
val cpuHeadroom = performanceMonitor.getCpuHeadroom()
val gpuHeadroom = performanceMonitor.getGpuHeadroom()

if (cpuHeadroom < 0.2f) {
    // Reduce background tasks
    // Skip non-essential animations
}

Instead of guessing what's slow, you get real data about CPU and GPU availability. Much better than shooting in the dark with profilers.

Summary

Building fast doesn't mean cutting corners. Use automation where it makes sense - dependency updates, UI adaptation, testing flows. Keep your code simple with composition patterns. And leverage the new performance APIs to optimize based on data, not assumptions.

The tools are there. Your users expect smooth, fast apps that work everywhere. Time to deliver them.

Happy coding :)

Want to become a software engineer?

boryanz — Sun, 29 Sep 2024 11:38:15 +0000

Eventually, you decide to try this field where people pay you money to sit all day in front of PC and type code. Nice, let’s go deeper.

Computer science is a HUGE field and you must decide which path to take. If you are a complete beginner you could take anything because any initial knowledge you get is valuable. Let’s say you take Native Android development as I did 5 years ago. In the beginning, what bugged me the most was where to start!? No connections, no guidance no nothing.

The only way to learn a concept is to apply theoretical knowledge. The closest path between theory and real project, is the course. Take a course or a bootcamp and code along it. You won’t understand most of the stuff but you will write down all the terminlogy and then search for it later. After finishing the course, immediately start building your own project, this is the most important step, because you will end up in a lot of errors and be forced to google every minute. At first, it would be painful to google all day but as days goes by you will be more fluent in language which you are working on. For you it would be intuitive to learn all the concepts and watch dozens of tutorials before starting building something new, watch out, there lay the worst trap you can fall into!!! Terminology wise, it’s called “Tutorial hell” where one watch tutorials all the time and knows nothing.

The moment you start building your own stuff, you’ll realize that you don’t know nothing. You must endure this period which might be 1-4 months if you are complete beginner. Keep going, don’t lose focus! The obvious question would be: Where to find ideas for real world project?

I suppose you have a hobby, or at least interest in something. If you don’t, first get it and then start programming becuse software is just a tool for building solutions for the people. Extract anything from your hobby, in my case I was beekeeper back then. My ideas was to keep track of my beehives, and have a todos inside the app. I am sure you can find something, even it sounds silly, build the product anyway! Keep in mind to keep the product(app) small with essential features only.

Probably you’ll spent several months to a year building the app, and in the process you’ll learn a ton of stuff. While building the product, create a decent looking github profile, pdf Resume and Linkedin profile. After finishing your first app, you can go onto the next project. I would build at least 3-5 projects before applying anywhere.

There is one catch here, the interviews. Interviews are totally different from the actual software engineering job. You’ll need to know data structures and algorithms so you’ll need to spend some time on this as well, around 2-3 months learning theory and practicing DSA excerises.

So in order to get the job. Personal projects + data structures and algorithms are a must.

To summarize, the process is hard because it requires consistency, a long hours at your desk baning your head why code doesn’t work. The only way to have a motivation is to have a vision about the product you are building, otherwise failure is inevitable.

If you feel passion to create something from scratch and also provide solution to a real world problem, you’ll succeed! Feel free to mail me if you have questions about this topic, I’m open for sharing my experinece with everyone who want to make a switch. Cheers.