So you did this:

targetSdk = 36

Build passed.
App opened.
Before you celebrate — pause.

Android 16 changes rules, and this is the checklist you should go through before releasing.

1. Check If Your App Breaks on Big Screens

Android 16 is serious about tablets and foldables.

Check this

• Does your app stretch weirdly?
• Any UI overlapping?
• Locked orientation ignored?

What to do

• Use flexible layouts
• Test on tablet/foldable emulator
• Fix screens that assume phone size

If it looks bad, Android 16 won’t hide it anymore.

2. Check Back Navigation Everywhere

Back navigation changes are one of the most common surprises.

Check this

• Back button behavior on every screen
• Swipe-back gesture
• Dialog and bottom-sheet dismissal

Fix

• Remove custom back logic if not needed
• Use OnBackPressedDispatcher
• Let system handle back when possible

If back feels wrong, users notice instantly.

3. Re-Test All Permission Flows

Permissions often break silently.

Check this

• Photo access
• Location usage
• Local network access

What to do

• Test on fresh install
• Don’t assume old permissions still work
• Remove permissions you don’t need

Clean permission flow = fewer Play Store issues.

4. Review Your AndroidManifest

Target 36 makes the system less forgiving.

Check this

• exported components
• Unused permissions
• Old intent filters

Tip
If something is not required, remove it.
Android 16 rewards clean manifests.

5. Look for Deprecated Stuff

Old code finally starts hurting.

Check

• Deprecated layout attributes
• Old UI flags
• Legacy APIs

If Android warns you — don’t ignore it this time 😄

6. Test App Update Flow (Not Just Fresh Install)

Many bugs appear only during updates.

Check

• App update from older version
• Data migration
• Feature flags

Fresh install working doesn’t mean upgrade works.

7. Check Notifications & Background Work

Background rules keep getting tighter.

Check

• Notifications showing correctly
• Long-running tasks
• WorkManager / foreground services

If something stops in background, targetSdk is usually the reason.

8. Optional: Look at What’s New

Not required, but useful:

• Progress-based notifications
• Better haptics
• Performance improvements

Use only what makes sense for your app.

Final Thought

Setting:

targetSdk = 36

is easy.

Making sure your app behaves well after that is the real work.

Run this checklist once, and Android 16 won’t surprise you later 😉

If we want to run a task in parallel, we create a new thread that runs separately from the main thread. For the main thread, there’s a Looper and a message queue. So, any task we perform on the main thread gets added to the queue and is then gets handover to main thread using Looper.

Now, if we run a long-running task on the main thread, it will be blocked. So, we move such tasks to a background thread.

Threads in Java vs Coroutines

In Java, there’s a limit to how many threads we can create per process. If a thread has a task that is waiting for some data from the network or is paused, it can’t do another task; for that, a new thread must be created.

In coroutines, however, when a task is waiting, another coroutine can use that same thread first coroutine was using. Once the first task is ready, it resumes on the same thread. Because coroutines run on threads and allow thread reuse, they are called lightweight.

Creating a thread in Java takes around 2 MB of memory. Coroutines are cheaper because multiple coroutines can share the same thread.

The term “coroutine” comes from cooperative routines — tasks that cooperate with each other. Kotlin developers built this framework to efficiently manage concurrency using threads.

For example:

If a thread has task1, which is waiting for a network response, and task2 comes in, instead of creating a new thread, the existing thread is reused. If no free thread is available, a new one is taken from the thread pool.

Coroutine Basics: Context, Scope, and Dispatcher

1. Scope defines the lifetime of a coroutine — which scope it’s attached to, e.g., MainScope, CoroutineScope, GlobalScope, viewModelScop, lifecycleScope.
2. Context defines the thread the coroutine will use, e.g., Dispatchers.IO, Dispatchers.Main, or Dispatchers.Default.

To create a custom coroutine:

CoroutineScope(Dispatchers.IO).launch {
    // your task here
}

Suspend Functions

The suspend keyword indicates that this particular task can be suspended at any point. That means it can wait for output, or it can pause so that other tasks can do their work using yield().

Launch vs Async

These are methods used to run tasks in a coroutine:

