Forem: David Rufai

Jetpack Compose Optimization - Making Your App Run Like a Well-Oiled Machine

David Rufai — Wed, 30 Oct 2024 18:56:55 +0000

I think we all know how easy it has become when it comes to building the UI in our Android apps since the introduction of Jetpack Compose, we've gone from the days of requiring 3 separate components to display a simple list(no shades to RecyclerView), to achieving the same with just a simple composable - 😍 the LazyColumn. But the thing with new technologies is that they often introduce a new level of complexity, in the case of Compose minimizing the number of re-compositions can be a very huge performance booster. This article aims at providing tips/techniques on how to do just that.

Before jumping right in we first need to understand how a composable is rendered on screen.

Composition: In this initial phase, Compose constructs a UI tree, a hierarchical representation of your UI. It executes your composable functions and reading state and builds the structure of your UI. This phase determines what UI elements to display and their relationships.

Layout: Once the UI tree is established, the Layout phase takes over. It measures and positions each UI element within the tree, calculating its size and placement on the screen. This phase ensures that elements are arranged correctly and don't overlap.

Drawing: Finally, the Drawing phase renders the UI to the screen. It takes the layout information generated in the previous phase and translates it into pixels, visually displaying your app's interface. This phase uses the device's graphics hardware to optimize performance.

When the device configuration(e.g, a screen rotation) or a state that the Composable depends on changes, the Composable is "re-composed". meaning it goes through these three phases again, updating the UI if necessary. This ensures that the UI remains consistent with the current state and configurations.

Now that we understand how Compose renders its UI components, let's jump into optimizing our apps.

Writing stable Composables

One way of reducing unnecessary recomposition in your app is by writing stable composables, but what do I mean by that? Stable composables are composables whose parameters are immutable or can be determined to have not changed between recompositions, on the other hand, Unstable composables have parameters that are mutable or cannot be determined to have changed, requiring full recomposition even if only a portion of the data has changed.

take the code block below for example.

@Composable
fun ItemList(items: List<String>) {
    Column {
        items.forEach { item ->
            Text(item)
        }
    }
}

// Usage with un-stable state
@Composable
fun MainScreen() {
    val items =  mutableListOf("Apple", "Banana", "Cherry")
    DisplayItems(items)
}

while this seems normal, this code would always cause DisplayItems to recompose even when the items hasn't particularly changed, this is because items is of a mutable data type, and the compose compiler doesn't know when it actually changes, so to err on the side of caution re-composition is always triggered. To fix this we can use the DisplayItems composable this way.

@Composable
fun MainScreen() {
    // Immutable list is stable
    val items = remember { listOf("Apple", "Banana", "Cherry") } 
    DisplayItems(items)
}

Here, items is stable because it’s created as an immutable list and wrapped in remember, meaning Compose will treat it as stable and won’t trigger recompositions unless items actually changes.

Use derivedStateOf for Computed States

Using derivedStateOf in Compose is helpful when you need to create a computed state that depends on other states, especially if the computation is expensive or the UI doesn’t need constant updates. With using this method computed values could trigger recompositions anytime the dependent state changes, even if the actual computed value doesn’t change.

@Composable
fun SearchScreen() {
    var query by remember { mutableStateOf("") }
    val items = listOf("Apple", "Banana", "Cherry", "Date")

    // Filtering directly without derivedStateOf
    val filteredItems = items.filter { it.contains(query, ignoreCase = true) }

    Column {
        TextField(
            value = query,
            onValueChange = { query = it },
            label = { Text("Search") }
        )
        filteredItems.forEach { item ->
            Text(item)
        }
    }
}

In the example above, filteredItems is recomputed every time the user types in the search bar, even if the filtered list remains unchanged, which isn't really efficient. With derivedStateOf, we ensure that filteredItems only updates when the query value actually changes, minimizing recompositions.

