Android

As a Kotlin developer, you’re no stranger to the numerous architectural patterns in Android app development. From the well-established MVP (Model-View-Presenter) to the widely-used MVVM (Model-View-ViewModel), and now, the emerging MVI (Model-View-Intent), it’s easy to feel lost in the sea of choices. But here’s the thing: MVI is rapidly becoming the go-to architecture for many, and it might just be the game changer you need in your next project.

If you’re feeling overwhelmed by all the buzzwords — MVP, MVVM, and now MVI — you’re not alone. Understanding which architecture fits best often feels like decoding an exclusive developer language. But when it comes to MVI, things are simpler than they seem.

In this blog, we’ll break down MVI architecture in Kotlin step-by-step, showing why it’s gaining popularity and how it simplifies Android app development. By the end, you’ll not only have a solid grasp of MVI, but you’ll also know how to integrate it into your Kotlin projects seamlessly — without the complexity.

What is MVI, and Why Should You Care?

You’re probably thinking, “Oh no, not another architecture pattern!” I get it. With all these patterns out there, navigating Android development can feel like a never-ending quest for the perfect way to manage UI, data, and state. But trust me, MVI is different.

MVI stands for Model-View-Intent. It’s an architecture designed to make your app’s state management more predictable, easier to test, and scalable. MVI addresses several common issues found in architectures like MVP and MVVM, such as:

• State Management: What’s the current state of the UI?
• Complex UI Flows: You press a button, but why does the app behave unexpectedly?
• Testing: How do you test all these interactions without conjuring a wizard?

Challenges in Modern Android App Development

Before we dive into the core concepts of MVI, let’s first examine some challenges faced in contemporary Android app development:

• Heavy Asynchronicity: Managing various asynchronous sources like REST APIs, WebSockets, and push notifications can complicate state management.
• State Updates from Multiple Sources: State changes can originate from different components, leading to confusion and potential inconsistencies.
• Large App Sizes: Modern applications can become cumbersome in size, impacting performance and user experience.
• Asynchronicity and Size: Combining asynchronous operations with large applications can lead to unexpected issues when changes occur in one part of the app.
• Debugging Difficulties: Tracing back to identify the root cause of errors or unexpected behavior can be incredibly challenging, often leaving developers frustrated.

The Core Idea Behind MVI

MVI architecture has its roots in functional and reactive programming. Inspired by patterns like Redux, Flux, and Cycle.js, it focuses on state management and unidirectional data flow, where all changes in the system flow in one direction, creating a predictable cycle of state updates.

In MVI, the UI is driven by a single source of truth: the Model, which holds the application’s state. Each user interaction triggers an Intent, which updates the Model, and the Model, in turn, updates the View. This clear cycle makes it easier to reason about how the UI evolves over time and simplifies debugging.

Think of your app as a state machine: the UI exists in a specific state, and user actions (or intents) cause the state to change. By having a single source of truth, tracking and debugging UI behavior becomes more predictable and manageable.

Here’s a simple breakdown of the key components:

• Model: Stores the application’s state.
• View: Displays the current state and renders the UI accordingly.
• Intent: Represents user-triggered actions or events, such as button presses or swipes.

Key Principles of MVI:

• Unidirectional Data Flow: Data flows in a single direction—from Intent → Model → View, ensuring a clear and predictable cycle.
• Immutable State: The state of the UI is immutable, meaning that a new instance of the state is created with every change.
• Cyclic Process: The interaction forms a loop, as each new Intent restarts the process, making the UI highly reactive to user inputs.

MVI vs MVVM: Why Choose MVI?

You might be thinking, “Hey, I’ve been using MVVM for years and it works fine. Why should I switch to MVI?” Good question! Let’s break it down.

Bidirectional Binding (MVVM): While MVVM is widely popular, it has one potential pitfall—bidirectional data binding. The ViewModel updates the View, and the View can update the ViewModel. While this flexibility is powerful, it can lead to unpredictable behaviors if not managed carefully, with data flying everywhere like confetti at a party. You think you’re just updating the username, but suddenly the whole form resets. Debugging that can be a real headache!

Unidirectional Flow (MVI): On the other hand, MVI simplifies things with a strict, unidirectional data flow. Data only goes one way—no confusion, no loops. It’s like having a traffic cop ensuring no one drives the wrong way down a one-way street.

State Management: In MVVM, LiveData is often used to manage state, but if not handled carefully, it can lead to inconsistencies. MVI, however, uses a single source of truth (the State), which ensures consistency across your app. If something breaks, you know exactly where to look.

In the end, MVI encourages writing cleaner, more maintainable code. It might require a bit more structure upfront, but once you embrace it, you’ll realize it saves you from a nightmare of state-related bugs and debugging sessions.

Now that you understand the basics of MVI, let’s dive deeper into how each of these components works in practice.

The Model (Where the Magic Happens)

In most architectures like MVP and MVVM, the Model traditionally handles only the data of your application. However, in more modern approaches like MVI (and even in MVVM, where we’re starting to adapt this concept), the Model also manages the app’s state. But what exactly is state?

In reactive programming paradigms, state refers to how your app responds to changes. Essentially, the app transitions between different states based on user interactions or other triggers. For example, when a button is clicked, the app moves from one state (e.g., waiting for input) to another (e.g., processing input).

State represents the current condition of the UI, such as whether it’s loading, showing data, or displaying an error message. In MVI, managing state explicitly and immutably is key. This means that once a state is defined, it cannot be modified directly — a new state is created if changes occur. This ensures the UI remains predictable, easier to understand, and simpler to debug.

So, unlike older architectures where the Model focuses primarily on data handling, MVI treats the Model as the central point for both data and state management. Every change in the app’s flow — whether it’s loading, successful, or in error — is encapsulated as a distinct, immutable state.

Here’s how we define a simple model in Kotlin:

sealed class ViewState {
    object Loading : ViewState()
    data class Success(val data: List<String>) : ViewState()
    data class Error(val errorMessage: String) : ViewState()
}