• launch returns a Job, which we can use to start, join, or cancel the task. It is fire-and-forget.
• async returns a Deferred<T>, which we can use to get the result of the task. We use await() to wait for the result.

In launch, we can use join() to wait for the task to finish.

Switching Context with withContext

Using the withContext suspend function, we can switch the context of a running coroutine. For example, one part can run on one thread, and another part can run on a different thread:

scope.launch{
  withContext(Dispatchers.IO) {
      // network operation
  }
  withContext(Dispatchers.Main) {
      // update UI, after network operation is done
  }
}

RunBlocking

runBlocking is used to run code in a coroutine and block the current thread until it completes:

fun main() = runBlocking {
    launch {
        delay(1000L)
        println("World")
    }
    println("Hello")
}

In this example, “Hello” prints first, then “World” prints after the coroutine finishes.

Coroutines provide an efficient, lightweight way to handle concurrency in Kotlin, reusing threads, avoiding heavy memory overhead, and simplifying asynchronous programming. By understanding scopes, contexts, dispatchers, suspend functions, and the difference between launch and async, we can harness the full power of coroutines in Kotlin.

Google has quietly introduced one of the most impactful low-level changes in Android in years: support for 16 KB memory pages. Starting with Android 15, devices can ship with larger memory pages, and by November 2025, all apps on Google Play targeting Android 15+ must support them.

This change isn’t just a technical curiosity — it directly translates into faster app launches, better battery usage, and quicker camera/system boot times. Let’s break down what’s happening, why it matters, and what developers need to do.

🔹 What Are Memory Pages?

Modern operating systems don’t manage RAM byte by byte. Instead, they split memory into fixed-size chunks called pages.

• On most systems, the page size has been 4 KB (4096 bytes).
• With this change, Android now supports 16 KB pages (16,384 bytes).

When an app requests memory, the OS allocates it in units of pages. Virtual memory addresses are mapped to physical addresses via these pages.

👉 Key takeaway: On Android 15+, memory can now be managed in bigger chunks (16 KB each) instead of 4 KB.

🔹 Why Does Page Size Matter?

Page size affects performance at multiple levels:

1. Page faults — If a memory page isn’t loaded, the OS must fetch it. More/smaller pages = more faults.
2. Page tables — Each page needs an entry. More pages = bigger tables and more CPU overhead.
3. TLB (Translation Lookaside Buffer) — CPU cache for page mappings. Fewer pages = fewer entries = fewer misses.

Smaller pages reduce wasted space but increase overhead. Larger pages reduce overhead but risk more internal fragmentation. Android’s move to 16 KB is a sweet spot for modern workloads.

👉 This optimization only impacts native code (NDK)

the parts of your app written in C or C++ and compiled into .so libraries.
If your app is entirely in Java or Kotlin, you don’t need to worry — there’s no impact.

When You Need to Care

You should pay attention if your app:

• Uses NDK directly with C/C++ code.
• Depends on third-party SDKs that include .so libraries (native code).

What You Should Do

To make sure your app runs smoothly across devices (both 4 KB and 16 KB page sizes):

• ✅ Use the latest NDK version that supports 16 KB pages.
• ✅ If you rely on prebuilt native SDKs, update them to versions that support 16 KB pages.
• ✅ Don’t hardcode the page size. Instead, use sysconf(_SC_PAGESIZE) to fetch it dynamically at runtime.
• ✅ Always test on both 4 KB and 16 KB devices to confirm stability and performance.

🔹 Performance Gains: How 16 KB Pages Help

1. Faster App Launches

When an app starts, the system loads lots of code and libraries. With 16 KB pages:

• Fewer page faults
• Fewer page table entries
• Less kernel overhead

👉 Google measured up to 30% faster launches (3.16% average).

2. Better Battery Usage

• Fewer TLB misses → less CPU time wasted
• Smaller page tables → lighter kernel work
• Bigger chunks from storage → more efficient I/O

👉 Saves 4–6% battery in common scenarios.

3. Quicker Camera & System Boot

• Camera: Big native libraries (image processing, ML models) load faster.
• Boot: Fewer page faults across system services.

👉 Results in ~0.8s faster boot and noticeably quicker camera startup.