@Composable
fun SearchScreen() {
    var query by remember { mutableStateOf("") }
    val items = listOf("Apple", "Banana", "Cherry", "Date")

    // Using derivedStateOf for optimized filtering
    val filteredItems by remember(query) {
        derivedStateOf { items.filter { it.contains(query, ignoreCase = true) } }
    }

    Column {
        TextField(
            value = query,
            onValueChange = { query = it },
            label = { Text("Search") }
        )
        filteredItems.forEach { item ->
            Text(item)
        }
    }
}

Using Lazy Composables Effectively

The LazyColumn and LazyRow components in Compose are handy, but they’re only as efficient as your use of them. Avoid nesting too many Lazy components, and use item scopes smartly to minimize view updates. Use the LazyListState to manage scroll positions and track updates efficiently.

Using the Profiler

One of the most reliable ways to ensure an optimized app is by measuring its performance. The Android Studio Profiler is like a diagnostic tool, showing you where bottlenecks are in your app. Keep an eye on the CPU and memory usage of composables, particularly the frequency of recomposition events. You can also consider using the 'Profile GPU Rendering' *or *'Profile HWUI Rendering' tool in your device's developer options settings screen, to view frame rendering times and ensure smooth animations. For Compose, a smooth operation is usually 60 frames per second or better.

Final Thoughts

Jetpack Compose offers plenty of ways to write clean, fast, and stunning apps. And just like a car needs regular maintenance, your app needs its optimizations to stay slick and speedy. In my experience, a few small adjustments can prevent a lot of user frustration and keep them coming back to your app. Keep building & write clean code :)

Dependency Injection in Jetpack Compose with Koin: A "Koincidence"?

David Rufai — Tue, 10 Sep 2024 13:02:31 +0000

Have you ever felt like your code is drowning in dependencies, tangled like some Italian spaghetti? Fear not! Dependency Injection (DI) is here to save the day, and this time with an elder wand Koin 😊, seriously, it’s as simple as flipping a coin 🌚! Let's dive into how you can inject dependencies in your Jetpack Compose app and give your code some much-needed structure—without breaking the spacetime continuum.

Well, what's the Deal with Koin?

Koin is a lightweight DI framework built in Kotlin. Think of it as a friendly neighborhood library that helps you manage your dependencies without all the boilerplate code. It’s like hiring an assistant who knows where everything is and hands it to you when you need it. Ready to make your code cleaner? Let’s get started!

1: Add Koin to your project

First, you’ll need to add Koin to your project. Head to your app module build.gradle file and include the following lines in the dependencies section and sync gradle files:

dependencies {
    implementation "io.insert-koin:koin-android:3.1.6"
    implementation "io.insert-koin:koin-androidx-compose:3.1.6"
}

that's it, we've just summon our very own Elder wand.

2: Define Your Modules

Think of a Koin module as your favorite meal prep service—it organizes all your dependencies so you don’t have to scramble at the last minute. Here’s how you can define a module to serve up some dependencies:

val appModule = module {
    single { Repository() }  // Singleton pattern
    factory { ViewModel(get()) }  // Factory pattern
}

In this module:

We have a Repository that’s served as a single instance (singleton).
The ViewModel gets created fresh every time, with the Repository injected like magic.

3: Start Koin in Your App

Before you can start injecting stuff, you need to initialize Koin in your app’s Application class. Don't worry, it’s a one-time setup.

class MyApp : Application() {
    override fun onCreate() {
        super.onCreate()
        startKoin {
            androidLogger()
            androidContext(this@MyApp)
            modules(appModule)
        }
    }
}

Note: Don't forget to define your application class in your app's AndroidManifest.xml file using the android:name attribute in the application tag.

4: Inject in Jetpack Compose

Alright! How do we inject dependencies into our Jetpack Compose UI? It’s Surprisingly easy, no rituals, sermons, or incantations needed.

@Composable
fun MyScreen(viewModel: ViewModel = get()) {
    val data = viewModel.loadData()
    Text(text = "Data: $data")
}

The magic here is get()—it tells Koin to inject the necessary dependencies. And just like that, you’ve turned a complicated mess into a clean, organized flow. You’re a magician at this point. 🎩✨

With Koin, you can wave goodbye to manual dependency management and say hello to clean, testable, and maintainable code. Your codebase & anyone
else who works on it will thank you, and you’ll wonder why you ever did it the hard way.