• Loading: This represents the state when the app is in the process of fetching data (e.g., waiting for a response from an API).
• Success: This state occurs when the data has been successfully fetched and is ready to be displayed to the user.
• Error: This represents a state where something went wrong during data fetching or processing (e.g., a network failure or unexpected error).

The View (The thing people see)

The View is, well, your UI. It’s responsible for displaying the current state of the application. In MVI, the View does not hold any logic. It just renders whatever state it’s given. The idea here is to decouple the logic from the UI.

Imagine you’re watching TV. The TV itself doesn’t decide what show to put on. It simply displays the signal it’s given. It doesn’t throw a tantrum if you change the channel either.

In Kotlin, you could write a function like this in your fragment or activity:

fun render(state: ViewState) {
    when (state) {
        is ViewState.Loading -> showLoadingSpinner()
        is ViewState.Success -> showData(state.data)
        is ViewState.Error -> showError(state.errorMessage)
    }
}

Simple, right? The view just listens for a state and reacts accordingly.

The Intent (Let’s do this!)

The Intent represents the user’s actions. It’s how the user interacts with the app. Clicking a button, pulling to refresh, typing in a search bar — these are all intents.

The role of the Intent in MVI is to communicate what the user wants to do. Intents are then translated into state changes.

Let’s define a couple of intents in Kotlin:

sealed class UserIntent {
    object LoadData : UserIntent()
    data class SubmitQuery(val query: String) : UserIntent()
}

Notice that these intents describe what the user is trying to do. They don’t define how to do it — that’s left to the business logic. It’s like placing an order at a restaurant. You don’t care how they cook your meal; you just want the meal!

Components of MVI Architecture

Model: Managing UI State

In MVI, the Model is responsible for representing the entire state of the UI. Unlike in other patterns, where the model might focus on data management, here it focuses on the UI state. This state is immutable, meaning that whenever there is a change, a new state object is created rather than modifying the existing one.

The model can represent various states, such as:

• Loading: When the app is fetching data.
• Loaded: When the data is successfully retrieved and ready to display.
• Error: When an error occurs (e.g., network failure).
• UI interactions: Reflecting user actions like clicks or navigations.

Each state is treated as an individual entity, allowing the architecture to manage complex state transitions more clearly.

Example of possible states:

sealed class UIState {
    object Loading : UIState()
    data class DataLoaded(val data: List<String>) : UIState()
    object Error : UIState()
}

View: Rendering the UI Based on State

The View in MVI acts as the visual representation layer that users interact with. It observes the current state from the model and updates the UI accordingly. Whether implemented in an Activity, Fragment, or custom view, the view is a passive component that merely reflects the current state—it doesn’t handle logic.

In other words, the view doesn’t make decisions about what to show. Instead, it receives updated states from the model and renders the UI based on these changes. This ensures that the view remains as a stateless component, only concerned with rendering.

Example of a View rendering different states:

fun render(state: UIState) {
    when (state) {
        is UIState.Loading -> showLoadingIndicator()
        is UIState.DataLoaded -> displayData(state.data)
        is UIState.Error -> showErrorMessage()
    }
}

Intent: Capturing User Actions

The Intent in MVI represents user actions or events that trigger changes in the application. This might include events like button clicks, swipes, or data inputs. Unlike traditional Android intents, which are used for launching components like activities, MVI’s intent concept is broader—it refers to the intentions of the user, such as trying to load data or submitting a form.

When a user action occurs, it generates an Intent that is sent to the model. The model processes the intent and produces the appropriate state change, which the view observes and renders.

Example of user intents:

sealed class UserIntent {
    object LoadData : UserIntent()
    data class ItemClicked(val itemId: String) : UserIntent()
}

How Does MVI Work?

The strength of MVI lies in its clear, predictable flow of data.

Here’s a step-by-step look at how the architecture operates:

1. User Interaction (Intent Generation): The cycle begins when the user interacts with the UI. For instance, the user clicks a button to load data, which generates an Intent (e.g., LoadData).
2. Intent Triggers Model Update: The Intent is then passed to the Model, which processes it. Based on the action, the Model might load data, update the UI state, or handle errors.
3. Model Updates State: After processing the Intent, the Model creates a new UI state (e.g., Loading, DataLoaded, or Error). The state is immutable, meaning the Model doesn’t change but generates a new state that the system can use.
4. View Renders State: The View observes the state changes in the Model and updates the UI accordingly. For example, if the state is DataLoaded, the View will render the list of data on the screen. If it’s Error, it will display an error message.
5. Cycle Repeats: The cycle continues as long as the user interacts with the app, creating new intents and triggering new state changes in the Model.

This flow ensures that data moves in one direction, from Intent → Model → View, without circular dependencies or ambiguity. If the user performs another action, the cycle starts again.

Let’s walk through a simple example of how MVI would be implemented in an Android app to load data:

1. User Intent: The user opens the app and requests to load a list of items.
2. Model Processing: The Model receives the LoadData intent, fetches data from the repository, and updates the state to DataLoaded with the retrieved data.
3. View Rendering: The View observes the new state and displays the list of items to the user. If the data fetch fails, the state would instead be set to Error, and the View would display an error message.

This cycle keeps the UI responsive and ensures that the user always sees the correct, up-to-date information.

Let’s Build an Example: A Simple MVI App

Alright, enough theory. Let’s roll up our sleeves and build a simple MVI-based Kotlin app that fetches and displays a list of pasta recipes (because who doesn’t love pasta?).

Step 1: Define Our ViewState

We’ll start by defining our ViewState. This will represent the possible states of the app.

sealed class RecipeViewState {
    object Loading : RecipeViewState()
    data class Success(val recipes: List<String>) : RecipeViewState()
    data class Error(val message: String) : RecipeViewState()
}

• Loading: Shown when we’re fetching the data.
• Success: Shown when we have successfully fetched the list of pasta recipes.
• Error: Shown when there’s an error, like burning the pasta (I mean, network error).

Step 2: Define the User Intents

Next, we define the UserIntent. This will capture the actions the user can take.

sealed class RecipeIntent {
    object LoadRecipes : RecipeIntent()
}