🔹 Example: 4 KB vs 16 KB Pages

Let’s say we load a 64 KB library.

With 4 KB pages:

• Needs 64 ÷ 4 = 16 pages
• 16 page faults, 16 entries, 16 TLB slots

[Page1][Page2][Page3]…[Page16]

With 16 KB pages:

• Needs 64 ÷ 16 = 4 pages
• 4 page faults, 4 entries, 4 TLB slots

[Page1……………][Page2……………][Page3……………][Page4……………]

👉 Fewer pages = less overhead = faster.

🔹 Developer Impact

1. Native Code Compatibility

If you use the NDK (C/C++ libraries), your binaries must support 16 KB alignment.

• Use NDK r28+ and AGP 8.5.1+ (enabled by default)
• Or add linker flags manually: -Wl,-z,max-page-size=16384
• Avoid hardcoding PAGE_SIZE == 4096. Instead use: sysconf(_SC_PAGESIZE);

2. Testing Tools

• Android Studio: Emulators with 16 KB page size (ARM64 + x86_64)
• Pixel Devices: Toggle in Developer Options (Android 15 QPR1+)
• Samsung Remote Test Lab: Cloud devices with 16 KB enabled

3. Play Store Deadline

• From Nov 1, 2025, all new apps and updates targeting Android 15+ must support 16 KB pages.

🔹 Why Not Go Even Bigger (64 KB, 2 MB)?

• 64 KB / 2 MB pages → even fewer faults, but much higher internal fragmentation.
• Many Android apps allocate small objects; wasting 60 KB every time would hurt memory efficiency.
• 16 KB is a balance: fewer faults without too much waste.

✅ Takeaway

The move to 16 KB memory pages is one of those under-the-hood changes that end users will feel without ever knowing why:

• Apps launch faster
• Battery lasts longer
• Cameras and devices boot quicker

For developers, the message is clear:

• Update your toolchains
• Test on 16 KB devices/emulators
• Don’t assume 4 KB pages anymore

Android is evolving for performance, and 16 KB pages are a big step in that journey.

💡 If you’re an Android developer working with native code, now’s the time to future-proof your apps for the 16 KB era.

For years, EncryptedSharedPreferences (ESP) was the go-to solution for securely storing small pieces of sensitive data (tokens, user IDs, session keys) on Android. It provided an easy API, handled key management behind the scenes, and used AES encryption under the hood.

But if you’ve checked the AndroidX release notes recently, you might have noticed:

👉 EncryptedSharedPreferences (and its sibling EncryptedFile) are now deprecated in the latest Security Cryptolibrary.

So what does that mean for your app? And what should you use instead? Let’s break it down.

🚨 Why is EncryptedSharedPreferences Deprecated?

• Google is moving away from SharedPreferences in general.
• DataStore is now the recommended replacement for preferences and key-value storage.
• For encryption, newer libraries like App Security (Crypto 1.1.0+) give more flexible, future-proof primitives.

ESP was convenient, but it had limitations:

• Heavy reliance on legacy SharedPreferences APIs.
• Limited flexibility for customizing cryptography.
• Not the best choice for modern coroutine/Flow-based apps.

✅ What to Use Instead

1. Jetpack DataStore (Recommended)

Google now recommends DataStore over SharedPreferences.

• Uses Kotlin coroutines + Flow.
• Type-safe (with Proto DataStore).
• Async and non-blocking.

➡️ But DataStore by itself is not encrypted. If you’re storing sensitive data, you need to encrypt values before writing.

2. Tink (Google’s Cryptography Library)

Tink is a cross-platform, production-ready cryptography library from Google.

• Supports AES-GCM, AES-SIV, and more.
• Built-in key rotation.
• Easy integration with Android’s KeyStore.

You can combine Tink + DataStore:

val keysetHandle = AndroidKeysetManager.Builder()
    .withSharedPref(context, "master_keyset", "my_pref")
    .withKeyTemplate(AesGcmKeyManager.aes256GcmTemplate())
    .withMasterKeyUri("android-keystore://master_key")
    .build()
    .keysetHandle

