DEV Community: Riazul Karim Ivan

Structured Concurrency with Kotlin Coroutines

Riazul Karim Ivan — Thu, 19 Feb 2026 16:28:35 +0000

Modern applications are highly concurrent. We fetch APIs, read databases, update UI, and process background tasks — often at the same time.

But concurrency without structure becomes chaos.

In this blog, we’ll explore:

What is Unstructured Concurrency
Why we need Structured Concurrency
The Fundamental Laws of Structured Coroutines
Real example with android viewModel implementation

What Is Unstructured Concurrency?

Unstructured concurrency is when asynchronous work is started without clear ownership, lifecycle, or control.

It’s the classic: “Start it and hope for the best.”

Example using traditional threads:

Thread {
    println("Doing background work")
}.start()

What’s wrong here?

Who owns this thread?
What if the screen is destroyed?
How do we cancel it?
What if it throws an exception?
How do we wait for it?

You don’t have much control over:

Lifecycle
Cancellation
Exception propagation
Execution flow

Even error handling becomes messy:

Thread {
    try {
        // some work
    } catch (e: Exception) {
        // won't propagate to parent
    }
}.start()

Exceptions don’t bubble up naturally. You lose structured error handling.

This is what we call Fire and Forget.

It may work in small programs — but in real systems (especially large Android apps), this becomes dangerous.

Why Traditional Threading Becomes Hard

Traditional threading:

Doesn’t enforce hierarchy
Doesn’t automatically propagate cancellation
Doesn’t wait for child work
Doesn’t provide predictable error handling

In complex systems:

Memory leaks happen
Background jobs continue after UI is gone
Errors disappear silently
Debugging becomes painful

As applications grow, this becomes unmanageable.

Why We Need Structured Concurrency

Structured concurrency solves these problems by introducing rules.

Instead of free-floating async work, we:

Group related tasks together
Track execution steps clearly
Manage lifecycle properly
Create a parent-child hierarchy
Make cancellation predictable
Make failure handling consistent

Think of it like this:

Unstructured concurrency = random background workers
Structured concurrency = organized team with a manager

The Core Idea: Parent-Child Hierarchy

Structured concurrency enforces a tree structure:

Parent
 ├── Child 1
 │     └── Grandchild
 └── Child 2

Rules:

A parent controls its children
A child cannot outlive its parent
Errors propagate upward
Cancellation flows downward

No more orphan coroutines.

What Is Structured Concurrency in Kotlin?

Structured concurrency is built into Kotlin coroutines using:

CoroutineScope
coroutineScope
supervisorScope
launch
async

Every coroutine must run inside a scope.

That scope defines:

Lifecycle
Cancellation rules
Error propagation
Completion behavior

Fundamental Laws of Structured Coroutines

There are five fundamental laws.

1. Law of Scope Ownership

Every coroutine must run inside a scope.

Bad (unstructured):

GlobalScope.launch {
    delay(1000)
}

Why bad?

No lifecycle control
Not tied to UI or business logic
Hard to test
Hard to cancel

Good:

coroutineScope {
    launch {
        delay(1000)
    }
}

The coroutine now belongs to the scope.

2. Law of Parent Completion

A parent scope suspends until all children complete.

Example:

coroutineScope {
    launch {
        delay(1000)
        println("Child done")
    }
}

println("Parent done")

Output:

Child done
Parent done

The parent does not finish until the child finishes.

This guarantees predictable execution flow.

3. Law of Downward Cancellation

Cancellation flows from parent to children.

Example:

val job = launch {
    launch {
        delay(5000)
        println("Child finished")
    }
}

delay(1000)
job.cancel()

When the parent is cancelled:

All children are cancelled automatically.

No orphan jobs.

4. Law of Upward Exception Propagation

Exceptions propagate from child to parent.

Example:

coroutineScope {
    launch {
        throw RuntimeException("Failure!")
    }

    launch {
        delay(5000)
    }
}

If one child fails:

Parent is cancelled
Sibling coroutines are cancelled

This enforces failure transparency.

You cannot silently ignore critical failures.

5. Law of Structured Boundaries

Concurrency must be bounded within a scope.

All async work must exist inside a well-defined boundary.

Not this:

fun loadData() {
    GlobalScope.launch {
        // background work
    }
}

But this:

suspend fun loadData() = coroutineScope {
    launch {
        // background work
    }
}

Now:

The caller controls lifecycle
The caller controls cancellation
The caller can handle exceptions

What About Independent Failures?

Sometimes you don’t want one failure to cancel everything.

That’s where supervisorScope comes in:

supervisorScope {
    launch {
        throw RuntimeException("Fails")
    }

    launch {
        delay(1000)
        println("Still running")
    }
}

Here:

One child fails
Other children continue

Useful for:

Parallel API calls
UI widgets
Independent features

Real-World Benefit (Especially for Large Apps)

In large systems:

Multi-module apps
Multiple API orchestration
Complex dashboards
Feature-based architecture

Structured concurrency gives:

Predictable lifecycle management
Safer cancellation
Cleaner error handling
Easier testing
No memory leaks
No zombie background jobs

It turns asynchronous chaos into a structured tree.

Structured vs Unstructured – Final Comparison

Feature	Unstructured	Structured
Lifecycle control	❌	✅
Cancellation propagation	❌	✅
Exception propagation	❌	✅
Hierarchy	❌	✅
Predictability	❌	✅
Maintainability	❌	✅

How to apply for android api call

Lets discuss three Scenarios to understand better:

Sequential / Dependent API calls (Chain)
Parallel Independent API calls (Zip – need both results)
Parallel Calls — Independent — Partial Failure Allowed

All examples are structured concurrency safe and lifecycle-aware.

Base Assumption (Clean Architecture Style)

Assume:

class FirstApiUseCase
class SecondApiUseCase

Each returns:

Flow<Result<T>>

And everything runs inside:

viewModelScope

Which means:

Automatically cancelled when ViewModel is cleared
No memory leaks
Structured lifecycle control

Scenario 1: Sequential API Calls (Second Depends on First)