For now, we just have one intent: the user wants to load recipes.

Step 3: Create the Reducer (Logic for Mapping Intents to State)

Now comes the fun part — the reducer! This is where the magic happens. The reducer takes the user’s intent and processes it into a new state.

Think of it as the person in the kitchen cooking the pasta. You give them the recipe (intent), and they deliver you a nice plate of pasta (state). Hopefully, it’s not overcooked.

Here’s a simple reducer implementation:

fun reducer(intent: RecipeIntent): RecipeViewState {
    return when (intent) {
        is RecipeIntent.LoadRecipes -> {
            // Simulating a loading state
            RecipeViewState.Loading
        }
    }
}

Right now, it just shows the loading state, but don’t worry. We’ll add more to this later.

Step 4: Set Up the View

The View in MVI is pretty straightforward. It listens for state changes and updates the UI accordingly.

fun render(viewState: RecipeViewState) {
    when (viewState) {
        is RecipeViewState.Loading -> {
            // Show a loading spinner
            println("Loading recipes... 🍝")
        }
        is RecipeViewState.Success -> {
            // Display the list of recipes
            println("Here are all your pasta recipes: ${viewState.recipes}")
        }
        is RecipeViewState.Error -> {
            // Show an error message
            println("Oops! Something went wrong: ${viewState.message}")
        }
    }
}

The ViewModel

In an MVI architecture, the ViewModel plays a crucial role in coordinating everything. It handles intents, processes them, and emits the corresponding state to the view.

Here’s an example ViewModel:

class RecipeViewModel {

    private val state: MutableLiveData<RecipeViewState> = MutableLiveData()

    fun processIntent(intent: RecipeIntent) {
        state.value = reducer(intent)

        // Simulate a network call to fetch recipes
        GlobalScope.launch(Dispatchers.IO) {
            delay(2000) // Simulating delay for network call

            val recipes = listOf("Spaghetti Carbonara", "Penne Arrabbiata", "Fettuccine Alfredo")
            state.postValue(RecipeViewState.Success(recipes))
        }
    }

    fun getState(): LiveData<RecipeViewState> = state
}

• The processIntent function handles the user’s intent and updates the state.
• We simulate a network call using a coroutine, which fetches a list of pasta recipes (again, we love pasta).
• Finally, we update the view state to Success and send the list of recipes back to the view.

Bringing It All Together

Here’s how we put everything together:

fun main() {
    val viewModel = RecipeViewModel()

    // Simulate the user intent to load recipes
    viewModel.processIntent(RecipeIntent.LoadRecipes)

    // Observe state changes
    viewModel.getState().observeForever { viewState ->
        render(viewState)
    }

    // Let's give the network call some time to simulate fetching
    Thread.sleep(3000)
}

This will:

1. Trigger the LoadRecipes intent.
2. Show a loading spinner (or in our case, print “Loading recipes… 🍝”).
3. After two seconds (to simulate a network call), it will print a list of pasta recipes.

And there you have it! A simple MVI-based app that fetches and displays recipes, built with Kotlin.

Let’s Build One More App: A Simple To-Do List App

To get more clarity and grasp the concept, I’ll walk through a simple example of a To-Do List App using MVI in Kotlin.

Step 1: Define the State

First, let’s define the state of our to-do list:

sealed class ToDoState {
    object Loading : ToDoState()
    data class Data(val todos: List<String>) : ToDoState()
    data class Error(val message: String) : ToDoState()
}

Here, Loading represents the loading state, Data holds our list of todos, and Error represents any error states.

Step 2: Define Intents

Next, define the various user intents:

sealed class ToDoIntent {
    object LoadTodos : ToDoIntent()
    data class AddTodo(val task: String) : ToDoIntent()
    data class DeleteTodo(val task: String) : ToDoIntent()
}

These are actions the user can trigger, such as loading todos, adding a task, or deleting one.

Step 3: Create a Reducer

The reducer is the glue that connects the intent to the state. It transforms the current state based on the intent. Think of it as the brain of your MVI architecture.

fun reducer(currentState: ToDoState, intent: ToDoIntent): ToDoState {
    return when (intent) {
        is ToDoIntent.LoadTodos -> ToDoState.Loading
        is ToDoIntent.AddTodo -> {
            if (currentState is ToDoState.Data) {
                val updatedTodos = currentState.todos + intent.task
                ToDoState.Data(updatedTodos)
            } else {
                currentState
            }
        }
        is ToDoIntent.DeleteTodo -> {
            if (currentState is ToDoState.Data) {
                val updatedTodos = currentState.todos - intent.task
                ToDoState.Data(updatedTodos)
            } else {
                currentState
            }
        }
    }
}

The reducer function takes in the current state and an intent, and spits out a new state. Notice how it doesn’t modify the old state but instead returns a fresh one, keeping things immutable.

Step 4: View Implementation

Now, let’s create our View, which will render the state:

class ToDoView {
    fun render(state: ToDoState) {
        when (state) {
            is ToDoState.Loading -> println("Loading todos...")
            is ToDoState.Data -> println("Here are all your todos: ${state.todos}")
            is ToDoState.Error -> println("Oops! Error: ${state.message}")
        }
    }
}

The view listens to state changes and updates the UI accordingly.

Step 5: ViewModel (Managing Intents)

Finally, we need a ViewModel to handle incoming intents and manage state transitions.

class ToDoViewModel {
    private var currentState: ToDoState = ToDoState.Loading
    private val view = ToDoView()

    fun processIntent(intent: ToDoIntent) {
        currentState = reducer(currentState, intent)
        view.render(currentState)
    }
}

The ToDoViewModel takes the intent, runs it through the reducer to update the state, and then calls render() on the view to display the result.

Common Pitfalls And How to Avoid Them

MVI is awesome, but like any architectural pattern, it has its challenges. Here are a few common pitfalls and how to avoid them:

1. Overengineering the State

The whole idea of MVI is to simplify state management, but it’s easy to go overboard and make your states overly complex. Keep it simple! You don’t need a million different states—just enough to represent the core states of your app.