val aead = keysetHandle.getPrimitive(Aead::class.java)
val ciphertext = aead.encrypt("my_secret".toByteArray(), null)
val plaintext = aead.decrypt(ciphertext, null)

3. Encrypted DataStore (Custom Implementation)

Since there’s no official EncryptedDataStore (yet), you can build a wrapper:

• Use Tink or Crypto for encryption.
• Store values in PreferencesDataStore.
• Expose them as safe getters/setters.

Example wrapper:

class SecureStorage(private val context: Context) {

    private val Context.dataStore by preferencesDataStore("secure_store")

    private val KEY_ACCESS_TOKEN = stringPreferencesKey("access_token")

    suspend fun saveToken(token: String) {
        context.dataStore.edit { prefs ->
            prefs[KEY_ACCESS_TOKEN] = encrypt(token)
            // Same normal data store but save with Encryption enabled
        }
    }

    // Retrove the value after decryption
    val accessToken: Flow<String?> = context.dataStore.data
        .map { prefs -> prefs[KEY_ACCESS_TOKEN]?.let { decrypt(it) } }

}

⚖ Which One Should You Pick?

• For new apps: Use DataStore + Tink/Encryption.
• For existing ESP apps: Don’t panic. ESP still works, but migration is wise if you’re future-proofing.
• For enterprise/finance apps: Stick with Tink — it’s maintained by Google Security engineers.

Takeaway

EncryptedSharedPreferences served us well, but it’s time to move forward.
The future of secure local storage on Android is:

👉 DataStore for persistence
👉 Tink (or Security Crypto) for encryption
👉 Android Keystore for key protection

By combining these, you get a modern, coroutine-friendly, and secure solution that will be supported long-term.

💡 Pro tip: If you’re migrating from ESP → DataStore, consider writing a small migration layer that reads old ESP values, decrypts them, and saves them into your new DataStore. That way, users don’t lose their tokens or session.

Android 16 is around the corner, and Google just slipped in a change that might break a few assumptions:

Your app can no longer force portrait mode on large-screen devices by default.

Yep. Tablets, foldables, Chromebooks — they’re done being treated like oversized phones.
Let’s talk about why Google did this, what it means, and what else is coming soon (spoiler: Play Store targeting deadlines).

🤦 Why this happened

Locking apps to portrait on big screens often leads to awkward UX:

• Users dock their tablet or attach a keyboard — and your app stubbornly sticks to portrait.
• Huge black bars appear, turning your UI into a tiny island in the middle.
• Foldables and Chromebooks feel especially broken.

Bottom line: users expect large screens to respect how they hold (or fold) the device. And Google wants us to build for that.

🧰 What to do instead

✅ Build responsive layouts using ConstraintLayout or Jetpack Compose.
✅ Use WindowSizeClass or check orientation to adapt content dynamically.
✅ Handle onConfigurationChanged properly — or better yet, let the system re-create the activity.
✅ If your app really needs portrait (e.g., camera, AR), explain why in your Play Console declarations.

Quick Compose idea:

val config = LocalConfiguration.current
if (config.orientation == Configuration.ORIENTATION_PORTRAIT) {
    // show vertical layout
} else {
    // show horizontal or two-pane layout
}

😂 What not to do

• Write hacks to force orientation — the system will quietly ignore them.
• Assume tablets are rare — they’re not, and foldables are everywhere now.

📦 Play Store deadlines you can’t ignore

Besides portrait lock changes, here’s what’s coming:

August 31, 2025:

• New apps & app updates must target API level 35 (Android 15).
• Existing apps that already target API 34 (Android 14):
• Can stay on the store and remain discoverable — even on Android 15 devices — unless Google updates the policy.

So if you’re stuck on older SDKs, it’s time to plan an upgrade.

🗓 And Android 16?

Right now, it’s in beta.
Google’s pattern suggests: around August–September 2026, targeting API 36 (Android 16) will become mandatory for new apps & updates.

🏆 Why this is actually great

• Your app will finally look natural on tablets, foldables, and Chromebooks.
• Better UX → happier users → better reviews.
• Staying up to date keeps Google happy (and keeps your app visible).

✅ TL;DR

