DEV Community: David Rufai

Introduction to media streaming: Part 1

David Rufai — Tue, 07 Jul 2026 20:51:52 +0000

I recently interviewed with a popular streaming platform for a Senior Software Engineer role focused on low-level media streaming. As someone with prior experience in this space, I used the prep process to go deeper into the internals of how streaming actually works. The interview went well, but the role wasn't quite the right fit at the time. In an effort not let that knowledge go to waste, I thought I'd write an article to share what I learned during this period.

This article is the first in a series introducing how media streaming works on the client side: the steps involved in getting a piece of media from a server onto a client device over the internet, so off we go!

The Problem with Downloading

I believe at some point you've consume some sort of media on the internet today with either your phone, your laptop, maybe even a pager if you're reading this from 1998. Whether it's a short clip on Instagram or X(formerly Twitter), or a two-hour film on Netflix or Amazon Prime, or maybe even listening to your favourite music on Spotify that content had to get to your device somehow.

These media content can be delivered in various ways but we'd be looking at two of them. In the early days of the internet, there was really just one go-to option, downloading the entire file before playback actually starts. Yeah that's works fine for a few second clip, but where the problem lies is when a long form media content is being served to a user. Downloading an hour of 720p video over a 4G connection can take several minutes depending on your connection quality, now imagine how that scales when the media resolution is larger with a longer duration. Nobody wants to stare at a loading bar for ten minutes before a movie starts.

Enters Streaming

The solution to this was streaming. In context media, streaming is the process of continually delivering multimedia content, like video, audio, or subtitles over the internet in near realtime.

Instead of waiting for the entire file to download, streaming breaks the media into small chunks (typically a few seconds each) that are delivered and buffered continuously. Playback can start as soon as the first chunk of the media arrives, rather than waiting for the whole file. See how that solves the download problem?...now let's dive a bit deeper into how these streaming technologies work.

Before playback can start with streaming, the player(client) needs to know what to fetch and in what order. That's the job of a manifest file, a kind of playlist that lists the available chunks and quality levels. depending on the streaming protocol, this manifest file can be formatted differently. HLS uses a .m3u8 manifests, while MPEG-DASH uses .mpd manifests. We won't go deep on these yet, but it's worth knowing they exist: they're the reason a player can jump between quality levels mid-playback without you noticing something we'll cover properly in Part 2 when we get into adaptive bitrate streaming.

The Two Big Streaming Technologies

Since streaming's early days, several technologies have emerged, but two dominate today RIP Adobe Flash:

HTTP Live Streaming (HLS) — developed by Apple
Dynamic Adaptive Streaming over HTTP (DASH), also known as MPEG-DASH

Both work on the same core idea described above: chunked delivery guided by a manifest. Before any video can be delivered this way, though, it needs to be prepared, encoded, packaged, and often encrypted. Tools like FFmpeg and Shaka Packager handle this: taking a raw, hour long video file and turning it into the chunks and manifests a streaming player can actually use.

Containers and Codecs

To support an the vast array of browsers, OS, and devices available today you can't rely on just a single media format. This is where containers and codecs come in, two terms that get used interchangeably but mean different things.

think of container as just that, a shell for housing multiple data streams maybe an audio, video and or subtitle stream, bundled into one file. An MP4 file, for example, is a container that might hold an H.264 video stream and an AAC audio stream inside it.

Each of those individual streams is compressed using a codec(encoder/decoder), an algorithm designed to shrink raw, usually oversized media data into something efficient to store and transmit over the internet. some of the common video codecs include:

H.264 / AVC (Advanced Video Coding)
H.265 / HEVC (High Efficiency Video Coding), the successor to H.264
AV1, a newer, royalty-free codec

And common audio codecs include:

AAC (Advanced Audio Coding)
Opus
FLAC

The codec is what does the heavy lifting of compression; the container is just the box everything ships in ;)

What's Next

To keep this article from running longer than the Dead Sea Scrolls, I'll stop here. Quick recap of what we covered:

Why downloading doesn't scale for long-form video, and how streaming solves it
How chunked delivery and manifest files work together
HLS and DASH as the two dominant streaming protocols
The difference between containers (the shell) and codecs (the compression)

In Part 2, we'll dig into bitrate vs. resolution and how they affect playback quality, how adaptive bitrate streaming actually decides what to switch to and when, and how premium content gets protected with DRM and how the client platform handle securing these files.

Stay tuned!

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

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