2. Complex Reducers

Reducers are great, but they can get messy if you try to handle too many edge cases inside them. Split reducers into smaller functions if they start becoming unmanageable.

3. Ignoring Performance

Immutable states are wonderful, but constantly recreating new states can be expensive if your app has complex data. Try using Kotlin’s data class copy() method to create efficient, shallow copies.

4. Not Testing Your Reducers

Reducers are pure functions—they take an input and always produce the same output. This makes them perfect candidates for unit testing. Don’t skimp on this; test your reducers to ensure they behave predictably!

Benefits of Using MVI Architecture

The MVI pattern offers several key advantages in modern Android development, especially for managing complex UI states:

1. Unidirectional Data Flow: By maintaining a clear, single direction for data to flow, MVI eliminates potential confusion about how and when the UI is updated. This makes the architecture easier to understand and debug.
2. Predictable UI State: With MVI, every possible state is predefined in the Model, and the state is immutable. This predictability means that the developer can always anticipate how the UI will react to different states, reducing the likelihood of UI inconsistencies.
3. Better Testability: Because each component in MVI (Model, View, and Intent) has clearly defined roles, it becomes much easier to test each in isolation. Unit tests can easily cover different user intents and state changes, making sure the application behaves as expected.
4. Scalability: As applications grow in complexity, maintaining a clean and organized codebase becomes essential. MVI’s clear separation of concerns (Intent, Model, View) ensures that the code remains maintainable and can be extended without introducing unintended side effects.
5. State Management: Managing UI state is notoriously challenging in Android apps, especially when dealing with screen rotations, background tasks, and asynchronous events. MVI’s approach to handling state ensures that the app’s state is always consistent and correct.

Conclusion 

MVI is a robust architecture that offers clear benefits when it comes to managing state, handling user interactions, and decoupling UI logic. The whole idea is to make your app’s state predictable, manageable, and testable — so no surprises when your app is running in production!

We built a simple apps today with MVI using Kotlin, and hopefully, you saw just how powerful and intuitive it can be. While MVI might take a bit more setup than other architectures, it provides a solid foundation for apps that need to scale and handle complex interactions.

MVI might not be the best choice for every app (especially simple ones), but for apps where state management and user interactions are complex, it’s a lifesaver.

Mobile app architecture is one of the most crucial aspects of app development. It’s like building a house; if your foundation is shaky, no matter how fancy the decorations are, the house will collapse eventually. In this blog post, We’ll discuss the mobile app architecture goals, with an emphasis on creating systems that are independent of frameworks, user interfaces (UI), databases, and external systems—while remaining easily testable.

Why Mobile App Architecture Matters

Imagine building a chair out of spaghetti noodles. Sure, it might hold up for a minute, but eventually, it’ll crumble.

Mobile app architecture is the thing that prevents our app from turning into a noodle chair.

A well-structured architecture gives our app:

• Scalability: It can handle more users, data, or features without falling apart.
• Maintainability: Updates, debugging, and improvements are easy to implement.
• Testability: You can test components in isolation, without worrying about dependencies like databases, APIs, or third-party services.
• Reusability: Common features can be reused across different apps or parts of the same app.
• Separation of Concerns: This keeps things neat and organized by dividing your code into separate components, each with a specific responsibility. (Nobody likes spaghetti code!)

Let’s break down how we can achieve these goals.

The Core Mobile App Architecture Goals

To achieve an optimal mobile application architecture, we developers should aim for the following goals:

• Independence from Frameworks
• Independence of User Interface (UI)
• Independence from Databases
• Independence from External Systems
• Independently Testable Components

Let’s look at them one by one.

Independence from Frameworks

You might be tempted to tightly couple your app’s architecture with a particular framework because, let’s face it, frameworks are super convenient. But frameworks are like fashion trends—today it’s skinny jeans, tomorrow, it’s wide-leg pants. Who knows what’s next? The key to a long-lasting mobile app architecture is to ensure it’s not overly dependent on any one framework.

When we say an architecture should be independent of frameworks, we mean the core functionality of the app shouldn’t rely on specific libraries or frameworks. Instead, frameworks should be viewed as tools that serve business needs. This independence allows business use cases to remain flexible and not restricted by the limitations of a particular library.

Why is this important?

• Frameworks can become outdated or obsolete, and replacing them could require rebuilding your entire app.
• Frameworks often impose restrictions or force you to structure your app in certain ways, limiting flexibility.

How to achieve framework independence?

Separate your business logic (the core functionality of your app) from the framework-specific code. Think of your app like a car: the engine (your business logic) should function independently of whether you’re using a stick shift or automatic transmission (the framework).

Example:

Imagine your app calculates taxes. The logic for calculating tax should reside in your business layer, completely isolated from how it’s presented (UI) or how the app communicates with the network.

class TaxCalculator {
    fun calculateTax(amount: Double, rate: Double): Double {
        return amount * rate
    }
}

This tax calculation has nothing to do with your UI framework (like SwiftUI for iOS or Jetpack Compose for Android). It can work anywhere because it’s self-contained.

Independence of User Interface (UI)

A well-designed architecture allows the UI to change independently from the rest of the system. This means the underlying business logic stays intact even if the presentation layer undergoes significant changes. For example, if you switch your app from an MVP (Model-View-Presenter) architecture to MVVM (Model-View-ViewModel), the business rules shouldn’t be affected.

Your app’s UI is like the icing on a cake, but the cake itself should taste good with or without the icing. By separating your app’s logic from the UI, you make your code more reusable and testable.

Why does UI independence matter?

• UIs tend to change more frequently than business logic.
• It allows you to test business logic without needing a polished front-end.
• You can reuse the same logic for different interfaces: mobile, web, voice, or even a smart toaster (yes, they exist!).

How to achieve UI independence?

Create a layer between your business logic and the UI, often called a “Presentation Layer” or “ViewModel.” This layer interacts with your business logic and converts it into something your UI can display.

Example:

Let’s revisit our TaxCalculator example. The UI should only handle displaying the tax result, not calculating it.