• Android 16 disables forced portrait lock on big screens → go responsive.
• By Aug 31, 2025: new apps & updates must target Android 15.
• Existing apps on API 34 can remain, for now.
• Android 16 target likely required around Aug–Sep 2026.

It’s a good time to future-proof your layouts — your users (and your Play Store rating) will thank you.

Let’s be real.

You joined tech thinking you’ll build cool apps, maybe even the next big startup. But suddenly you’re stuck dry-running a binary search tree on a whiteboard, with an interviewer staring like you’re defusing a bomb.
Why??

Isn’t app development mostly about layouts, APIs, and fixing that one annoying crash that only happens on Android 9?

Yes.
But here’s the catch — DSA is not just about code. It’s about you.

DSA ≠ Just Algorithms. It’s Mindset + How You React When Stuff Breaks

When you’re given a problem in interviews, they’re not just looking for a working solution.
They’re watching:

• Do you panic when it doesn’t work on the first try?
• Do you go quiet or talk through it?
• Do you ask smart questions?
• And honestly… do you give up or keep trying?

It’s like a live personality test with code.

Anyone Can Code. Few Can Think Clearly

Let’s be honest — with enough Stack Overflow and ChatGPT, anyone can build a to-do app.
But when a real bug hits production and it’s not in any tutorial — what do you do?

That’s where DSA prep helps. It trains your brain to:

• Break problems down
• Spot patterns
• Handle chaos without throwing your laptop

It’s like mental CrossFit. Painful at first. But later, when a bug hits on Friday at 6 PM? You’re calm. You’ve seen worse(hello, dynamic programming).

Bonus Points: It Shows How You Communicate

Interviewers don’t just want the right answer.
They want to see how you think — especially under pressure.

If you can explain your thoughts clearly, adapt when they add new constraints, and stay chill when stuck — congrats, you’re already ahead of 80% of the crowd.

TL;DR

DSA isn’t about building apps. It’s about building you.

You’re not just proving you can code — you’re showing:

• You can solve tough problems
• You stay composed under pressure
• You think, explain, and learn fast

The problem is just an excuse. You’re the real test. nd don’t forget to include these rounds as an interviewer.

#HappyCoding

AI, ML, and Deep Learning — What’s the Deal?

Let’s start with a simple fact: Artificial Intelligence (AI) is the boss, and Machine Learning (ML) is its hardworking employee. AI is the broad concept of making machines smart, while ML is a specific way AI learns from data. If AI were a school, ML would be the student doing all the homework (and complaining about it).

But wait, there’s more! ML itself has multiple techniques, and one of them is Deep Learning (DL). Deep Learning is a specialized method within ML that uses Neural Networks, but ML can also learn using other methods like decision trees, support vector machines, and statistical models.

The Learning Secret: Data, Data, and More Data

ML is like a child learning to recognize objects. If you don’t show it pictures of cats and dogs, it won’t know which is which. No data = No learning. Simple as that.

In ML, data is usually split into three parts:

• 70% Training Data (The School Phase) — The algorithm learns from this.
• 15% Validation Data (The Test) — It checks if learning is on track.
• 15% Test Data (The Final Exam) — It evaluates if ML actually understood or just memorized everything.

Deep Learning: One of ML’s Powerful Tools

Deep Learning is one of the most advanced methods used in ML, but it’s not the only way ML can work. Traditional ML techniques often rely on structured data and predefined rules, whereas Deep Learning uses multi-layered neural networks to automatically extract patterns from raw data.

Neural Networks — Not Real Neurons!

Neural networks sound fancy, but they’re just mathematical functions, not actual biological neurons. They mimic how our brains process information by passing data through layers of artificial neurons, which apply weights and biases to make decisions. If you want to go deeper into this topic, you can explore concepts like backpropagation and gradient descent separately.

Types of Learning

Deep Learning can learn in different ways:

1. Supervised Learning — The teacher provides answers (labeled data). Example: Feeding an AI thousands of pictures of cats and dogs, labeled accordingly.
2. Unsupervised Learning — No teacher, just raw data. The AI finds patterns by itself (kinda like figuring out office politics). Example: Grouping customer types in a business.
3. Reinforcement Learning — The trial-and-error method. The AI gets rewards for good behavior, like training a dog with treats. Example: AI learning to play chess by practicing against itself.