Call API-1 → based on result → call API-2

Example:

Fetch user profile
Use userId → fetch user transactions

Let implement this with flatMapLatest chain

fun loadUserData(userId: String) {
    firstApiUseCase.execute(userId)
        .onStart { showLoading() }
        .flatMapLatest { userResult ->
            if (userResult is Result.Success) {
                secondApiUseCase.execute(userResult.data.id)
            } else {
                flowOf(Result.Error(Exception("User fetch failed")))
            }
        }
        .onEach { transactionResult ->
            handleTransactionResult(transactionResult)
        }
        .catch { showError(it) }
        .onCompletion { hideLoading() }
        .launchIn(viewModelScope)
}

Code Flow Explanation

firstApiUseCase.execute() starts.
When first API emits success →
flatMapLatest triggers second API.
If first fails → second never runs.
Everything is inside viewModelScope.
If ViewModel clears → both calls cancel.

Structured Concurrency Law Applied:

Parent scope owns both API calls.
Cancellation flows downward.
Exceptions propagate upward.
Execution remains bounded inside scope.

Scenario 2: Parallel Independent Calls (Zip – Need Both Results)

Call API-A and API-B in parallel
Continue only when BOTH succeed

Example:

Fetch wallet balance
Fetch recent transactions

They are independent but UI needs both.

Lets implement this with zip

fun loadDashboard() {

    val balanceFlow = balanceUseCase.execute()
    val transactionFlow = transactionUseCase.execute()

    balanceFlow
        .zip(transactionFlow) { balanceResult, transactionResult ->
            Pair(balanceResult, transactionResult)
        }
        .onStart { showLoading() }
        .onEach { (balance, transactions) ->
            renderDashboard(balance, transactions)
        }
        .catch { showError(it) }
        .onCompletion { hideLoading() }
        .launchIn(viewModelScope)
}

Code Flow Explanation

Both APIs start at the same time.
zip waits for BOTH to emit.
If either fails → whole flow fails.
Structured and lifecycle-safe.

Why This Is Structured

Both flows:

Are children of the same scope
Are cancelled if ViewModel clears
Fail together unless using supervisor

Scenario 3: Parallel Calls — Independent — Partial Failure Allowed

Example:

Load Profile
Load Notifications
Even if notifications fail → still show profile

Lets implement this with Supervisor Scope

Assuming use case returns Flow:

fun loadHomeScreen() {
    viewModelScope.launch {

        supervisorScope {

            val profileFlow = async {
                profileUseCase.execute().catch { emit(null) }.firstOrNull()
            }

            val notificationFlow = async {
                notificationUseCase.execute().catch { emit(null) }.firstOrNull()
            }

            val profile = profileFlow.await()
            val notifications = notificationFlow.await()

            profile?.let { renderProfile(it) }
            notifications?.let { renderNotifications(it) }
        }
    }
}

What Happens Here (Code Flow)

viewModelScope.launch → lifecycle owned by ViewModel
supervisorScope creates structured boundary
Two async blocks start in parallel
If one throws → it does NOT cancel the other
Both results are awaited safely
Each result handled independently

This is still 100% structured concurrency.

Why Not Use coroutineScope?

If you use:

coroutineScope {
    async { ... }
    async { ... }
}

If one throws →
Parent gets cancelled →
Sibling gets cancelled automatically ❌

That’s Law #4: Exceptions propagate upward.

But in this case we WANT:

Failure isolation
Independent execution

So we use supervisorScope.

Structured Hierarchy Now Looks Like

viewModelScope
    └── supervisorScope
            ├── async Profile
            └── async Notifications

Rules here:

Parent waits for both
Failure does NOT cancel sibling
Still lifecycle aware
Still bounded
Still structured

No GlobalScope.
No fire-and-forget.

Final Takeaway

Structured Concurrency is not just a feature. It’s a philosophy.

It says:

Async work must have ownership.
Work must be grouped logically.
Lifecycle must be controlled.
Errors must be visible.
Cancellation must be predictable.

If concurrency is a tree —
Structured concurrency makes sure every branch belongs to something.

No floating jobs | No silent failures | No chaos

Defect Management in the Pre-AI Era: Lessons from 14+ Years of Enterprise Software Delivery

Riazul Karim Ivan — Sun, 15 Feb 2026 15:50:53 +0000

Before AI-assisted debugging, automated RCA summaries, and smart ticket triaging — defect management was a highly human, structured, and disciplined engineering practice.

In my 15 years of experience across enterprise systems, mobile super apps, e-commerce platforms, core banking, multi-wallet systems, closed enterprise environments, and open-source modifications — one truth has remained constant:

Quality is not accidental. It is governed.

Defect management is not just a QA responsibility. It is a cross-functional operational system involving:

Engineering
QA
Product
Project Management
Leadership

This article outlines how structured defect governance was executed — systematically and strategically — before AI augmentation.

1. Defect Classification: Severity vs. Priority

Clear, objective classification prevents emotional debates and ensures business-critical issues receive immediate attention.

Severity (technical impact)

Level	Definition	Score
Critical	Application crash, data loss, security breach	4
Major	Core feature broken or severely degraded	3
Minor	UI/UX glitches, performance degradation	2
Trivial	Typos, cosmetic issues	1

Priority (business urgency)

Level	Meaning	Score
P0	Fix immediately (blocker)	1
P1	Must fix in next release	2
P2	Can be deferred to backlog	3

Example

Issue	Severity	Priority
Crash in payment screen	Critical	P0
Misaligned icon	Minor	P2

Priority and Severity

Source: https://medium.com/hepsiburadatech/bug-severity-and-priority-matrix-ae14fb344559

Priority and Severity - 2

Source: https://www.sketchbubble.com/en/presentation-severity-vs-priority.html

These matrices (or similar quadrant versions) were posted in every war room and Jira project.

2. The Defect Lifecycle

A standardized lifecycle creates transparency and accountability across teams.

Typical flow (customized per organization):

Defect Life Cycle example 1

Source: https://unstop.com/blog/bug-life-cycle