class TaxViewModel(private val calculator: TaxCalculator) {

    fun getTax(amount: Double, rate: Double): String {
        val tax = calculator.calculateTax(amount, rate)
        return "The calculated tax is: $tax"
    }
}

Here, the TaxViewModel is responsible for preparing the data for the UI. If your boss suddenly wants the tax displayed as an emoji (💰), you can change that in the TaxViewModel without touching the core calculation logic.

Independence from the Database

Databases are like refrigerators. They store all your precious data (your milk and leftovers). But just like you wouldn’t glue your fridge to the kitchen floor (hopefully!), you shouldn’t tie your business logic directly to a specific database. Someday you might want to switch from SQL to NoSQL or even a cloud storage solution.

Independence from databases is a crucial goal in mobile application architecture. Business logic should not be tightly coupled with the database technology, allowing developers to swap out database solutions with minimal friction. For instance, transitioning from SQLite to Realm or using Room ORM instead of a custom DAO layer should not affect the core business rules.

Why does database independence matter?

• Databases may change over time as your app scales or business requirements evolve.
• Separating logic from the database makes testing easier. You don’t need to run a real database to verify that your tax calculations work.

How to achieve database independence?

Use a repository pattern or an abstraction layer to hide the details of how data is stored and retrieved.

class TaxRepository(private val database: Database) {

    fun saveTaxRecord(record: TaxRecord) {
        database.insert(record)
    }

    fun fetchTaxRecords(): List<TaxRecord> {
        return database.queryAll()
    }
}

In this case, you can swap out the database object for a real database, a mock database, or even a file. Your business logic won’t care because it talks to the repository, not directly to the database.

Independence from External Systems

Apps often rely on external systems like APIs, cloud services, or third-party libraries. But like a bad internet connection, you can’t always rely on them to be there. If you make your app overly dependent on these systems, you’re setting yourself up for trouble.

Why does external system independence matter?

• External services can change, break, or be temporarily unavailable.
• If your app is tightly coupled to external systems, a single outage could bring your entire app down.

How to achieve external system independence?

The solution is to use abstractions and dependency injection. In layman’s terms, instead of calling the external system directly, create an interface or a contract that your app can use, and inject the actual implementation later.

Example:

interface TaxServiceInterface {
    fun getCurrentTaxRate(): Double
}

class ExternalTaxService : TaxServiceInterface {
    override fun getCurrentTaxRate(): Double {
        // Call to external API for tax rate
        return api.fetchTaxRate()
    }
}

Now your app only knows about TaxServiceInterface. Whether the data comes from an API or from a local file doesn’t matter. You could swap them without the app noticing a thing!

Testability

Testing is like flossing your teeth. Everyone knows they should do it, but too many skip it because it seems like extra effort. But when your app crashes in production, you’ll wish you’d written those tests.

Testability is crucial to ensure that your app functions correctly, especially when different components (like databases and APIs) aren’t playing nice. Independent and modular architecture makes it easier to test components in isolation.

How to achieve testability?

• Write small, independent functions that can be tested without requiring other parts of the app.
• Use mocks and stubs for databases, APIs, and other external systems.
• Write unit tests for business logic, integration tests for how components work together, and UI tests for checking the user interface.

Example:

class TaxCalculatorTest {

    @Test
    fun testCalculateTax() {
        val calculator = TaxCalculator()
        val result = calculator.calculateTax(100.0, 0.05)
        assertEquals(5.0, result, 0.0)  // expected value, actual value, delta
    }
}

In this test, you’re only testing the tax calculation logic. You don’t need to worry about the UI, database, or external systems, because they’re decoupled.

Note: 0.0 is the delta, which represents the tolerance level for comparing floating-point values, as floating-point arithmetic can introduce small precision errors. The delta parameter in assertEquals is used for comparing floating-point numbers (such as Double in Kotlin) to account for minor precision differences that may occur during calculations. This is a common practice in testing frameworks like JUnit.

Before wrapping it all up, let’s build a sample tax calculator app with these architectural goals in mind.

Building a Sample Tax Calculator App

Now that we’ve established the architectural goals, let’s create a simple tax calculator app in Kotlin. We’ll follow a modular approach, ensuring independence from frameworks, UI, databases, and external systems, while also maintaining testability.

Mobile App Architecture for Tax Calculation

We’ll build the app using the following layers:

1. Domain Layer – Tax calculation logic.
2. Data Layer – Data sources for tax rates, income brackets, etc.
3. Presentation Layer – The ViewModel that communicates between the domain and UI.

Let’s dive into each layer,

Domain Layer: Tax Calculation Logic

The Domain Layer encapsulates the core business logic of the application, specifically the tax calculation logic. It operates independently of any frameworks, user interfaces, databases, or external systems, ensuring a clear separation of concerns.

Tax Calculation Use Case

// Domain Layer
interface CalculateTaxUseCase {
    fun execute(income: Double): TaxResult
}

class CalculateTaxUseCaseImpl(
    private val taxRepository: TaxRepository,
    private val taxRuleEngine: TaxRuleEngine // To apply tax rules
) : CalculateTaxUseCase {
    override fun execute(income: Double): TaxResult {
        val taxRates = taxRepository.getTaxRates() // Fetch tax rates
        return taxRuleEngine.calculateTax(income, taxRates)
    }
}

• Independence from Frameworks: The implementation of CalculateTaxUseCaseImpl does not rely on any specific framework, allowing it to be easily swapped or modified without impacting the overall architecture.
• Independence of User Interface (UI): This layer is agnostic to the UI, focusing solely on business logic and allowing the UI layer to interact with it without any coupling.

Data Layer: Fetching Tax Rates

The Data Layer is responsible for providing the necessary data (like tax rates) to the domain layer without any dependencies on how that data is sourced.

// Data Layer
interface TaxRepository {
    fun getTaxRates(): List<TaxRate>
}

// Implementation that fetches from a remote source
class RemoteTaxRepository(private val apiService: ApiService) : TaxRepository {
    override fun getTaxRates(): List<TaxRate> {
        return apiService.fetchTaxRates() // Fetch from API
    }
}