The Accuracy Game: Loss Functions and Optimizations

In deep learning, we aim for accuracy, but mistakes happen. The loss function tells us how wrong our model is. It’s also known as cost function or error function (because it’s costly to have errors!).

Think of a loss function as a teacher grading an exam. If you get all answers wrong, your loss is high. If you get them right, your loss is low. The AI adjusts itself to minimize this loss, improving accuracy over time.

The loss function is calculated in such a way that it minimizes the error in the learning data. When we provide the expected output, the model checks its generated output against it and determines how much error it has made. This feedback helps the model learn and improve in future iterations.

Example: AI Learning to Recognize Cats

1. You give an AI a dataset of 10,000 cat pictures.
2. It trains, but at first, it thinks some dogs are cats (big mistake!).
3. The loss function tells it, “Nope, that’s not a cat!”
4. It adjusts its model and tries again. It can try the same data multiple times to reduce the error — this repetition is called an epoch, and the number of epochs is set manually by the creator.
5. Over time, the AI becomes a cat-recognition master!

How ChatGPT Works — A Real-World Example

Ever wondered how ChatGPT gives you answers so quickly? Here’s what happens internally when you type a query:

1. Input Processing — Your text is converted into numerical representations (tokens) so the model understands it.
2. Neural Network Magic — The input is passed through multiple layers of a transformer model, which analyzes context, meaning, and past patterns.
3. Prediction & Probability — The model predicts the next words based on learned patterns and assigns probabilities to possible answers.
4. Loss Function Check — It evaluates how accurate its predictions are based on past training data.
5. Refinement & Output — The final response is generated, refined, and sent to you.

It’s like having a super-fast librarian who scans millions of books in a second to find the best answer!

Wrapping It Up

AI is the big picture, ML is the student learning from data, and Deep Learning is one of the advanced techniques ML uses to learn. ML also has other methods, and the right approach depends on the problem being solved.

And remember, without data, AI is just a clueless machine, like a student who never studied before an exam!

Hope this made AI/ML a little more fun for you! 🚀

Localization is essential for reaching a global audience, and Transifex makes it easier to manage translations efficiently. In this guide, we’ll walk through integrating Transifex into your Android project, handling runtime language changes, and ensuring seamless string retrieval.

Initializing Transifex

First, we define a global variable to manage language state across the app:

object LanguageManager {
    var langState: LocaleState? = null
}

This langState variable allows dynamic language switching at runtime.

Setting Up Transifex in Application Class

To initialize Transifex, add the following method in your Application class:

private fun initTransifex() {
    try {
        val preferredLanguage = "en" // Change to "es", "ja", "de" as needed
        
        LanguageManager.langState = LocaleState(
            TxNative.wrap(this),
            "en", // Default locale (usually English)
            arrayOf("en", "es", "ja", "de"), // Supported locales
            Locale(preferredLanguage) // Initial locale
        )
        TxNative.init(
            TxNative.wrap(this),
            LanguageManager.langState!!,
            BuildConfig.TRANSIFEX_TOKEN,
            null,
            null,
            null
        )
        
        TxNative.fetchTranslations(preferredLanguage, null)
        LanguageManager.langState?.setCurrentLocale(Locale(preferredLanguage))
        TxNative.fetchTranslations(null, null)
    } catch (e: Exception) {
        Timber.e("Transifex Throwable %s", e.message)
    }
}

Now, call this method inside the onCreate() method of your Application class:

override fun onCreate() {
    super.onCreate()
    initTransifex()
}

Changing Language at Runtime

To change the language dynamically from anywhere in your app, call:

LanguageManager.langState?.setCurrentLocale(Locale("es")) // Spanish

This will instantly update the app’s language to Spanish.

Handling Strings Properly

When using Transifex, make sure to wrap string retrievals using TxNative.wrap(). Instead of:

context.getString(R.string.string_id)
stringResource(R.string.string_id)

Use:

TxNative.wrap(LocalContext.current).getString(R.string.string_id)

This ensures that Transifex applies the correct translations based on the active locale.

Uploading Strings to Transifex

Once you’ve updated your string files, upload them to Transifex using the following command in the terminal:

java -jar </path/to>/transifex.jar push -t <token> -s <secret> -m app -v

Downloading Transifex CLI

Download the Transifex CLI tool (transifex.jar) from here and replace </path/to> in the above command with its actual location.

Conclusion

Integrating Transifex into your Android app enables efficient localization with minimal effort. By following the steps above, you can seamlessly manage translations, change languages dynamically, and keep your app user-friendly for a global audience.

So, you’ve just heard about coroutines in Kotlin, and everyone around you is hyping them up. “They’re lightweight!” “They simplify asynchronous programming!” “They make your coffee!” (Okay, maybe not that last one… yet.) But what exactly are coroutines? And how do they work under the hood? Grab your cup of coffee (made without coroutines, sadly), and let’s dive in.

🚀 What Are Coroutines?

Imagine you’re at a party with two kinds of people:

1. Threads: These are your overly enthusiastic friends who need a lot of space and energy to function.
2. Coroutines: These are the chill folks who get the job done without hogging all the snacks (or system resources).

Coroutines are Kotlin’s way of handling asynchronous programming. They allow you to write non-blocking, concurrent code that looks like it’s sequential. This means you can perform tasks like network calls or database operations without freezing your app, and without the headache of callbacks.

🌟 What Coroutines Offer Over Threads

Let’s take a closer look at how coroutines outshine threads:

1. Lightweightness

• Threads are heavyweight because each one takes up a significant chunk of system memory (about 1MB per thread).
• Coroutines, however, are extremely lightweight. You can create thousands of coroutines in the same memory space as a handful of threads.

2. Non-Blocking Code Execution

• In threads, blocking calls (like Thread.sleep) block the entire thread.
• Coroutines, on the other hand, can suspend their execution without blocking the thread. This allows other coroutines to run on the same thread.

3. Faster Context Switching

Let’s dig into context switching, a term that often leaves developers scratching their heads.

What Is Context Switching?

Context switching is the process of saving the state of a running task (like a thread or coroutine) so that another task can run, and then restoring the saved state to resume the original task.

• In Threads:
  The operating system saves and restores the entire thread state — CPU registers, stack, etc. This is like changing into a completely new outfit, and it’s expensive.
• In Coroutines:
  Only the coroutine’s execution state (like its stack frame) is saved in memory. Think of this as just putting on or taking off a hat — quick and efficient.

🧑‍🏫 Example of Context Switching and Thread Usage

Let’s say you’re using coroutines to perform two tasks: downloading data and processing it.

How Threads Work:

When switching tasks, the OS might pause a thread running Task A and resume a different thread running Task B. This involves:

1. Saving all the thread’s data (registers, stack).
2. Switching the CPU to the new thread.

Threads have a one-to-one relationship with the CPU core, and switching between them is costly.

How Coroutines Work:

Coroutines run on a Dispatcher (e.g., Dispatchers.Default, Dispatchers.IO):

1. When Task A (a coroutine) is suspended (e.g., waiting for network data), the thread is freed to run other coroutines.
2. When Task B resumes, it may run on the same thread or a different thread, depending on the dispatcher.

🧵 What Happens to Threads During Context Switch?

Here’s the secret sauce of coroutines:

• When a coroutine is suspended, the thread it’s running on is freed up to perform other tasks.
• The thread doesn’t get blocked or wasted. This is why coroutines are so efficient compared to traditional thread management.

Example in Action:

fun main() = runBlocking {
    launch(Dispatchers.IO) { 
        println("Downloading data on thread: ${Thread.currentThread().name}")
        delay(1000)  // Suspends coroutine, thread is freed
        println("Resuming download on thread: ${Thread.currentThread().name}")
    }

    launch(Dispatchers.Default) { 
        println("Processing data on thread: ${Thread.currentThread().name}")
        delay(500)  // Suspends coroutine, thread is freed
        println("Resuming processing on thread: ${Thread.currentThread().name}")
    }
}

Output:

Downloading data on thread: DefaultDispatcher-worker-1
Processing data on thread: DefaultDispatcher-worker-2
Resuming processing on thread: DefaultDispatcher-worker-3
Resuming download on thread: DefaultDispatcher-worker-1