Conclusion 🏁

Koin makes dependency injection in Jetpack Compose a walk in the park. It’s lightweight, easy to use, and saves you from writing boilerplate code—like a pocket-size superhero for your app. So, go ahead, flip the "Koin", and let it work its magic in your next project! Just remember, with great power comes great injectability.

Happy coding, and may your dependencies always be well-injected! 😌

Understanding Dependency Injection

David Rufai — Sun, 18 Aug 2024 18:07:08 +0000

Imagine you're working on an app that requires various components to interact seamlessly. You’ve written a class to handle user authentication, but it directly creates instances of several dependencies network services, data storage, and logging utilities. It works well at first, but as the project grows, testing becomes a nightmare. Every time you make a change, you must modify multiple classes, and mocking these dependencies for unit tests feels like a battle. You start to realize that your tightly coupled code is dragging down the entire project.

This is where Dependency Injection comes to the rescue.

Dependency Injection? What the heck is that?

Dependency Injection (DI) is a software engineering technique often used in object-oriented software development to handle object relationships. Rather than having an object create or manage its required components (dependencies), DI involves providing these components from an external source. This approach is like giving an object the tools it needs instead of letting it gather them. By implementing DI, developers can create systems where different parts are less tightly interconnected. This results in easier to modify, test, and maintain applications over time. It also allows seamless flexibility in swapping out components without affecting the overall system structure.

Here's a very basic example in Kotlin.

 class GenericEngine() {
   fun start() {
     print("engine started")
   }
 }


class Car() {   
   val engine = GenericEngine()

   fun drive() {
     engine.start()
   } 
}

Here, the Car is responsible for creating its engine, which seems pretty normal for now, right? But what happens when we want to build a car with a different type of engine? Do we create a different car class and then define our custom engine in it, or just change the GenericEngine instance to a different engine instance? This approach has some issues: the former being having to write more code for just a slightly different behavior, and the latter being having to modify a field which could cause breaking changes. This could go south quickly in large-scale applications. Fortunately for us, we have a magic trick up our sleeves... drumroll 🥁 ...Dependency Injection!!! 🙌

We could avoid all of that unnecessary modification by just requiring the engine to be passed as a dependency. This allows us to easily modify the engine type on our class object (talk about an upgrade 😉). Enough talk, here's how we do that.


class Car(private val engine: Engine) {  // Engine is injected via the constructor
    fun drive() {
        engine.start()
        println("Car is driving")
    }
}

fun main() {
    val engine = Engine()  // engine dependency is created outside the Car class
    val car = Car(engine)  // dependency is injected into the Car class
    car.drive()
}

We could take this a step further by defining an Engine interface. This provides more flexibility, enabling us to swap out different implementations of the dependency without changing the dependent class.

First, we define our interface and also two contracts (start & stop) that all engines must follow.

interface Engine {
    fun start()
    fun stop()
}

now let's create two implementations of the Engine interface.

class PetrolEngine() : Engine {
    override fun start() {
        println("engine started")
    }

    override fun stop() {
        println("engine stopped")
    }
}

class ElectricEngine() : Engine {
    override fun start() {
        println("Electric engine started, battery on 12% please find a charging station soon")
    }

    override fun stop() {
        println("electric engine stopped")
    }
}

now our Car class would depend on the Engine interface and not a specific implementation.

class Car(private val engine: Engine) {
    fun drive() {
        engine.start()
        println("Car is moving")
    }

    fun stop() {
        println("Car stopped turning off engine")
        engine.stop()
    }
}

finally here's how we can use both implementations.

    val petrolEngine: Engine = PetrolEngine()
    val electricEngine: Engine = ElectricEngine()

    val carWithPetrolEngine = Car(petrolEngine)
    carWithPetrolEngine.drive()

    val carWithElectricEngine = Car(electricEngine)
    carWithElectricEngine.drive()

This approach using an interface is more scalable and is a very common practice in software design, especially when building apps that need to be easily modified.

I guess now we could easily solve the world's energy crisis by implementing an Engine that runs on water 😅.