// Implementation that fetches from a local database
class LocalTaxRepository(private val taxDao: TaxDao) : TaxRepository {
    override fun getTaxRates(): List<TaxRate> {
        return taxDao.getAllTaxRates() // Fetch from local database
    }
}

• Independence from Databases: The TaxRepository interface allows for different implementations (remote or local) without the domain layer needing to know the source of the data. This separation facilitates future changes, such as switching databases or APIs, without affecting business logic.

Tax Rule Engine: Applying Tax Rules

The Tax Rule Engine handles the application of tax rules based on the user’s income and tax rates, maintaining a clear focus on the calculation itself.

// Domain Layer - Tax Rule Engine
class TaxRuleEngine {

    fun calculateTax(income: Double, taxRates: List<TaxRate>): TaxResult {
        var totalTax = 0.0

        for (rate in taxRates) {
            if (income >= rate.bracketStart && income <= rate.bracketEnd) {
                totalTax += (income - rate.bracketStart) * rate.rate
            }
        }

        return TaxResult(income, totalTax)
    }
}

data class TaxRate(val bracketStart: Double, val bracketEnd: Double, val rate: Double)
data class TaxResult(val income: Double, val totalTax: Double)

• Independence from External Systems: The logic in the TaxRuleEngine does not depend on external systems or how tax data is retrieved. It focuses purely on calculating taxes based on the given rates.
• Independence of External Systems (Somewhat Confusing): A robust architecture should also be agnostic to the interfaces and contracts of external systems. This means that any external services, whether APIs, databases, or third-party libraries, should be integrated through adapters. This modular approach ensures that external systems can be swapped out without affecting the business logic.

For example, if an application initially integrates with a REST API, later switching to a GraphQL service should require minimal changes to the core application logic. Here’s how you can design a simple adapter for an external service in Kotlin:

// External Service Interface
interface UserService {
    fun fetchUser(userId: Int): User
}

// REST API Implementation
class RestUserService : UserService {
    override fun fetchUser(userId: Int): User {
        // Logic to fetch user from REST API
        return User(userId, "amol pawar") // Dummy data for illustration
    }
}

// GraphQL Implementation
class GraphQLUserService : UserService {
    override fun fetchUser(userId: Int): User {
        // Logic to fetch user from GraphQL API
        return User(userId, "akshay pawal") // Dummy data for illustration
    }
}

// Usage
fun getUser(userService: UserService, userId: Int): User {
    return userService.fetchUser(userId)
}

In this example, we can easily switch between different implementations of UserService without changing the business logic that consumes it.

In our tax calculation app case, we can apply this principle by allowing for flexible data source selection. Your application can seamlessly switch between different data providers without impacting the overall architecture.

Switching between data sources (local vs. remote):

// Switching between data sources (local vs remote)
val taxRepository: TaxRepository = if (useLocalData) {
    LocalTaxRepository(localDatabase.taxDao())
} else {
    RemoteTaxRepository(apiService)
}

Independence from Databases and External Systems: The decision on which data source to use is made at runtime, ensuring that the business logic remains unaffected regardless of the data source configuration.

Presentation Layer: ViewModel for Tax Calculation

The Presentation Layer interacts with the domain layer to provide results to the UI while remaining independent of the specific UI implementation.

// Presentation Layer
class TaxViewModel(private val calculateTaxUseCase: CalculateTaxUseCase) : ViewModel() {

    private val _taxResult = MutableLiveData<TaxResult>()
    val taxResult: LiveData<TaxResult> get() = _taxResult

    fun calculateTax(income: Double) {
        _taxResult.value = calculateTaxUseCase.execute(income)
    }
}

• Independently Testable Components: The TaxViewModel can be easily tested in isolation by providing a mock implementation of CalculateTaxUseCase, allowing for focused unit tests without relying on actual data sources or UI components.

Testing the Architecture

The architecture promotes independently testable components by isolating each layer’s functionality. For example, you can test the CalculateTaxUseCase using a mock TaxRepository, ensuring that you can validate the tax calculation logic without relying on actual data fetching.

class CalculateTaxUseCaseTest {

    private val mockTaxRepository = mock(TaxRepository::class.java)
    private val taxRuleEngine = TaxRuleEngine()
    private val calculateTaxUseCase = CalculateTaxUseCaseImpl(mockTaxRepository, taxRuleEngine)

    @Test
    fun `should calculate correct tax for income`() {
        // Setup tax rates
        val taxRates = listOf(
            TaxRate(0.0, 10000.0, 0.1), // 10% for income from 0 to 10,000
            TaxRate(10000.0, 20000.0, 0.2) // 20% for income from 10,001 to 20,000
        )
        
        // Mock the repository to return the defined tax rates
        `when`(mockTaxRepository.getTaxRates()).thenReturn(taxRates)

        // Calculate tax for an income of 15,000
        val result = calculateTaxUseCase.execute(15000.0)

        // Assert the total tax is correctly calculated
        // For $15,000, tax should be:
        // 10% on the first $10,000 = $1,000
        // 20% on the next $5,000 = $1,000
        // Total = $1,000 + $1,000 = $2,000
        assertEquals(2000.0, result.totalTax, 0.0)
    }
}

This architecture not only adheres to the specified goals but also provides a clear structure for future enhancements and testing.

Conclusion

Mobile app architecture is like building a castle in the sky—you need to make sure your app’s components are well-structured, independent, and testable. By following the goals outlined here:

1. Framework independence means you can switch frameworks without rewriting everything.
2. UI independence ensures your business logic can work on any platform.
3. Database independence lets you change how you store data without affecting how you process it.
4. External system independence allows for flexibility in changing third-party services.
5. Testability guarantees your app doesn’t break when you add new features.

Remember: A good app architecture is invisible when done right, but painfully obvious when done wrong. So, avoid the spaghetti code, keep your components decoupled, and, of course, floss regularly! 😄