Notice that the coroutine might resume on a different thread or the same one, depending on availability. This makes coroutines highly flexible and efficient.

4. Structured Concurrency

Coroutines provide structured concurrency — a mechanism to manage their lifecycle easily. When a coroutine scope ends, all its child coroutines are canceled automatically, preventing leaks and rogue tasks.

5. Error Handling

Coroutines offer exception transparency. If a coroutine fails, the parent coroutine can handle it, maintaining a clean and predictable error flow.

🎭 Tricky Question: What Really Happens on Suspension?

Let’s address a common question:

What happens to the thread when delay or any suspend function is called?

When a coroutine calls a suspend function:

1. The coroutine pauses its execution and saves its state.
2. The thread is freed and can be used to run other tasks.
3. Once the coroutine resumes, it may:

• Continue on the same thread.
• Be assigned a different thread, depending on the dispatcher.

🎉 Wrapping It Up

Coroutines are the secret weapon for writing clean, efficient, and readable asynchronous code in Kotlin. They offer lightweight context switching, structured concurrency, and excellent error handling, all while freeing up threads when they’re not needed.

So next time someone praises threads, you can say:
“Threads walk, but coroutines run — and they clean up after themselves too!”

That’s where Android WorkManager swoops in like a caped crusader, ensuring that your background tasks always get done, even when your app takes a nap or the phone restarts. Let’s break it down with a practical example.

Meet the Scenario: The Never-Ending Sync

Let’s say you’ve got a weather app, and it needs to sync weather data every 15 minutes so users get the latest forecast. But we all know that users aren’t always on the app, right? They may close it, or the phone may go into battery-saving mode, but the app still needs to get that data.

How WorkManager Saves the Day

1. The Request (AKA The “To-Do List” for WorkManager)
   First, you create a WorkRequest. This is like giving WorkManager a sticky note that says, “Hey, sync weather data every 15 minutes.” Now, WorkManager knows what needs to happen, and it’s ready to jump into action at the right time.
2. The Worker (The Hard Worker)
   Enter the Worker class. This is the actual task-doer. Think of it as your friend who always shows up to help, no matter what. Inside the doWork() method, you’ll tell it exactly what to do—like making an HTTP request to fetch the weather data.

public class WeatherSyncWorker extends Worker {   
  @NonNull     
  @Override     
  public Result doWork() {         
        // Get the latest weather data here         
        fetchWeatherData();         
        return Result.success();     
  } 
}

1. Handling Conditions (Because Timing Is Everything)
   But here’s the thing: you don’t want the app syncing when the phone is on 5% battery or when it’s in a place with no Wi-Fi. So, you set constraints. Maybe you tell WorkManager: “Only sync when the phone is charging or connected to Wi-Fi.”

Constraints constraints = new Constraints.Builder()     
.setRequiresCharging(true)     
.setRequiredNetworkType(NetworkType.UNMETERED) 
// Only Wi-Fi     .build();

1. Now, WorkManager only works when the conditions are perfect — like waiting for a sunny day to take your dog out for a walk.
2. Reliability (Even If Your App Decides to Nap)
   The real magic happens here: WorkManager doesn’t just forget the task if something goes wrong. If the app is closed, the phone restarts, or the app crashes mid-task, WorkManager will try again. It’s like your task is armed with a parachute, always ready to land safely, no matter what happens. So even after a device reboot, your weather sync will eventually run.

Why You’ll Love WorkManager

In real life, it’s like asking a friend to send your mom a birthday gift, but you give them strict instructions: “Don’t do it unless you’re at a store that has gift wrap, and only when you’re not on a time crunch, and please, do it even if you lose your phone on the way there!”

• Background Tasks? ✅
• Guaranteed Execution (Even on Reboots)? ✅
• Flexible Scheduling and Conditions? ✅

In the end, WorkManager is your app’s trustworthy assistant who always makes sure things get done, no matter how many distractions (or crashes) happen along the way.

So, next time you need to schedule background work that should run reliably — whether it’s syncing data, sending notifications, or anything else — think of Android WorkManager. It’s the unsung hero in your app’s background story, and it’s always working, even when you don’t see it.