Kotlin

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.