Defect Life Cycle example 2

Source: https://unstop.com/blog/bug-life-cycle

Key rule: The moment a developer starts analysis, the status must move to In Progress. Comments and artifacts are mandatory at every transition.

3. Required Artifacts for Every Defect

Clear title & description
Step-by-step reproduction path
Environment (SIT / UAT / Pre-Prod / Prod)
Screenshots / screen recordings
Frequency (Always / Sometimes / Once)
Backend request/response (when applicable)
Data dump or test data
Related logs

Incomplete defects were sent back to the reporter with a comment—preventing wasted developer time.

4. Testing Phases: Sequential Flow

We followed a structured progression of environments and testing layers.

Source: https://northflank.com/blog/what-are-dev-qa-preview-test-staging-and-production-environments

Pre-SIT (Development Internal Testing)

Backend + frontend engineers tested happy paths and selected error cases on mocked APIs. This was essentially a developer-led sanity check before official builds.

Smoke Testing (after every build/deployment)

Quick verification that the application launches and core navigation works.

SIT (System Integration Testing)

Dedicated QA team started as soon as partial features were released. Defects were logged and triaged immediately.

Sanity Testing

After every defect fix or small release—focused verification that the fix works and no obvious regressions were introduced.

UAT (User Acceptance Testing)

Business users or a separate QA team validated against real business scenarios. Often included regression suites.

Pre-Production / Staging (Dry Run)

Full production-like configuration with limited users. Final sanity + regression before go-live.

Production

Live monitoring. Critical issues → immediate hot-fix. Non-critical → negotiated deferral to next release.

Regression Testing

Executed after every fix across all phases to guard against side-effects.

5. Governance: Meetings That Actually Worked

Defect Triage / Assignment Meeting (post-SIT or post-UAT cycle)

QA + PM + PO + Dev Leads reviewed all new defects, assigned owners, and estimated effort.
Daily Defect Progress Meeting

15-minute stand-up tracking open critical/major defects. Missed targets escalated to leadership the same day.
Release Readiness Review

Dashboard-focused meeting held before every production push.

6. Developer Perspective: How We Actually Fixed Defects

Prioritize by Severity × Priority matrix.
Move to In Progress immediately.
Document root cause in comments.
If root cause lies in another team (BE/FE/UX/Content), re-assign with clear handoff notes.
Fix → local testing → developer sanity → raise PR with before/after evidence.
Code review → merge → deploy to next environment → QA retest + regression.

Hardest scenarios

“Works on my machine” / cannot reproduce (missing config, production-only data, log access). Solution: paired debugging sessions with QA.
Side-effects from the fix. Mitigation: mandatory regression checklist and peer review of changed flows.

Hot-fixes

All hands on deck—cross-team war room, parallel reproduction, fix, and deployment within hours.

7. Tools and Leadership Visibility

Jira was the undisputed champion. We built dashboards showing:

Defect aging (days open by severity)
Burn-down of critical/major defects
Pie charts by status, severity, module
Escape rate (defects found in production)
Sprint health

Source: https://idalko.com/blog/jira-dashboards

These dashboards were shared in leadership reviews—nothing builds urgency like a red “Defects > 30 days old” widget.

8. Key Metrics Leadership Should Track

Defect density per module
Average resolution time by severity
Defect escape rate (Prod / Pre-Prod)
Regression failure rate after fixes
Reopened defect ratio (signals poor testing or fixes)

Final Thoughts

Defect management is not about fixing bugs.

It is about:

Engineering maturity
Cross-functional accountability
Risk management
Release confidence
Leadership visibility

With a well-defined lifecycle, structured classification, sanity validation, and transparent dashboards — any multi-module enterprise system can maintain high reliability and predictable delivery.

And that discipline was built long before AI entered our workflows.

Managing Multi-Branch Development with Inter-Dependent Features (Without Merge Hell)

Riazul Karim Ivan — Sun, 15 Feb 2026 09:56:48 +0000

Real-world strategy for complex Android / backend teams building dependent features with staggered releases.

🎯 Problem Scenario

You have:

Multiple teams working in parallel
Feature dependencies (Feature 2 depends on Feature 1)
Partial releases
Feature flags controlling exposure
Independent features going on at the same time

Release Plan

Week	Release Content
Week 1	Feature 1 (Partial)
Week 2	Feature 1 (Controlled) + Feature 2 (Partial)
Final	Feature 1 (Full)
Final	Feature 2 (Full)

And some parts of Feature 1 must be OFF while Feature 2 is released.

This is not theoretical. This is production reality.

🚨 What Goes Wrong Without Strategy

Massive merge conflicts
Long-lived feature branches
Inconsistent environments
Broken CI
“It works in my branch” syndrome
Release panic

So we need:

✔ Predictable branch flow
✔ Clear dependency control
✔ Controlled releases
✔ Feature isolation
✔ Conflict minimization

🏗 Branching Strategy Overview

Instead of long-lived feature branches merging at the end, we use:

main → Production
develop → Integration
release/* → Weekly release branches
feature/* → Short-lived branches
Feature Flags → Control exposure

🌳 High-Level Branch Flow

main
  |
  |-----------------------------|
  |                             |
develop -------------------------
  |         |          |      |
  |         |          |      |
feature/F1  feature/F2 feature/F3 (independent)
   |            |
   |            |
   |------------|
        (merge early because F2 depends on F1)

🔥 Core Principle #1 — Merge Early, Hide with Feature Flags

Instead of waiting:

❌ Don’t keep Feature 1 in isolation until fully complete.

Instead:

✅ Merge incomplete Feature 1 to develop
✅ Hide incomplete parts behind feature flags

Example:

if (featureToggle.isFeature1PartialEnabled()) {
   showNewDashboard()
}

Feature toggles let you:

Merge early
Reduce conflicts
Control rollout
Disable partial implementation

This is critical in fintech apps.

🧩 Handling Feature Dependency (F2 depends on F1)

Correct Approach

F1 starts from develop
F1 merges to develop early (behind flag)
F2 branches from updated develop
F2 builds on F1’s base safely

Why?

If F2 branches before F1 merges →
You create a dependency merge nightmare later.

📅 Week-by-Week Flow
🟢 Week 1 → Release Partial Feature 1
Branch Structure

develop
   |
   |---- release/week-1

Steps:

Merge partial F1 into develop
Create release/week-1
Enable only partial F1 via feature flag
Merge release into main
Tag version

main ← release/week-1

🟡 Week 2 → Release F2 + Controlled F1

Now:

F2 already built on F1 (because F1 was merged early)

Some F1 parts must remain OFF

Branch Flow

develop
   |
   |---- release/week-2

Enable:

F2 partial → ON
F1 advanced parts → OFF

Controlled via:

Remote config
Build config
Runtime toggles

No branching trick. Just feature control.

🏁 Final Releases

When Feature 1 is complete:

Ensure all parts merged into develop
Enable all F1 flags
Create release branch
Merge to main
Same for Feature 2.

🔁 Independent Feature Development

Now let’s add complexity:

Feature 3, Feature 4, Feature 5
All independent.

Branch Structure

develop
 |  |  |  |
F1 F2 F3 F4

Rules:

✔ All feature branches short-lived
✔ Rebase frequently from develop
✔ Merge early
✔ Use feature flags
✔ Avoid feature-to-feature direct merges

⚔ Conflict Minimization Rules

Rule 1 — No Long-Lived Feature Branches

If a branch lives > 1 week → risk increases 3x.

Merge incomplete but hidden.

Rule 2 — Daily Rebase or Merge from Develop

git checkout feature/F2
git fetch
git rebase origin/develop

This keeps branch fresh.

Rule 3 — Avoid Branching from Another Feature

Never:

feature/F2 from feature/F1

Always:

feature/F2 from develop

Even if dependent.

Because F1 should already be merged (hidden).

Rule 4 — One Release Branch Per Release

Release branches are temporary stabilization zones.

develop → release/x → main

Hotfix goes:

main → hotfix/x → main → develop

📊 Full Flow Diagram (Complex Case)

                      main
                        ^
                        |
                release/week-1
                        ^
                        |
develop ----------------|----------------------
 |      |        |      |        |          |
F1      F2       F3     F4       F5         F6
 |       |
 |-------|
 (F2 depends on F1)

🧠 Advanced Technique (For Large Teams)

If you are working in something like:

Multi-module Android Super App
Microservice backend
Fintech compliance system

Then consider:

1️⃣ Module Isolation

Feature per module reduces conflict dramatically.

2️⃣ Trunk-Based Development (Advanced)

For very mature teams:

No long feature branches
Everyone merges to develop daily
Everything hidden behind flags

Used by:

Google
Meta
Netflix

🎛 Feature Flag Strategy (Very Important)

Types of flags:

Type	Purpose
Build-time	Separate flavor builds
Runtime	Enable/disable dynamically
Remote config	Gradual rollout

Example in fintech:

Enable new KYC flow only for 10% users
Enable F2 only after F1 baseline stable

💥 What This Achieves

✔ Minimal conflicts
✔ Parallel development
✔ Safe dependency handling
✔ Flexible release planning
✔ Faster CI stability
✔ Reduced stress before release

🏆 Final Golden Rules

Merge early.
Hide incomplete work with flags.
Never branch from another feature.
Rebase frequently.
Keep release branches short-lived.
Prefer integration over isolation.

🔚 Final Thought

Multi-feature development is not about Git tricks. It’s about discipline and integration mindset.

The real mistake teams make is confusing branch isolation with feature isolation.

Isolation should happen via flags — not branches.

Building a Scalable Navigation System for a 30+ Module Super App

Riazul Karim Ivan — Sat, 14 Feb 2026 10:02:26 +0000

I recently interviewed for a Senior Android role in Europe, where the core discussion revolved around large-scale navigation systems.

That conversation reminded me of something: designing navigation for a 30+ module multi-wallet super app is a completely different game compared to standard Android apps.

It’s not just about NavController or deep links. It’s about:

Modular isolation
Feature ownership
Cross-module communication
State-driven routing
Scalability without chaos

So let’s break down how to architect a robust, scalable in-app navigation system for a super app (think Revolut-style), while considering real-world constraints and growth challenges.

1. Core Architecture Overview

We use a layered navigation system:

DeepLinkActivity / NotificationReceiver
            ↓
NavigationDispatcherActivity (Invisible)
            ↓
Security State Machine
            ↓
MainActivity (Multi-tab NavHost)
            ↓
Feature NavGraphs (Per module)

We intentionally separate:

Entry resolution
Security validation
Feature navigation
UI containers

2. The Navigation Layers

Layer 1: Entry Layer

Handles:

Deep links
Push notifications
External SDK returns

Single responsibility:
→ Parse input
→ Send to Dispatcher

Never navigate directly.

Layer 2: Dispatcher Layer (Invisible Activity Pattern)

This is the brain.

class NavigationDispatcherActivity : ComponentActivity() {

    private val viewModel: DispatcherViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        viewModel.resolve(intent)

        lifecycleScope.launchWhenStarted {
            viewModel.destination.collect { destination ->
                startActivity(MainActivity.newIntent(this@NavigationDispatcherActivity, destination))
                finish()
            }
        }
    }
}

Why this is powerful:

Can perform API calls
Can validate security
Can transform routes
Can block invalid flows
No UI flicker

3. Router Abstraction (Multiple Routers Strategy)

In a 30+ module app, one router is not enough.

We define:

interface AppRouter {
    fun navigate(destination: Destination)
}

Then split by concern:

SecurityRouter
DashboardRouter
FeatureRouter
DialogRouter
ExternalRouter

Each router handles a specific layer.

Example: SecurityRouter

class SecurityRouter @Inject constructor(
    private val sessionManager: SessionManager
) {

    fun evaluate(destination: Destination): Destination {
        return when {
            !sessionManager.isLoggedIn() -> Destination.Login
            sessionManager.isPinRequired() -> Destination.PinValidation(destination)
            else -> destination
        }
    }
}

Dispatcher calls:

DeepLink → SecurityRouter → FinalDestination

4. Destination Modeling (Strongly Typed Navigation)

Never navigate with raw strings.

Use:

sealed class Destination {

    object Home : Destination()

    data class Transfer(
        val amount: Double?,
        val currency: String?
    ) : Destination()

    data class CryptoBuy(
        val asset: String
    ) : Destination()

    object Login : Destination()

    data class PinValidation(
        val next: Destination
    ) : Destination()
}

This prevents:

Route mismatch
Argument errors
Broken deep links

5. Compose Navigation Setup

Root NavHost (MainActivity)

@Composable
fun MainNavigation(startDestination: Destination) {

    val navController = rememberNavController()

    NavHost(
        navController = navController,
        startDestination = startDestination.route()
    ) {
        homeGraph(navController)
        paymentsGraph(navController)
        cryptoGraph(navController)
        cardsGraph(navController)
        profileGraph(navController)
    }
}

Each module exposes:

fun NavGraphBuilder.cryptoGraph(navController: NavController)

This keeps modules isolated.

6. Multi-Backstack Bottom Navigation

For a Revolut-style dashboard:

Home
Payments
Crypto
Cards
Profile

We maintain multiple back stacks.

val navControllers = remember {
    BottomTab.values().associateWith { NavHostController(context) }
}

Each tab owns:

Independent NavHost
Independent back stack

This ensures:

Switching tabs preserves state
Back works per tab
Deep link can jump to specific tab

7. Injecting Routers Into Dashboard

Dashboard should not know business rules.

Inject:

class DashboardViewModel @Inject constructor(
    private val featureRouter: FeatureRouter
)

Example:

fun onCryptoClick() {
    featureRouter.navigate(Destination.CryptoBuy(asset = "BTC"))
}

Router decides:

Tab switch
Destination route
Whether upgrade required

8. Handling Multiple Deep Link Flows

Example deep links:

revolut://transfer?amount=200
revolut://crypto/buy?asset=BTC
revolut://card/freeze?id=123

Dispatcher logic:

fun resolve(intent: Intent) {
    val parsed = deepLinkParser.parse(intent)

    val secured = securityRouter.evaluate(parsed)

    _destination.value = secured
}

If crypto feature disabled:

Destination.FeatureUnavailable

9. Handling Notification-Based Navigation

Notifications often require:

Open specific tab
Open nested screen
Show dialog
Validate session

Instead of embedding route inside PendingIntent directly:

Use same dispatcher.

Notification click → DispatcherActivity.

Example payload:

{
  "type": "CRYPTO_PRICE_ALERT",
  "asset": "BTC"
}

Mapping:

when(type) {
    CRYPTO_PRICE_ALERT -> Destination.CryptoBuy(asset)
    TRANSFER_RECEIVED -> Destination.TransferDetail(id)
}

Single resolution system for both deep links and notifications.

10. Handling Dialog & BottomSheet Navigation

Use Compose Navigation dialog destinations:

dialog(
    route = "upgrade_dialog"
) {
    UpgradeDialog()
}

For full screen bottom sheet:

Use:

ModalBottomSheet

Inside same NavHost.

Avoid new Activity.

11. PIN & Face Scan Flow

Security overlay flow:

If destination requires validation:

Destination.PinValidation(next = Transfer)

In NavGraph:

composable("pin_validation") {
    PinScreen(
        onSuccess = {
            navController.navigate(next.route())
        }
    )
}

Face scan same pattern.

12. Handling Inactive State (Session Timeout)

Use:

ProcessLifecycleOwner

Track background timestamp.

On resume:

if (timeout) {
   navController.navigate("pin_validation")
}

Important:

Do NOT recreate MainActivity.

Push overlay screen.

13. Dynamic Permissions & Server-Driven Menu

API returns enabled modules:

["HOME","CARDS","CRYPTO"]

Build tabs dynamically:

val tabs = apiModules.map { it.toBottomTab() }

NavGraph must be modular.

Modules expose their graph via DI.

14. Rotation Handling (Compose Advantage)

Compose + ViewModel:

Navigation state survives
Back stack preserved
Dispatcher ViewModel survives config change

Important:
Avoid storing navigation events as LiveData.

Use:

StateFlow + Event consumption

15. Some UI/UX Guide-line

Use contentDescription
Provide semantic roles
Manage focus when switching tabs
Use LaunchedEffect to request focus
Ensure dialog traps focus properly

Fintech apps must be accessible.

Final System Architecture Summary

Layer	Responsibility
Entry	Parse deep link / notification
Dispatcher	API + security resolution
Routers	Decide correct navigation
Main NavHost	Container
Feature Graphs	Isolated module flows
Dialog Layer	Overlays
Security Layer	State machine

Why This Architecture Scales to 30+ Modules

✔ Modules don’t know about each other
✔ Navigation centralized
✔ Security enforced globally
✔ Deep link + notification unified
✔ Dynamic features supported
✔ Back stack preserved per tab
✔ Compose-native
✔ Config-safe
✔ Testable

The Invisible Dispatcher Pattern (The Cool Part)

Instead of:

DeepLink → Feature

We use:

DeepLink → Dispatcher (ViewModel + API) → Router → Destination

This:

Eliminates navigation race conditions
Avoids feature coupling
Handles async validation
Makes super app manageable

Another use-case showing for an eduction app:

Navigation is not just about moving between screens — it is the backbone of a super app’s architecture. With a properly layered navigation system, complexity becomes manageable, features remain isolated, and the entire application stays scalable and testable.

The Ultimate Guide to Kotlin Concurrency for Building a Super Android App 🚀

Riazul Karim Ivan — Fri, 13 Feb 2026 18:21:22 +0000

How We Use Kotlin Coroutines & Flow in Enterprise Android

In this article, I'll show how we use Coroutines + Flow in production inside a digital wealth management app. This is not theoretical coroutine usage.

This is orchestration for:

Portfolio summary, Investment accounts
Risk profile validation, Regulatory document loading
Sensitive balance visibility toggle
Parallel dashboard aggregation
Child dependent API triggers
Compose-driven UI state
Backpressure handling
Error handling patterns
Token refresh flows
Retry policies
App preloading optimization

Architecture Context

Clean Architecture / MVVM / MVI
Repository pattern
UseCase returns Flow
ViewModel orchestrates flows
Immutable UI state via StateFlow
Compose collects state
Retrofit + Room
No GlobalScope
No blocking calls

1. Sequential Orchestration (Profile → Portfolio)

Real Scenario

When user opens Portfolio screen:

Load investor profile
Update greeting header
Fetch portfolio accounts
Map into UI state
Handle stage-specific errors

ViewModel Implementation

private fun loadInvestorOverview() {

    getInvestorProfileUseCase
        .execute(Unit)
        .onStart { setLoading(true) }
        .catch { error ->
            setLoading(false)
            showInvestorError(error)
        }
        .flatMapConcat { profile ->
            _uiState.update {
                it.copy(
                    investorName = "${profile.firstName} ${profile.lastName}"
                )
            }
            getPortfolioAccountsUseCase.execute(profile.investorId)
        }
        .catch { error ->
            setLoading(false)
            handlePortfolioError(error)
        }
        .onEach { accounts ->
            _uiState.update {
                it.copy(
                    portfolioAccounts = accounts.map {
                        PortfolioItem(
                            accountId = it.accountId,
                            productType = it.productType
                        )
                    }
                )
            }
        }
        .onCompletion { setLoading(false) }
        .launchIn(viewModelScope)
}

Why This Pattern Is Important

First error handles profile domain
Second error handles portfolio domain
No nested coroutine blocks
Pipeline remains flat and readable
Cancellation remains structured

This is how real fintech orchestration should look.

2. Parallel Dashboard Aggregation (combine)

Scenario

On dashboard load:

Fetch investment accounts
Fetch total asset value Show screen only when both available

fun initializeDashboard() {

    val accountsFlow = getInvestmentAccountsUseCase.execute(Unit)
    val assetValueFlow = getTotalAssetValueUseCase.execute(Unit)
    accountsFlow
        .combine(assetValueFlow) { accounts, totalValue ->
            accounts to totalValue
        }
        .onStart { setLoading(true) }
        .onCompletion { setLoading(false) }
        .catch { showDashboardError(it) }
        .onEach { (accounts, totalValue) ->
            _uiState.update {
                it.copy(
                    investmentAccounts = accounts,
                    totalAssets = totalValue
                )
            }
        }
        .launchIn(viewModelScope)
}

Why combine instead of zip?

combine reacts when either emits.
Asset value might refresh independently of account list.
In real apps:

Accounts rarely change
Market value changes frequently

combine supports this naturally.

3. Strict Regulatory Pairing (zip)

Scenario

Before showing Trade screen:

Load risk disclosure template
Load risk summary view template

Both must succeed.

private fun loadRiskDocuments() {

    getDisclosureTemplateUseCase.execute(DISCLOSURE_FULL)
        .zip(
            getDisclosureTemplateUseCase.execute(DISCLOSURE_SUMMARY)
        ) { full, summary ->
            full to summary
        }
        .onStart { setLoading(true) }
        .onCompletion { setLoading(false) }
        .catch { showDocumentError(it) }
        .onEach { (fullDoc, summaryDoc) ->
            _uiState.update {
                it.copy(
                    fullDisclosure = fullDoc,
                    summaryDisclosure = summaryDoc
                )
            }
        }
        .launchIn(viewModelScope)
}

Why zip here?

Because both documents are mandatory before proceeding.
No partial rendering allowed.

4. Detail Loading + Dependent Call

Scenario

When user selects an investment account:

Load account details
Update state
Trigger transaction history call

fun loadAccountDetail(accountId: String, refresh: Boolean = false) {

    getAccountDetailUseCase
        .execute(accountId)
        .onStart { setLoading(true) }
        .onCompletion {
            _uiState.update { it.copy(isRefreshing = false) }
        }
        .catch { handleDetailError(it) }
        .onEach { detail ->
            _uiState.update {
                it.copy(
                    selectedAccount = detail,
                    hasDividendOption = detail.dividendOptions.isNotEmpty()
                )
            }
            loadTransactionHistory(accountId, refresh)
        }
        .launchIn(viewModelScope)
}

Why trigger child call inside onEach?

Because:

Only executed after success
No nested coroutineScope
Keeps orchestration centralized in ViewModel

5. UI State for Compose (Immutable)

data class PortfolioUiState(
    val isLoading: Boolean = false,
    val investorName: String = "",
    val investmentAccounts: List<PortfolioItem> = emptyList(),
    val totalAssets: AssetValue? = null,
    val selectedAccount: AccountDetail? = null,
    val hasDividendOption: Boolean = false,
    val fullDisclosure: Document? = null,
    val summaryDisclosure: Document? = null
)

ViewModel State Holder

private val _uiState = MutableStateFlow(PortfolioUiState())
val uiState: StateFlow<PortfolioUiState> = _uiState

6. Compose UI (Reactive + Clean)

@Composable
fun PortfolioScreen(viewModel: PortfolioViewModel) {

    val state by viewModel.uiState.collectAsStateWithLifecycle()
    if (state.isLoading) {
        CircularProgressIndicator()
    }
    Text(text = "Welcome ${state.investorName}")

    state.totalAssets?.let {
        Text("Total Assets: ${it.formatted}")
    }

    LazyColumn {
        items(state.investmentAccounts) { account ->
            Text(account.accountId)
        }
    }
}

No LiveData and No manual observers.
Pure Flow ----> StateFlow ----> Compose.

7. Reactive Sensitive Value Visibility (Flow-Based)

Instead of Rx sensor logic, we use Flow:

Scenario:

Hide portfolio value when device is face down
Show when user touches screen

val sensitiveVisibilityFlow =
    combine(deviceOrientationFlow, userInteractionFlow) { isFaceDown, isTouching ->
        !isFaceDown && isTouching
    }.distinctUntilChanged()
In ViewModel:
sensitiveVisibilityFlow
    .onEach { visible ->
        _uiState.update {
            it.copy(isPortfolioVisible = visible)
        }
    }
    .launchIn(viewModelScope)
Compose:
AnimatedVisibility(visible = state.isPortfolioVisible) {
    PortfolioValueSection()
}

8. Handling Inactivity (PIN / Login Expire)

Use a shared flow for session events.

object SessionManager {
    private val _sessionExpired = MutableSharedFlow<Unit>()
    val sessionExpired = _sessionExpired.asSharedFlow()

    suspend fun expire() {
        _sessionExpired.emit(Unit)
    }
}

In BaseViewModel:

viewModelScope.launch {
    SessionManager.sessionExpired.collect {
        navigator.navigateToLogin()
    }
}

9. Prevent Multiple Button Clicks (Throttle)

Double execution is not a fintech issue.
It's a concurrency failure - and every serious app must prevent it.

Throttle First

fun <T> Flow<T>.throttleFirst(windowDuration: Long): Flow<T> = flow {
    var lastTime = 0L
    collect { value ->
        val current = System.currentTimeMillis()
        if (current - lastTime >= windowDuration) {
            lastTime = current
            emit(value)
        }
    }
}

Usage:

buttonClicks
    .throttleFirst(1000)
    .onEach { viewModel.sendMoney() }
    .launchIn(scope)

10. Backpressure Handling (High Frequency Events)

Example:

Search field
Real-time stock ticker

Debounce + FlatMapLatest

searchQuery
    .debounce(300)
    .distinctUntilChanged()
    .flatMapLatest { query ->
        repository.searchStocks(query)
    }

flatMapLatest cancels previous request.

11. Avoid Blocking User Experience

Never:

runBlocking { }
Thread.sleep()

Instead:

withContext(Dispatchers.IO) {
    heavyWork()
}

Or better - push heavy work to repository layer.

12. Jetpack Compose Concurrency Patterns

Collect State Safely

val balance by viewModel.balanceFlow.collectAsStateWithLifecycle()

Launch Side Effects

LaunchedEffect(Unit) {
    viewModel.loadDashboard()
}

Snackbar Error Flow

LaunchedEffect(viewModel.errorFlow) {
    viewModel.errorFlow.collect {
        snackbarHostState.showSnackbar(it.message)
    }
}

13. Advanced Retry with Exponential Backoff

In financial systems:

Network instability is common
Backend throttling happens
Temporary 5xx failures occur
You must retry safely - but not aggressively

Retry is not retry(3).
Retry must be:

Conditional
Intelligent
Exponential
Cancellable
Token-aware

13.1 Production Pattern: Conditional Exponential Backoff

Scenario

Refreshing portfolio valuation from market service.

private fun refreshMarketValuation() {

    getMarketValuationUseCase
        .execute(Unit)
        .retryWhen { cause, attempt ->
            val isNetworkError = cause is IOException
            val isServerError = cause is HttpException && cause.code() >= 500
            if ((isNetworkError || isServerError) && attempt < 3) {
                val backoffDelay = 1_000L * (2.0.pow(attempt.toDouble())).toLong()
                delay(backoffDelay)
                true
            } else {
                false
            }
        }
        .onStart { setLoading(true) }
        .onCompletion { setLoading(false) }
        .catch { handleMarketError(it) }
        .onEach { valuation ->
            _uiState.update { it.copy(marketValuation = valuation) }
        }
        .launchIn(viewModelScope)
}

What Happens Here?

Retries only network + 5xx
Does NOT retry business errors (4xx)
Exponential backoff: 1s → 2s → 4s
Automatically cancelled if ViewModel cleared
No blocking threads

This prevents backend abuse while improving reliability.

14. Token Expiry + Automatic Refresh

In fintech/investment systems:

Access tokens expire frequently
Multiple API calls may fail simultaneously
Only ONE refresh call must execute
Other calls must wait

If you don't orchestrate this properly:

You trigger multiple refresh requests
Backend invalidates sessions
Users get forced logout

Core Rule

Token refresh must be:

Centralized
Mutex-protected
Reusable across flows

Token Coordinator

class AuthTokenCoordinator(
    private val refreshTokenUseCase: RefreshTokenUseCase,
    private val tokenStorage: TokenStorage
) {

    private val mutex = Mutex()
    suspend fun refreshIfNeeded(): String {
        return mutex.withLock {
            val newToken = refreshTokenUseCase.execute(Unit).first()
            tokenStorage.save(newToken)
            newToken.accessToken
        }
    }
}

Why Mutex?
If 5 APIs fail with 401 at the same time:

Without Mutex → 5 refresh calls
With Mutex → 1 refresh call
All suspended callers wait safely.

14.1 Token Refresh Orchestration Pattern (Flow Level)

Now the important part:

How do we retry original API after token refresh?

We do NOT handle token inside every ViewModel.
We handle it at repository layer.

Repository-Level Flow Orchestration

Scenario

Fetching portfolio summary.

fun getPortfolioSummary(): Flow<PortfolioSummary> {

   return flow {
        emit(api.getPortfolioSummary())
    }
        .catch { throwable ->
            if (throwable is HttpException && throwable.code() == 401) {
                val newToken = authTokenCoordinator.refreshIfNeeded()
                emit(api.getPortfolioSummaryWithToken(newToken))
            } else {
                throw throwable
            }
        }
}

What Happens Here?

API call fails with 401
Refresh token (mutex protected)
Retry original call
Emit result
Upstream ViewModel never knows refresh happened

This keeps ViewModel clean.

14.2 Even Cleaner: Reusable Token Wrapper

For large systems, create a reusable wrapper:

fun <T> Flow<T>.withTokenRefresh(
    authTokenCoordinator: AuthTokenCoordinator,
    retryBlock: suspend (String) -> T
): Flow<T> {

    return catch { throwable ->
        if (throwable is HttpException && throwable.code() == 401) {
            val newToken = authTokenCoordinator.refreshIfNeeded()
            emit(retryBlock(newToken))
        } else {
            throw throwable
        }
    }
}

Usage:

fun getPortfolioSummary(): Flow<PortfolioSummary> {

    return flow {
        emit(api.getPortfolioSummary())
    }.withTokenRefresh(authTokenCoordinator) { newToken ->
        api.getPortfolioSummaryWithToken(newToken)
    }
}

Why This Pattern Scales

Centralized
Reusable
No duplication
Mutex-safe
ViewModel unaware of auth complexity
Works with combine / zip / flatMap

14.3 What Happens with Parallel Calls + Token Expiry?

Let's say:

initializeDashboard()
  → getInvestmentAccounts()
  → getTotalAssetValue()

Both fail with 401.

What happens?

First failure triggers refresh
Second waits on mutex
Both resume using new token
combine still works
UI sees only final result

About Auth Orchestration

In this kind of app, Token management is not an interceptor problem only. It is a concurrency orchestration problem.

App must be design with these:

Mutex protection
Repository-level retry
ViewModel isolation
Cancellation safety
Backoff compatibility

When done correctly:

UI remains clean
Flows remain declarative
Orchestration remains centralized
System remains resilient

In fintech apps, concurrency is not optimization.

Final Thought

Coroutines and Flow are not async tools.
They are:

Orchestration engine
Error propagation model
State machine builder
Backpressure handler
Lifecycle-aware execution framework

A Clean & Practical Code Review Checklist for Android Projects

Riazul Karim Ivan — Thu, 12 Feb 2026 14:02:16 +0000

In Android projects — especially large-scale, multi-module, production apps — having a consistent review checklist reduces technical debt and keeps standards aligned across the team.
They are about maintainability, scalability, performance, and team trust.
Here’s a practical checklist I use for Android projects.

1. Architecture & Design

Good architecture makes the project survivable after years.

✔ Architecture Consistency

Follows Clean Architecture / MVVM / MVI consistently
Uni-directional data flow maintained
Clear separation of UI / Domain / Data layers

✔ Business Logic Placement

No business logic inside Activities or Fragments (or compose)
ViewModels only handle UI-related logic
Domain logic lives inside UseCases

✔ UseCases

Single responsibility
Small and focused
No multi-purpose “God” use cases

✔ Dependency Injection

Hilt / Dagger properly configured
No manual dependency wiring
No service locators hidden inside code

✔ Design Principles

SOLID principles followed, along with others(DRY, KISS, GRASP, CQRS)
Reuse of existing utility functions where appropriate
No duplicated logic
No broken unit tests

2. Kotlin & Language Usage

Kotlin gives powerful tools. Use them wisely.

✔ Immutability First

Prefer val over var
Immutable state where possible

✔ Kotlin Types

Use data class for models
sealed class for state representation
enum when appropriate

✔ Null Safety

Avoid nullable chains like ?.?.?.
No use of !!
Handle nulls explicitly and safely

✔ Extension & Scope Functions

Extension functions improve readability (not dumping business logic)
Scope functions (let, apply, run, also, with) used meaningfully
No nested scope-function pyramids

✔ Data Structures

Correct usage of List, MutableList, Map, Set
Avoid unnecessary list copying
Efficient transformations (map, filter, associate, etc.)

3. UI Layer (Compose / XML)

UI should be predictable and state-driven.

Jetpack Compose

State hoisted properly
UI is stateless where possible
No side effects inside composables
Use LaunchedEffect, SideEffect, remember, derivedStateOf correctly
Awareness of recomposition behavior (use of key in list generate)
Avoid unnecessary recompositions

XML / View System

No heavy logic inside views
Avoid deeply nested layouts
ViewBinding enabled (no findViewById)
No memory leaks from view references

4. State & Async Handling

Async mistakes are expensive in production.

✔ Coroutines & Flow

Proper use of Flow, StateFlow, or LiveData
No GlobalScope
Cold vs hot stream usage is correct

✔ Dispatcher Usage

IO for network/database
Default for CPU work
Main for UI

✔ Cancellation

Jobs cancelled properly
ViewModelScope used correctly

✔ Avoid Blocking

No runBlocking in production
No Thread.sleep()
No heavy work on Main thread

5. Error Handling

Error handling defines production quality.

Errors modeled explicitly (Result, Either, sealed classes)
No silent catch {} blocks
User-friendly error states exposed to UI
Logs added meaningfully (no spam logging)

6. Performance

Performance issues hide in small mistakes.

No heavy work on Main thread
Avoid unnecessary recompositions
Efficient list rendering (LazyColumn, DiffUtil)
Pagination or lazy loading where needed
No memory leaks (Context misuse, observers not cleared)

7. Testing

If it’s not tested, it’s fragile.

Unit tests for UseCases
Unit tests for ViewModels
UI logic is state-driven and testable
Mocks/Fakes used properly
Descriptive test names
Minimum coverage target followed (e.g., 80%)
Test functions are maintainable and readable

8. Code Quality & Readability

Code should read like documentation.

Small and focused functions
Meaningful naming (no data, temp, obj)
No commented-out dead code
Consistent formatting (ktlint, detekt)
No magic numbers — use constants

9. Security & Configuration

Small mistakes here can be costly.

No API keys or secrets inside source code
Tokens loaded from secure config
Proguard / R8 rules reviewed
Debug-only tools not leaking into release builds
Do not pass secret user-data every layer or keep in memory
Follow Security team guideline to avoid pentest defects/review comments

10. Git & PR Hygiene

Good PR hygiene reduces team friction.

PR is small and focused
Large tasks split into smaller subtasks
Clear description of what and why
Screenshots for UI changes
Screen recording for flow (even with mock data)
For defect fixes: include reproduction path and screen record
Linked ticket/task for feature or bug
No unrelated changes in the same PR

Final Thoughts

A good code review is not about nitpicking syntax. It’s about protecting the future of the codebase.
When teams follow a structured checklist:

Bugs decrease
Performance improves
Onboarding becomes easier
Refactoring becomes safer (layer by layer)
Trust increases

Code quality is not accidental. It is enforced — consistently.