So, you’ve just sat down to build an Android app, and naturally, you want to execute some background tasks. Perhaps you’re thinking, ‘Should I use a Thread? Maybe AsyncTask? No, wait—that’s deprecated!’ Don’t worry, we’ve all been there. In the wild, vast world of Android development, managing background tasks is like trying to control a herd of cats—tricky, unpredictable, and occasionally chaotic. Fortunately, Google swoops in with a superhero named WorkManager, helping you schedule and execute tasks reliably, even when the app isn’t running. Think of it as your trusty sidekick for all background work.

In this blog, we’re going to dive deep into WorkManager, breaking down the concepts, exploring its features, discussing its usage, and providing detailed code explanations.

What is WorkManager?

Imagine you have a task that doesn’t need to happen right now, but you absolutely need to ensure it gets done eventually, even if the app is killed or the device restarts. Enter WorkManager, the reliable superhero of background processing.

In simple words, WorkManager is an API in Jetpack that allows you to schedule deferrable, guaranteed background tasks. Unlike a Thread or a Service, it ensures your tasks run even if the user quits the app, reboots the phone, or encounters unexpected interruptions. Whether you’re syncing data with a server, processing images, or sending logs, WorkManager can handle all that—and more—like a pro.

When Should We Use WorkManager?

Not all heroes wear capes, and not all background tasks need WorkManager. It’s ideal for tasks that:

• Need guaranteed execution (even after the app is closed or the device reboots).
• Should respect system health (low battery, Doze mode, etc.).
• Require deferral or scheduling (to run at a certain time or periodically).

Consider using WorkManager when:

• You need guaranteed execution (even after the app is closed or the device reboots).
• The task doesn’t need to run instantly but should be completed eventually.
• Tasks need to survive configuration changes, app shutdowns, or reboots.

Think: syncing data, uploading logs, periodic background tasks, etc.

When NOT to use WorkManager:

• If your task is immediate and must run in real time, use Thread or Coroutines instead. WorkManager is more like your chilled-out buddy who’ll get the work done eventually—but on its terms.

Key Components of WorkManager

Before we dive into the code, let’s get to know the three main players:

• WorkRequest: Defines the task you want to run. This is like giving WorkManager its to-do list.
• Worker: The actual worker that does the background task. You create a class that extends Worker to define what you want to do in the background.
• WorkManager: The manager that schedules and runs the tasks.

Setting Up WorkManager: Let’s Get Our Hands Dirty

Here’s how you can set up WorkManager in Android.

First, add the dependency to your build.gradle or build.gradle.kts file:

dependencies {
    implementation "androidx.work:work-runtime:2.7.1" // or the latest version
}

Step 1: Define the Worker

A Worker class does the actual task you want to perform. It runs on a background thread, so no need to worry about blocking the UI. Here’s a sample Worker that logs “Work is being done” to the console.

class MyWorker(appContext: Context, workerParams: WorkerParameters):
        Worker(appContext, workerParams) {

    override fun doWork(): Result {
        // Do the task here (this runs in the background)
        Log.d("MyWorker", "Work is being done!")

        // Return success or failure based on the result of your task
        return Result.success()
    }
}

Step 2: Create a WorkRequest

Next, you create a WorkRequest that tells WorkManager what work to schedule. Here’s how you create a simple OneTimeWorkRequest.

val workRequest = OneTimeWorkRequestBuilder<MyWorker>().build()

Step 3: Enqueue the Work

Finally, pass that work to WorkManager for execution. This is like handing your to-do list to the boss.

WorkManager.getInstance(applicationContext).enqueue(workRequest)

And that’s it! Your background task is now running. WorkManager is making sure everything runs smoothly, even if you’re taking a nap or binge-watching Netflix.

A Simple Use Case Example

Let’s say you want to upload some user data in the background. Sounds fancy, right? Here’s how you can do that with WorkManager.

Step 1: Adding the dependency

First things first, add this to your build.gradle file:

implementation "androidx.work:work-runtime-ktx:2.7.1" //use latest version

Step 2: Creating a Worker (Meet the Hero)

The Worker class is where the magic happens. It’s where you define what your task is supposed to do. Let’s create a simple worker that simulates uploading user data (aka…prints logs because it’s fun).

class UploadWorker(context: Context, params: WorkerParameters) : Worker(context, params) {

    override fun doWork(): Result {
        // Imagine uploading data here
        Log.d("UploadWorker", "Uploading user data...")

        // Task finished successfully, tell WorkManager
        return Result.success()
    }
}

Here, the doWork() method is where you perform your background task. If the task completes successfully, we return Result.success() like a proud coder. But, if something goes wrong (like, let’s say, the Internet decides to take a break), you can return Result.retry() or Result.failure().

Step 3: Scheduling Your Work (Set It and Forget It)

Now that you have your Worker, it’s time to schedule that bad boy! WorkManager takes care of the scheduling for you.

val uploadRequest = OneTimeWorkRequestBuilder<UploadWorker>()
    .build()

WorkManager.getInstance(context)
    .enqueue(uploadRequest)

In this example, we’re using a OneTimeWorkRequest. This means we want to run the task just once, thank you very much. After all, how many times do we really need to upload that same file?

What About Recurring Tasks? (Because Background Tasks Love Routine)

What if your background task needs to run periodically, like syncing data every hour or cleaning out unused files daily? That’s where PeriodicWorkRequest comes into play.

val periodicSyncRequest = PeriodicWorkRequestBuilder<UploadWorker>(1, TimeUnit.HOURS)
    .build()

WorkManager.getInstance(context)
    .enqueue(periodicSyncRequest)

Here, we’re asking WorkManager to run the task every hour. Of course, WorkManager doesn’t promise exactly every hour on the dot (it’s not that obsessive), but it’ll happen at some point within that hour.

Types of WorkRequests: One Time vs. Periodic

In our previous discussion, you may have noticed I mentioned a one-time and periodic request. WorkManager offers two types of tasks:

1. OneTimeWorkRequest: For tasks that need to run just once (like uploading logs or cleaning the fridge once in a blue moon).

val oneTimeWorkRequest = OneTimeWorkRequestBuilder<MyWorker>().build()

2. PeriodicWorkRequest: For tasks that need to be repeated (like syncing data every day or watering your plants every week—unless you’re that neglectful plant parent).

val periodicWorkRequest = PeriodicWorkRequestBuilder<MyWorker>(15, TimeUnit.MINUTES).build()

Tip: Periodic work must have a minimum interval of 15 minutes (Android’s way of ensuring your app doesn’t become a battery vampire). If your app needs to perform tasks more frequently than every 15 minutes, you might consider using other mechanisms, such as alarms or foreground services. However, be mindful of their potential impact on user experience and battery consumption.

Handling Success and Failure

Just like life, not all tasks go according to plan. Sometimes, things fail. But don’t worry—WorkManager has your back. You can return Result.success(), Result.failure(), or Result.retry() based on the outcome of your task.

override fun doWork(): Result {
    return try {
        // Do your work here
        Result.success()
    } catch (e: Exception) {
        Result.retry()  // Retry on failure
    }
}

Retrying failed tasks is like giving someone a second chance—sometimes, they just need a little more time!

Handling Input and Output

Sometimes, your Worker needs some data to do its job (it’s not psychic, unfortunately). You can pass input data when scheduling the work.

val data = workDataOf("userId" to 1234)

val uploadRequest = OneTimeWorkRequestBuilder<UploadWorker>()
    .setInputData(data)
    .build()

WorkManager.getInstance(context).enqueue(uploadRequest)

In your Worker, you can access this input like so:

override fun doWork(): Result {
    val userId = inputData.getInt("userId", -1)
    Log.d("UploadWorker", "Uploading data for user: $userId")
    
    // Do the work...
    return Result.success()
}

And if your Worker finishes and wants to send a little message back (like a good teammate), it can return output data.

override fun doWork(): Result {
    val outputData = workDataOf("uploadSuccess" to true)
    
    return Result.success(outputData)
}

Constraints (Because Background Tasks Can Be Picky)

Sometimes, your task shouldn’t run unless certain conditions are met. Like, you don’t want to upload files when the device is on low battery or when there’s no network. Thankfully, WorkManager lets you set constraints.

val constraints = Constraints.Builder()
    .setRequiredNetworkType(NetworkType.CONNECTED)
    .setRequiresBatteryNotLow(true)
    .build()

val uploadRequest = OneTimeWorkRequestBuilder<UploadWorker>()
    .setConstraints(constraints)
    .build()

Now your upload will only happen when the network is connected, and the device has enough battery. WorkManager is considerate like that.

Unique Work: One Worker to Rule Them All

Sometimes, you don’t want duplicate tasks running (imagine sending multiple notifications for the same event—annoying, right?). WorkManager lets you enforce unique work using enqueueUniqueWork.

WorkManager.getInstance(applicationContext)
    .enqueueUniqueWork("UniqueWork", ExistingWorkPolicy.REPLACE, workRequest)

This ensures that only one instance of your task is running at any given time.

Chaining Work Requests (Because One Task Just Isn’t Enough)

What if you have a series of tasks, like uploading data, followed by cleaning up files? You can chain your tasks using WorkManager like an overly ambitious to-do list.

val uploadWork = OneTimeWorkRequestBuilder<UploadWorker>().build()
val cleanupWork = OneTimeWorkRequestBuilder<CleanupWorker>().build()

WorkManager.getInstance(context)
    .beginWith(uploadWork)
    .then(cleanupWork)
    .enqueue()

Now, UploadWorker will do its thing, and once it’s done, CleanupWorker will jump into action. WorkManager makes sure things run in the order you specify, like a well-behaved assistant.

Let’s take a look at another use case: Chaining Tasks – WorkManager’s Superpower.

Imagine you want to upload a photo, resize it, and then upload the resized version. With WorkManager, you can chain these tasks together, ensuring they happen in the correct order.

val resizeWork = OneTimeWorkRequestBuilder<ResizeWorker>().build()
val uploadWork = OneTimeWorkRequestBuilder<UploadWorker>().build()

WorkManager.getInstance(applicationContext)
    .beginWith(resizeWork)  // First, resize the image
    .then(uploadWork)       // Then, upload the resized image
    .enqueue()              // Start the chain

It’s like a relay race but with background tasks. Once the resize worker finishes, it passes the baton to the upload worker. Teamwork makes the dream work!

Monitoring Work Status (Because Micromanagement is Fun)

Want to know if your work is done or if it failed miserably? WorkManager has you covered. You can observe the status of your work like a proud parent watching over their kid at a school play.

WorkManager.getInstance(context)
    .getWorkInfoByIdLiveData(uploadRequest.id)
    .observe(this, Observer { workInfo ->
        if (workInfo != null && workInfo.state.isFinished) {
            Log.d("WorkManager", "Work finished!")
        }
    })

You can also check if it’s still running, if it failed, or if it’s in the process of retrying. It’s like having real-time updates without the annoying notifications!

Best Practices for WorkManager

• Use Constraints Wisely: Don’t run heavy tasks when the user is on low battery or no internet. Add constraints like network availability or charging state.

val constraints = Constraints.Builder()
    .setRequiresCharging(true)  // Only run when charging
    .setRequiredNetworkType(NetworkType.CONNECTED)  // Only run when connected to the internet
    .build()

• Avoid Long Running Tasks: WorkManager is not designed for super long tasks. Offload heavy lifting to server-side APIs when possible.
• Keep the Worker Light: The heavier the worker, the more the system will dislike your app, especially in low-memory scenarios.

Conclusion: Why WorkManager is Your New BFF

WorkManager is like that dependable friend who handles everything in the background, even when you’re not paying attention. It’s a powerful tool that simplifies background work, ensures system health, and offers you flexibility. Plus, with features like task chaining and unique work, it’s the ultimate multitool for background processing in Android.

And hey, whether you’re dealing with syncing, uploading, or scheduling—WorkManager will be there for you. Remember, background tasks are like coffee—sometimes you need them now, sometimes later, but they always make everything better when done right.