DEV Community: Hoang Son

Day 7/100: Week 1 Recap — 6 Android Fundamentals I Thought I Knew Cold

Hoang Son — Sun, 05 Apr 2026 16:39:56 +0000

This is Day 7 of my 100 Days to Senior Android Engineer series. Every 7th day is a weekly recap — a structured summary of what I covered, what surprised me, and what I'm carrying into next week.

Week 1 is done.

Six topics. Six posts. And more gaps in my "solid" understanding than I expected to find.

Here's the honest summary.

What I covered this week

Day	Topic	Key insight
Day 1	Why I started this	Knowing how vs knowing why
Day 2	The 4 Android components	Each is an OS entry point, not just a class
Day 3	Activity Lifecycle	`onDestroy()` is not guaranteed
Day 4	Fragment Lifecycle	Two lifecycles: Fragment + View
Day 5	Intent, Task & Back Stack	`singleTask` clears your back stack silently
Day 6	Context	Lifetime mismatch = memory leak

The 6 most important things I (re)learned

1. Android components are entry points, not just classes

When you declare an Activity, Service, BroadcastReceiver, or ContentProvider in AndroidManifest.xml, you're giving the OS a door into your app — one it can open independently, even if the rest of your app isn't running.

This reframes how you think about crashes and ANRs. When something fires unexpectedly, the first question is now: which entry point triggered this, and what are its thread and lifecycle contracts?

The one that catches people most: BroadcastReceiver.onReceive() runs on the main thread and dies immediately after the method returns. No coroutine scope. No lifecycle. Delegate to WorkManager and return.

2. `onDestroy()` is not a safe place to save critical state

The lifecycle diagram shows onDestroy() as a clean endpoint. The reality:

Under memory pressure, the system can kill your process without calling onDestroy().

onPause() is the only callback guaranteed to be called before your process dies. If you're saving anything critical — a draft, a form input, a transaction — it belongs in onPause() or better yet, in SavedStateHandle.

// The modern answer for state that must survive both
// configuration changes AND process death:
class FormViewModel(private val savedStateHandle: SavedStateHandle) : ViewModel() {
    var draftInput: String
        get() = savedStateHandle["draft"] ?: ""
        set(value) { savedStateHandle["draft"] = value }
}

3. Fragment has TWO lifecycles — and mixing them up leaks memory

A Fragment's View is destroyed and recreated every time the user navigates away and back on the back stack. The Fragment instance stays alive. This means:

Observers scoped to the Fragment (this) keep firing even when the View is gone
binding references become stale but don't throw until you touch them

The fix is one word: viewLifecycleOwner.

// ❌ Observer stays alive after view is destroyed
viewModel.state.observe(this) { updateUI(it) }

// ✅ Observer cancelled when view is destroyed
viewModel.state.observe(viewLifecycleOwner) { updateUI(it) }

If you write one thing differently after reading this series, make it this.

4. `singleTask` clears your back stack — and it's silent about it

This is the one I found most embarrassing to admit, because I've shipped it.

singleTask doesn't just prevent duplicate instances. It destroys everything above the target Activity in the back stack when it's reused. A user mid-flow taps a notification, and their navigation history is gone.

User's back stack:  [Home] → [List] → [Detail] → [Settings]
Notification tap targets Detail (singleTask):
Result:             [Home] → [Detail]
                              ↑ List and Settings silently destroyed

The correct tool for notification deep links is TaskStackBuilder, which synthesizes a logical back stack instead of destroying the existing one.

5. Context lifetime mismatch is the root cause of most leaks

The rule I now use:

Match the context's lifetime to the consumer's lifetime.

Consumer lives forever (singleton, library) → applicationContext
Consumer is UI-bound (View, Dialog, LayoutInflater) → Activity context

Using applicationContext everywhere "to be safe" isn't safe — it silently breaks theme-dependent attributes and crashes Dialog creation. Using Activity context everywhere leaks memory into long-lived objects.

The decision is about lifetime, not about which one compiles.

6. `ContentProvider` initializes before `Application.onCreate()`

This one was a genuine surprise.

Libraries like WorkManager, Firebase, and Jetpack Startup use an empty ContentProvider to auto-initialize without requiring any code in your Application class. The ContentProvider.onCreate() runs before Application.onCreate(), giving them a guaranteed early initialization hook.

Process starts →
  ContentProviders init (manifest order) →
  Application.onCreate() →
  Your first Activity/Service/Receiver

Next time you wonder how a library "just works" with no setup — check if it ships a ContentProvider in its manifest.

The question I couldn't answer confidently until Day 3

On Day 2, I wrote about the two-Activity transition callback order. I thought I knew it:

A.onPause() → A.onStop() → B.onCreate() → B.onStart() → B.onResume()

Wrong.

A.onPause() → B.onCreate() → B.onStart() → B.onResume() → A.onStop()

A.onStop() comes after B.onResume(). Activity B is fully visible before Activity A stops. I've known this diagram for years and never caught the ordering detail.

The practical consequence: if you hold an exclusive resource (camera, audio focus) and release it in onStop() instead of onPause(), Activity B will try to acquire it before you've released it.

What surprised me most about Week 1

I expected to fly through the fundamentals. These are basics — I've been doing Android for 8 years.

What I found instead: I had solid procedural knowledge (what to call, when to call it) but weaker causal knowledge (why the system works this way, what breaks when you violate the rules).

The gaps showed up in the edge cases:

The precise callback order between two Activities
What singleTask actually does to the back stack
The Fragment's View lifecycle being genuinely separate from the Fragment lifecycle

None of these are obscure. They're in the official documentation. I just hadn't read them carefully in a long time — and "mostly right" had been good enough.

It's not good enough for senior-level conversations.

Into Week 2

Next week: Process Death, Memory, ANR, and Main Thread Model.

These are the topics that show up in production incident post-mortems more than anywhere else. They're also the topics where the gap between "I've heard of this" and "I can diagnose this in production" is largest.

Starting Monday with Day 8: Process Death — what actually happens when Android kills your app.

One question for you

What's the Android fundamental you feel least confident explaining to a junior? Drop it in the comments — it might become a future post.

Follow the full series to get all 100 days.

← Day 6: Context in Android — The Wrong One Will Leak Your Entire Activity

Day 6/100: Context in Android — The Wrong One Will Leak Your Entire Activity

Hoang Son — Wed, 01 Apr 2026 16:43:22 +0000

This is Day 6 of my 100 Days to Senior Android Engineer series. Each post: what I thought I knew → what I actually learned → interview implications.

🔍 The concept

Context is one of those Android classes you use dozens of times per day without thinking about it. You pass it to constructors, use it to inflate views, start activities, access resources.

But Context isn't one thing — it's a family of related objects with very different lifetimes. Pass the wrong one into a long-lived object, and you've just anchored that object to a screen that the user may have left minutes ago. The screen can't be garbage collected. You've created a memory leak.

Not a theoretical one. A real one that affects every user who navigates back to that screen.

💡 What I thought I knew

My rule of thumb used to be: "Use applicationContext when in doubt."

That's not wrong exactly — applicationContext won't leak. But it's incomplete, and applying it blindly causes a different class of bugs: UI operations that crash, theme-aware resources that return wrong values, dialogs that fail to show.

The full picture is more nuanced, and more interesting.

😳 What I actually learned

What Context actually is

Context is an abstract class that provides access to application-level resources and operations:

Context (abstract)
  ├── ContextWrapper
  │     ├── Application        ← lives as long as the process
  │     ├── Activity           ← lives as long as the screen
  │     └── Service            ← lives as long as the service
  └── ContextImpl              ← the real implementation, hidden from you

Every Activity is a Context. Every Application is a Context. They wrap the same underlying ContextImpl but expose different capabilities and, critically, have different lifetimes.

The lifetime mismatch that causes leaks

The classic pattern that causes a leak:

// ❌ Singleton holding an Activity Context
object ImageLoader {
    private lateinit var context: Context

    fun init(context: Context) {
        // If caller passes an Activity, this singleton now holds
        // a reference to that Activity for the lifetime of the process
        this.context = context
    }
}

// In Activity:
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    ImageLoader.init(this)  // 💀 leaking 'this' into a singleton
}

The singleton lives forever. It holds the Activity. The Activity holds its entire view hierarchy — every View, every Bitmap, every Drawable. None of it can be garbage collected.

Rotate the screen twice and you have three leaked Activity instances, each holding their full view hierarchy in memory.

The fix is one word:

fun init(context: Context) {
    this.context = context.applicationContext  // ✅ survives rotation, no leak
}

applicationContext has the same lifetime as the process. No Activity is held. No leak.

But `applicationContext` isn't always correct

Here's where my old rule of thumb breaks down. applicationContext doesn't have a theme. It doesn't know which Activity it's in. For operations that depend on the UI context, it either crashes or silently returns wrong results.

// ❌ Inflating a view with applicationContext — theme attributes broken
val view = LayoutInflater.from(applicationContext).inflate(R.layout.my_view, null)
// Colors from ?attr/colorPrimary, ?attr/textAppearanceBody1, etc. — all wrong

// ✅ Inflate with Activity context — theme attributes resolved correctly
val view = LayoutInflater.from(this).inflate(R.layout.my_view, null)

// ❌ Showing a Dialog with applicationContext — crashes on API 23+
AlertDialog.Builder(applicationContext)  // throws WindowManager$BadTokenException
    .setMessage("Are you sure?")
    .show()

// ✅ Show Dialog with Activity context
AlertDialog.Builder(this)
    .setMessage("Are you sure?")
    .show()

// ❌ Starting an Activity from applicationContext without NEW_TASK flag — crashes
applicationContext.startActivity(Intent(applicationContext, DetailActivity::class.java))
// throws AndroidRuntimeException: Calling startActivity() from outside of an Activity context

// ✅ With the required flag
applicationContext.startActivity(
    Intent(applicationContext, DetailActivity::class.java).apply {
        flags = Intent.FLAG_ACTIVITY_NEW_TASK
    }
)

The decision table

After going through the docs carefully, this is the table I now keep in my head:

Operation	Application Context	Activity Context
Start an Activity	⚠️ needs `NEW_TASK` flag	✅
Start a Service	✅	✅
Send a Broadcast	✅	✅
Load a resource (string, drawable)	✅	✅
Inflate a layout with theme	❌ wrong theme	✅
Show a Dialog	❌ crashes	✅
Create a ViewModel	❌	✅
Initialize a singleton / library	✅	❌ leaks
Access SharedPreferences	✅	✅
Get system services (e.g. `ClipboardManager`)	✅	✅

The pattern: anything UI-related needs Activity context. Anything that lives longer than a screen needs Application context.

The `this` vs `requireContext()` vs `requireActivity()` confusion in Fragments

Fragments add another layer of confusion because they're not a Context themselves — they have a context.

class MyFragment : Fragment() {

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {

        // 'this' — the Fragment, NOT a Context
        // Can't be passed where Context is expected

        // requireContext() — the Activity context (or throws if detached)
        val prefs = requireContext().getSharedPreferences("prefs", Context.MODE_PRIVATE)

        // requireActivity() — explicitly the Activity, useful when you need
        // Activity-specific APIs like ViewModelProvider, window insets, etc.
        val windowInsetsController = requireActivity().window.insetsController

        // context — nullable version of requireContext(), safe if you check
        context?.let { ctx ->
            Toast.makeText(ctx, "Hello", Toast.LENGTH_SHORT).show()
        }
    }
}

The practical rule in Fragments: use requireContext() for Context needs, requireActivity() only when you specifically need the Activity. The difference matters if you ever move the Fragment to a different host.

The `WeakReference` anti-pattern

You'll sometimes see this pattern as an attempted fix for Context leaks:

class SomeManager(context: Context) {
    // "I'll use WeakReference so I don't leak"
    private val contextRef = WeakReference(context)

    fun doSomethingWithUI() {
        val ctx = contextRef.get() ?: return
        // use ctx
    }
}

This is better than holding a strong reference, but it's still wrong for different reasons:

If you need the UI context to still be alive, a WeakReference that's been collected gives you null at an unpredictable time — leading to silent no-ops or hard-to-reproduce bugs.
If you don't need the UI context, you should be using applicationContext anyway.

WeakReference<Context> is almost never the right answer. It papers over the real issue: the object's lifetime is incompatible with the context's lifetime. Fix the lifetime problem instead.

The `ContextThemeWrapper` you didn't know you were using

When you write LayoutInflater.from(activity), you get a LayoutInflater that uses the Activity's theme. But sometimes you need to inflate a view with a different theme than the current Activity — for example, inflating a dark-themed bottom sheet inside a light-themed Activity.

// Inflate with a custom theme, without changing the Activity's theme
val themedContext = ContextThemeWrapper(requireContext(), R.style.ThemeOverlay_App_BottomSheet)
val inflater = LayoutInflater.from(themedContext)
val view = inflater.inflate(R.layout.bottom_sheet_content, container, false)

ContextThemeWrapper wraps any Context and overlays a theme on top. Compose's MaterialTheme uses this mechanism internally when you apply a LocalContentColor or a theme override. Knowing it exists saves you from the wrong solution — changing the Activity theme globally just to style one component.

🧪 The rule of thumb that actually works

Instead of "use applicationContext when in doubt", the rule I use now:

Match the context's lifetime to the consumer's lifetime.

Consumer lives as long as the process (singleton, repository, library init) → applicationContext
Consumer lives as long as a screen (ViewModel, Adapter, custom View within an Activity) → Activity context, and make sure the consumer doesn't outlive the screen
Consumer is inside a Fragment → requireContext(), which gives you the host Activity's context

// Checklist before passing context anywhere:
// 1. How long does the receiver live?
// 2. What operations will it perform with the context?
// 3. Does its lifetime match the context's lifetime?

// If receiver is longer-lived → applicationContext
// If receiver needs UI → Activity context, manage its lifecycle

❓ The interview questions

Question 1 — Mid-level:

"What's the difference between this, applicationContext, and baseContext in an Activity?"

this — the Activity itself, which is a Context. Full UI capabilities, lifetime tied to the Activity.
applicationContext — the Application object. No UI capabilities, lives as long as the process.
baseContext — the wrapped ContextImpl inside the ContextWrapper. Rarely used directly; it's the raw context before any wrapper applies its logic. Calling baseContext from an Activity skips the Activity's own context wrapper logic — almost never what you want.

Question 2 — Senior:

"You're building an SDK that other apps will integrate. Your SDK has a singleton that needs to perform operations like loading resources and starting a background service. How do you handle Context?"

class MySdk private constructor(private val appContext: Context) {

    companion object {
        @Volatile private var instance: MySdk? = null

        fun init(context: Context): MySdk {
            return instance ?: synchronized(this) {
                instance ?: MySdk(
                    // Always store applicationContext — the caller's Activity
                    // will be destroyed; the SDK must outlive it
                    context.applicationContext
                ).also { instance = it }
            }
        }
    }

    fun loadResource(): String {
        // ✅ Resources work fine with applicationContext
        return appContext.getString(R.string.sdk_label)
    }

    fun startBackgroundWork() {
        // ✅ Starting a Service works with applicationContext
        appContext.startService(Intent(appContext, SdkSyncService::class.java))
    }

    fun showDialog(activity: Activity) {
        // ✅ For UI operations, require the caller to pass Activity explicitly
        // Don't store it — just use it for this operation
        AlertDialog.Builder(activity)
            .setMessage("SDK needs permission")
            .show()
    }
}

Key points: always store applicationContext in the singleton, never the caller's Activity. For UI operations, make them instance methods that take an Activity parameter rather than storing it.

Question 3 — Senior:

"LeakCanary reports a Context leak in your app, originating from a custom View. How do you diagnose and fix it?"

First, understand what LeakCanary is telling you: the Context (likely an Activity) is retained after it should have been garbage collected, because something is holding a reference to it.

For a custom View, the most common causes:

// Cause 1: Static reference to a View (which holds its Context)
companion object {
    var lastClickedView: View? = null  // 💀 holds Activity via view.context
}

// Cause 2: Anonymous listener registered on a long-lived object
class MyView(context: Context) : View(context) {
    init {
        EventBus.register(object : EventListener {  // 💀 anonymous class holds outer View
            override fun onEvent(event: Event) { /* ... */ }
        })
        // EventBus holds the listener, listener holds the View, View holds Context
    }
}

// Fix: use weak reference or unregister in onDetachedFromWindow
override fun onDetachedFromWindow() {
    super.onDetachedFromWindow()
    EventBus.unregister(listener)
}

// Cause 3: Context stored in a non-View object without applicationContext
class ImageCache(val context: Context) {  // 💀 if passed Activity context
    // ...
}
// Fix: ImageCache(context.applicationContext)

Diagnosis approach: read the LeakCanary reference chain bottom-up. The chain shows exactly which object is holding the reference that prevents GC. The fix is usually at the top of that chain — nulling a reference, unregistering a listener, or swapping to applicationContext.

What surprised me revisiting this

applicationContext for LayoutInflater doesn't just look wrong — it silently breaks theme-dependent attributes without throwing an exception. Views inflate but render incorrectly. The kind of bug that shows up in screenshots and is hard to reproduce in isolation.
WeakReference<Context> is a false sense of security. I've written this pattern before and thought I was being careful. Going back through the theory, it just moves the problem rather than fixing it.
ContextThemeWrapper being the mechanism behind Compose's LocalContentColor — I'd used Compose theme overrides for months without ever connecting it to the View system's ContextThemeWrapper. The mental model clicked when I saw them as the same concept.

Tomorrow

Day 7 → Week 1 Recap — six posts in, and I'm already finding more gaps than I expected. A summary of the most important insights from this week, plus the one question I couldn't answer confidently until now.

What's the most surprising Context-related bug you've encountered? Drop it in the comments.

← Day 5: Intent, Task & Back Stack — Why launchMode Is a Trap

Day 5/100: Intent, Task & Back Stack and Why launchMode is a trap

Hoang Son — Mon, 30 Mar 2026 08:04:42 +0000

This is Day 5 of my 100 Days to Senior Android Engineer series. Each post: what I thought I knew → what I actually learned → interview implications.

🔍 The concept

When a user opens your app, taps through several screens, and then presses Back — Android needs to know where to go. That navigation history lives in a Task, which is essentially a stack of Activities managed by the OS.

Most developers use Intents and navigate between Activities for years without ever thinking deeply about Tasks. That works — until you get a bug report that says:

"When I tap the notification, it opens a blank screen instead of the detail screen."
"After I share something from my app, pressing Back takes the user to our app's home screen instead of the sharing sheet."
"We have two instances of the same Activity open and I don't know why."

All three of these are Task and back stack bugs. And they're famously hard to reproduce because they depend on navigation history that you can't easily control in tests.

💡 What I thought I knew

My mental model was simple: Back Stack = list of screens, Back button = pop the top screen. launchMode existed for edge cases. Intents had flags for special situations.

I'd used FLAG_ACTIVITY_CLEAR_TOP and singleTop a few times, copy-pasted from Stack Overflow, and moved on.

That approach works until it spectacularly doesn't.

😳 What I actually learned

A Task is an OS-level concept, not an app concept

Tasks are owned by the Android system, not by your app. Your app doesn't control how many Tasks exist. The user — through their navigation history — does.

User flow that creates TWO tasks:

Task 1 (your app):
  [HomeActivity] → [ProductActivity] → [CheckoutActivity]

User opens Chrome, taps a deep link into your app:

Task 2 (from Chrome):
  [ProductActivity]   ← same Activity class, different Task

Two instances of ProductActivity exist simultaneously in two different Tasks. The Back button behavior differs between them because they belong to different navigation histories.

This is expected and correct Android behavior. The problem is when your launchMode settings interfere with it.

`launchMode` — what each value actually does

<!-- Default — new instance every time -->
<activity android:launchMode="standard" />

<!-- Reuse existing instance if it's at the TOP of the stack -->
<activity android:launchMode="singleTop" />

<!-- Only one instance per Task -->
<activity android:launchMode="singleTask" />

<!-- Only one instance in the entire system, in its own Task -->
<activity android:launchMode="singleInstance" />

On paper, this sounds useful. In practice:

singleTop is the only one worth using regularly. Perfect for notification tap targets — prevents stacking duplicate instances when the user taps multiple notifications quickly.

singleTask is where most bugs live. When Android reuses a singleTask Activity, it clears everything above it in the back stack. The whole stack. Not just the top.

Back stack before user taps notification:
[Home] → [List] → [Detail] → [Settings]
                                ↑ user is here

Notification tap targets Detail (singleTask):
[Home] → [Detail]
                ↑ List and Settings are GONE

If you've ever seen "pressing Back after tapping a notification takes me to Home instead of the previous screen" — this is why.

singleInstance is almost never the right answer in a modern app. It creates its own isolated Task, which breaks the user's navigation model in ways that are hard to predict and harder to debug.

Intent flags — the lower-level control

Intent flags give you per-launch control instead of per-Activity declaration. They're more surgical than launchMode.

// The three flags you'll actually use:

// 1. If the Activity exists in the stack, bring it to front and clear above it
intent.flags = Intent.FLAG_ACTIVITY_CLEAR_TOP or Intent.FLAG_ACTIVITY_SINGLE_TOP

// 2. Start fresh — clear the entire back stack (used for logout)
intent.flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK

// 3. Don't create a new Task even if launched from outside the app
intent.flags = Intent.FLAG_ACTIVITY_REORDER_TO_FRONT

The one combination every Android dev should know by heart:

// Logout — clear everything and start fresh
fun logout() {
    val intent = Intent(this, LoginActivity::class.java).apply {
        flags = Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TASK
    }
    startActivity(intent)
    // No finish() needed — CLEAR_TASK handles it
}

FLAG_ACTIVITY_NEW_TASK or FLAG_ACTIVITY_CLEAR_TASK starts the target Activity in a new Task after clearing any existing Task for your app. This is the correct logout implementation — not finishAffinity(), not a chain of finish() calls.

Deep links and the Task problem

Deep links are where Task management gets genuinely complex.

When a user taps a deep link from another app (browser, email, messaging), Android can handle it two ways:

Scenario A — App is not running:
  New Task created → deep link destination shown
  User presses Back → where do they go?

Scenario B — App IS running with existing back stack:
  Does Android resume existing Task or create new one?
  Depends on launchMode + flags + TaskAffinity

The correct approach for deep links is to use TaskStackBuilder to construct a synthetic back stack:

// When handling a deep link to a detail screen,
// build the back stack the user would have navigated through naturally
val stackBuilder = TaskStackBuilder.create(context).apply {
    // Add the parent chain
    addNextIntentWithParentStack(
        Intent(context, DetailActivity::class.java).apply {
            putExtra("item_id", itemId)
        }
    )
}
stackBuilder.startActivities()

This creates:

[HomeActivity] → [ListActivity] → [DetailActivity]

So when the user presses Back from the deep-linked Detail screen, they get a logical navigation history — not a blank Home screen or an exit from the app.

With Jetpack Navigation, deep link handling is automatic when you declare your deep links in the nav graph. The library builds the synthetic back stack for you.

`taskAffinity` — the setting nobody talks about

Every Activity has a taskAffinity — by default, it's your app's package name. This is what Android uses to decide which Task an Activity "belongs to".

This setting is almost never explicitly configured, and that's usually fine. But it's responsible for a class of bugs that are nearly impossible to diagnose without knowing it exists.

<!-- This Activity will try to live in a different Task -->
<activity
    android:name=".ShareReceiverActivity"
    android:taskAffinity="com.yourapp.sharing"
    android:launchMode="singleTask" />

If you combine a custom taskAffinity with singleTask, the Activity will always land in its own dedicated Task. Useful for share targets or widgets that should be isolated from the main app flow. Dangerous if done accidentally.

🧪 The mental model that stuck

A decision tree for navigation decisions:

Need to navigate normally?
  → startActivity() with no flags. Default launchMode. Done.

Tapping a notification that targets a screen that might already be open?
  → singleTop on the target Activity.

Logging out or resetting app state?
  → FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TASK

Deep linking into a nested screen?
  → TaskStackBuilder (manual) or Jetpack Navigation deep links (automatic)

Need only one instance of a screen per Task?
  → singleTask, but document WHY and test the back stack carefully

Need a completely isolated screen (PiP, share target)?
  → singleInstance + custom taskAffinity, and be very intentional about it

The default answer to "should I change launchMode?" is almost always no. The Navigation Component and ViewModel handle the scenarios that historically required launchMode hacks, and they do it without the back stack side effects.

❓ The interview questions

Question 1 — Mid-level:

"What's the difference between FLAG_ACTIVITY_CLEAR_TOP and FLAG_ACTIVITY_CLEAR_TASK?"

CLEAR_TOP clears all Activities above the target in the current Task and brings the target to the front. The Activities below the target survive.

CLEAR_TASK destroys the entire Task first, then starts the target fresh. Nothing survives. Usually paired with NEW_TASK.

// CLEAR_TOP: [Home] → [List] → [Detail] → [Settings]
// Navigate to List with CLEAR_TOP:
// Result: [Home] → [List]

// CLEAR_TASK: same back stack
// Navigate to Login with CLEAR_TASK | NEW_TASK:
// Result: [Login]  ← completely fresh

Question 2 — Senior:

"A user taps a push notification for an order status update. Your app may or may not be running. The user might be on any screen. How do you ensure they land on the OrderDetailActivity with a correct back stack regardless of app state?"

// In your notification handler (FirebaseMessagingService or NotificationReceiver)
fun showOrderNotification(orderId: String) {
    val detailIntent = Intent(context, OrderDetailActivity::class.java).apply {
        putExtra("order_id", orderId)
        // Ensure we handle both app running and not running
        flags = Intent.FLAG_ACTIVITY_SINGLE_TOP
    }

    val pendingIntent = TaskStackBuilder.create(context).run {
        addNextIntentWithParentStack(detailIntent)
        getPendingIntent(
            orderId.hashCode(),
            PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
        )
    }

    val notification = NotificationCompat.Builder(context, CHANNEL_ID)
        .setContentIntent(pendingIntent)
        .setAutoCancel(true)
        // ...
        .build()

    notificationManager.notify(orderId.hashCode(), notification)
}

TaskStackBuilder synthesizes the back stack so the user can press Back naturally. FLAG_ACTIVITY_SINGLE_TOP prevents duplicate instances if the Activity is already on top. The hashCode() of orderId as the notification ID ensures multiple order notifications don't replace each other.

Question 3 — Senior / Architecture:

"Your team wants to migrate from multiple Activities to a single-Activity architecture with Jetpack Navigation. What happens to your back stack management, deep links, and notification handling?"

Single-Activity means the OS back stack now contains just one (or very few) Activities. Back stack management moves entirely into the Navigation Component's NavBackStack, which handles:

Fragment transactions as navigation actions
popUpTo / inclusive replacing FLAG_ACTIVITY_CLEAR_TOP
launchSingleTop on nav actions replacing singleTop launchMode
<deepLink> in nav graph replacing TaskStackBuilder manual setup

The tradeoff: you gain simplicity and predictability. You lose fine-grained OS-level Task control. For most apps, that's the right trade.

<!-- Navigation graph replaces launchMode and Intent flags -->
<action
    android:id="@+id/action_to_home"
    app:destination="@id/homeFragment"
    app:popUpTo="@id/nav_graph"
    app:popUpToInclusive="true"
    app:launchSingleTop="true" />

What surprised me revisiting this

I'd been using singleTask in a notification scenario for years without fully understanding that it clears the back stack above the target. It worked in our tests because we always tapped the notification from the home screen. It would have broken for any user mid-flow.
TaskStackBuilder for notifications is shockingly underused. Most notification implementations I've seen in the wild use a simple PendingIntent with no back stack construction. Users tap the notification and Back exits the app. That's a bad UX that's trivially fixable.
The Navigation Component genuinely removes the need for 90% of launchMode usage. I knew this conceptually, but going back through the docs made it concrete. Every singleTop and CLEAR_TOP use case has a clean Navigation Component equivalent.

Tomorrow

Day 6 → Context in Android — Application, Activity, Service: why using the wrong one causes memory leaks and crashes, and a rule of thumb that's served me well for years.

Have you ever shipped a singleTask bug that cleared a back stack unexpectedly? I definitely have. Tell me in the comments.

← Day 4: Fragment Lifecycle — Why It's More Confusing Than Activity's

Day 4/100: Fragment Lifecycle — Why It's More Confusing Than Activity's

Hoang Son — Sun, 29 Mar 2026 16:54:58 +0000

This is Day 4 of my 100 Days to Senior Android Engineer series. Each post: what I thought I knew → what I actually learned → interview implications.

🔍 The concept

If you thought Activity Lifecycle was tricky, Fragment Lifecycle is trickier — because a Fragment doesn't have one lifecycle. It has two.

The Fragment lifecycle — tied to when the Fragment is attached to its host
The Fragment View lifecycle — tied to when the Fragment's UI exists

They run in parallel, they start and end at different times, and confusing one for the other is responsible for a surprising number of memory leaks and NullPointerException crashes in production Android apps.

💡 What I thought I knew

I used to think Fragment Lifecycle was basically Activity Lifecycle with extra steps. onCreate, onStart, onResume, onPause, onStop, onDestroy — with a few Fragment-specific callbacks like onAttach and onCreateView sprinkled in.

That model gets you through most work. Until it doesn't.

😳 What I actually learned

The full Fragment lifecycle has 9 callbacks, not 6

onAttach()        ← Fragment attached to Activity
onCreate()        ← Fragment created (no view yet)
onCreateView()    ← View inflated
onViewCreated()   ← View ready to use ✅ best place for view setup
onStart()
onResume()
onPause()
onStop()
onDestroyView()   ← View destroyed (Fragment still alive!)
onDestroy()
onDetach()        ← Fragment detached from Activity

The critical pair that most tutorials gloss over: onCreateView() / onDestroyView().

The Fragment itself can be alive while its View is destroyed. This happens every time you navigate away from a Fragment in a back stack — the Fragment instance is retained, but its View is torn down and rebuilt when you navigate back.

The two lifecycles visualized

Fragment added to back stack, user navigates away:

Fragment lifecycle:    CREATED ──────────────────────────────── CREATED
                        │                                          │
View lifecycle:        CREATED ── STARTED ── RESUMED ── PAUSED ── STOPPED ── DESTROYED
                                                                              ↑
                                                              View gone, Fragment alive

When the user navigates back:

Fragment lifecycle:    CREATED (same instance, uninterrupted)
                        │
View lifecycle:        CREATED (brand new View) ── STARTED ── RESUMED

Same Fragment, new View. Every time.

The leak that this causes

Here's a pattern I've seen in real codebases — it looks completely reasonable:

class UserProfileFragment : Fragment() {
    // 💀 Storing View binding at Fragment scope
    private var binding: FragmentUserProfileBinding? = null

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        binding = FragmentUserProfileBinding.inflate(inflater, container, false)
        return binding!!.root
    }

    override fun onDestroyView() {
        super.onDestroyView()
        // Most tutorials tell you to null this out here
        binding = null
    }
}

Setting binding = null in onDestroyView() looks correct. And it is necessary. But it's not sufficient if you have observers or coroutines that still hold a reference to the old binding after the view is destroyed.

The safer pattern with coroutines:

class UserProfileFragment : Fragment(R.layout.fragment_user_profile) {
    // Use viewBinding delegate — auto-nulled on onDestroyView
    private val binding by viewBinding(FragmentUserProfileBinding::bind)

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)

        // ✅ viewLifecycleOwner — scoped to the VIEW lifecycle, not the Fragment
        viewLifecycleOwner.lifecycleScope.launch {
            viewModel.uiState.collect { state ->
                binding.profileName.text = state.name
            }
        }
    }
}

The key is viewLifecycleOwner — not this (the Fragment), not viewLifecycleOwner.lifecycle, but viewLifecycleOwner as the LifecycleOwner passed to observers and coroutine scopes.

`this` vs `viewLifecycleOwner` — the mistake that causes crashes

This is the most common Fragment lifecycle bug I've seen in code reviews:

// ❌ Wrong — uses Fragment as LifecycleOwner
viewModel.uiState.observe(this) { state ->
    binding.profileName.text = state.name  // 💀 binding might be null here
}

// ✅ Correct — uses View lifecycle as LifecycleOwner
viewModel.uiState.observe(viewLifecycleOwner) { state ->
    binding.profileName.text = state.name  // safe — observer cancelled when view dies
}

When you pass this (the Fragment) as the LifecycleOwner, the observer stays active even after onDestroyView(). The Fragment is still STARTED. So when uiState emits a new value while the View doesn't exist, your observer fires and tries to update binding — which is null. Crash.

When you pass viewLifecycleOwner, the observer is automatically cancelled when the View is destroyed. No null check needed. No crash.

The callback where I always initialize views wrong

onCreateView() vs onViewCreated() — which one do you use to set up click listeners and observers?

// ❌ Common but suboptimal
override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
): View {
    val binding = FragmentUserProfileBinding.inflate(inflater, container, false)
    // Setting up UI logic here — works, but mixes concerns
    binding.button.setOnClickListener { /* ... */ }
    return binding.root
}

// ✅ Correct separation
override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
): View {
    // ONLY inflate and return — nothing else
    _binding = FragmentUserProfileBinding.inflate(inflater, container, false)
    return _binding!!.root
}

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    // ALL view setup goes here — binding is guaranteed non-null
    binding.button.setOnClickListener { /* ... */ }
    observeViewModel()
}

onViewCreated() is called immediately after onCreateView() with the view already inflated and attached. It's the right place for view setup because the view is guaranteed to exist, and using viewLifecycleOwner here is unambiguous.

Fragment-to-Fragment communication the right way

One more pattern that trips up mid-to-senior level devs: how Fragments should talk to each other.

// ❌ Fragment directly referencing sibling Fragment
class DetailFragment : Fragment() {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        // Getting sibling Fragment — tightly coupled, breaks on backstack changes
        val listFragment = parentFragmentManager
            .findFragmentById(R.id.list_fragment) as? ListFragment
        listFragment?.updateSelection(itemId)  // 💀 might be null
    }
}

// ✅ Communicate through shared ViewModel
class DetailFragment : Fragment() {
    // Scoped to Activity — shared with ListFragment
    private val sharedViewModel: SharedViewModel by activityViewModels()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        binding.button.setOnClickListener {
            sharedViewModel.selectItem(itemId)  // ListFragment observes this
        }
    }
}

Fragments should never hold direct references to sibling Fragments. The ViewModel is the bus.

🧪 The mental model that stuck

Two rules that cover 90% of Fragment lifecycle issues:

Rule 1: View setup goes in onViewCreated(), never in onCreateView().
onCreateView() inflates. onViewCreated() configures. One job each.

Rule 2: Anything that touches views uses viewLifecycleOwner, not this.
Observers, coroutine scopes, anything that can fire after the view is gone — always scope it to viewLifecycleOwner.

Fragment alive?     → use lifecycleScope (this)
View alive?         → use viewLifecycleOwner.lifecycleScope

When in doubt, ask: "If the user navigates away and back, will this still work correctly?" If you're using this as a lifecycle owner for view-touching code, the answer is probably no.

❓ The interview questions

Question 1 — Mid-level:

"What's the difference between lifecycleScope and viewLifecycleOwner.lifecycleScope in a Fragment?"

lifecycleScope is scoped to the Fragment's lifecycle — it's cancelled when the Fragment is destroyed. viewLifecycleOwner.lifecycleScope is scoped to the View's lifecycle — cancelled when the View is destroyed, which happens earlier when navigating in a back stack. For anything that interacts with views, always use the latter.

Question 2 — Senior:

"A Fragment is added to the back stack. The user navigates to a new Fragment, then presses Back. Walk me through exactly what happens to both lifecycles."

User navigates away:
  Fragment:   onPause → onStop → onDestroyView   (Fragment stays CREATED)
  View:       fully destroyed

User presses Back:
  Fragment:   onCreateView → onViewCreated → onStart → onResume  (same instance)
  View:       brand new View created from scratch

Follow-up the interviewer will likely ask: "So what does that mean for data you stored as view state vs instance state?"

View state (scroll position, text in EditText with android:saveEnabled="true") — lost unless you explicitly save it. Instance state (data in ViewModel, SavedStateHandle) — preserved.

Question 3 — Senior / System Design:

"How would you design Fragment communication in an app with 10+ Fragments across 3 feature modules?"

Each feature module has its own ViewModel scoped to its navigation graph. Fragments within a feature communicate through that ViewModel via navGraphViewModels(). Cross-feature communication goes through the Activity-scoped ViewModel or a shared data layer (repository + StateFlow) that both feature ViewModels observe. Fragments never reference each other directly.

// Scoped to nav graph — shared within a feature
private val featureViewModel: FeatureViewModel by navGraphViewModels(R.id.feature_graph)

// Scoped to Activity — shared across features
private val appViewModel: AppViewModel by activityViewModels()

What surprised me revisiting this

I've been writing Fragments for years. Going back carefully, two things stood out:

I still occasionally write observe(this) out of habit. It's the kind of mistake that doesn't crash immediately — it only crashes in specific navigation patterns. Easy to miss in code review if you're not specifically looking for it.
The Fragment constructor with layout ID — Fragment(R.layout.fragment_user_profile) — means you can skip overriding onCreateView() entirely for most Fragments. I'd been overriding it by default for years without thinking about whether I needed to.

Tomorrow

Day 5 → Intent, Task and Back Stack — how Android manages navigation at the OS level, and why launchMode causes more bugs than it solves.

Have you ever shipped a viewLifecycleOwner bug to production? I have. Drop your story in the comments.

← Day 3: Activity Lifecycle — The Diagram You've Seen 100 Times

Day 3/100: Activity Lifecycle — The Diagram You've Seen 100 Times

Hoang Son — Sat, 28 Mar 2026 00:46:50 +0000

This is Day 3 of my 100 Days to Senior Android Engineer series. Each post: what I thought I knew → what I actually learned → interview implications.

🔍 The concept

Every Android developer has seen this diagram:

          onCreate()
              ↓
          onStart()
              ↓
          onResume()  ←──────────────────────┐
              ↓                              │
         [Activity running]                  │
              ↓                              │
          onPause()                          │
              ↓                         onRestart()
          onStop()   ──────────────────────→ │
              ↓
          onDestroy()

You could draw this in your sleep. I certainly could.

The problem is that this diagram shows the happy path. It doesn't show what happens in the three scenarios that actually matter in production — and that every senior interview will eventually probe.

💡 What I thought I knew

My mental model was: callbacks fire in a predictable sequence, each one is the right place to do certain things (init in onCreate, release in onDestroy), and as long as I follow the pattern, everything works.

That model is mostly right. Mostly.

😳 What I actually learned

The diagram has a ghost: the back stack

The standard diagram shows a single Activity in isolation. But your app never has just one Activity in isolation — it has a back stack, and the lifecycle behaves differently depending on why a callback fires.

Consider onStop(). It gets called in two very different situations:

Situation A: User presses Home
    → Activity goes to background
    → onPause() → onStop()
    → Activity is still in memory (probably)
    → User comes back → onRestart() → onStart() → onResume()

Situation B: User navigates to another Activity
    → Current Activity partially covered
    → onPause() → onStop()
    → User presses Back → onRestart() → onStart() → onResume()

Situation C: System kills the process (low memory)
    → onPause() → onStop() → [process killed, no onDestroy()]
    → User comes back → onCreate() with savedInstanceState Bundle

Situation C is the one that breaks apps. onDestroy() is not guaranteed to be called. If you're releasing resources, closing connections, or saving state in onDestroy(), you have a bug waiting to happen under memory pressure.

The configuration change trap

Rotate the screen. What happens?

onPause()
onStop()
onDestroy()   ← called this time, because it's a controlled teardown
onCreate()    ← brand new instance
onStart()
onResume()

The Activity is destroyed and recreated. Which means:

Any data stored in instance variables is gone
Any network request in flight is cancelled (if tied to the Activity's scope)
Any UI state that isn't explicitly saved is reset

Here's a pattern I've seen in codebases more than I'd like:

class ProfileActivity : AppCompatActivity() {
    private var userProfile: UserProfile? = null  // 💀 gone on rotation

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // Fetch every time, including on rotation
        fetchUserProfile()
    }

    private fun fetchUserProfile() {
        // Network call fires again on every rotation
        viewModel.loadProfile(userId)
    }
}

The fix isn't complicated — it's using ViewModel correctly:

class ProfileActivity : AppCompatActivity() {
    // ViewModel survives configuration changes
    private val viewModel: ProfileViewModel by viewModels()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        // ViewModel already has data if we're recreating after rotation
        // loadProfile() is called inside ViewModel's init{} or handled idempotently
        observeViewModel()
    }
}

The ViewModel survives configuration changes because it's scoped to the ViewModelStore, which is retained across recreations. The Activity is recreated; the ViewModel is not.

onPause() is your last guarantee

This is the one that surprises the most people.

onPause() is the only callback guaranteed to be called before your process can be killed.

Not onStop(). Not onDestroy(). Just onPause().

From the docs:

"If the system needs to recover memory in an emergency, it might not call onStop() and onDestroy()."

This has a direct consequence on where you save critical state:

override fun onPause() {
    super.onPause()
    // ✅ Save anything critical HERE — this is your last guaranteed checkpoint
    saveDraftMessage()
    releaseCamera()  // release exclusive resources here, not in onStop
}

override fun onStop() {
    super.onStop()
    // ✅ Safe for non-critical cleanup that can tolerate being skipped under pressure
    stopLocationUpdates()
}

override fun onDestroy() {
    super.onDestroy()
    // ✅ Cleanup that you'd expect in a clean shutdown
    // ❌ Do NOT rely on this for anything critical
}

There's also a performance implication: onPause() blocks the transition to the next Activity. Anything slow in onPause() directly delays how quickly the new screen appears. Keep it fast.

The two-Activity transition sequence

This is a classic interview question, and the answer is not what most people expect.

What's the callback order when Activity A starts Activity B?

// Most people answer:
A.onPause()
A.onStop()
B.onCreate()
B.onStart()
B.onResume()

// Actual order:
A.onPause()       ← A pauses FIRST
B.onCreate()      ← B starts creating
B.onStart()
B.onResume()      ← B is now visible
A.onStop()        ← A stops AFTER B is running

A.onStop() comes after B.onResume(). This matters because it means A is still technically "paused but not stopped" while B initializes. If you're holding an exclusive resource (camera, audio focus) and releasing it in onStop() instead of onPause(), Activity B will try to acquire it before you've released it.

🧪 The mental model that stuck

Instead of memorizing the diagram, I now ask two questions for each callback:

1. Can this be the last callback that runs?

Callback	Can be last before kill?
`onPause()`	✅ Yes — save critical state here
`onStop()`	⚠️ Usually, but not guaranteed
`onDestroy()`	❌ Not guaranteed

2. How many times will this run in a session?

Scenario	`onCreate`	`onResume`
Normal launch	1×	1×
Home → Back to app	1×	2×
Rotate screen	2×	2×
Rotate 3 times	4×	4×

If you're doing expensive initialization in onResume() instead of onCreate(), every rotation and every return from background triggers it again. That's a real performance bug in disguise.

❓ The three interview questions

Question 1 — Basic:

"When does onDestroy() get called, and can you rely on it always being called?"

No. Under memory pressure, the process is killed without onDestroy(). Save critical state in onPause().

Question 2 — Mid-level:

"A user starts filling out a form, receives a phone call, and comes back. How do you ensure their input is preserved?"

// Option A: ViewModel (survives configuration change, lost on process death)
class FormViewModel : ViewModel() {
    val formState = MutableStateFlow(FormState())
}

// Option B: onSaveInstanceState (survives process death, limited to Bundle size)
override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString("draft_input", binding.editText.text.toString())
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    savedInstanceState?.getString("draft_input")?.let {
        binding.editText.setText(it)
    }
}

// Option C: SavedStateHandle (best of both — ViewModel + process death survival)
class FormViewModel(private val savedStateHandle: SavedStateHandle) : ViewModel() {
    var draftInput: String
        get() = savedStateHandle["draft_input"] ?: ""
        set(value) { savedStateHandle["draft_input"] = value }
}

The senior answer explains all three options, their tradeoffs, and reaches for SavedStateHandle as the modern solution — because it survives both configuration changes and process death.

Question 3 — Senior:

"Activity A launches Activity B. In Activity B, the user performs an action that should update a result visible in Activity A. How do you handle this, and what lifecycle considerations apply?"

The legacy approach — startActivityForResult() — is deprecated. The modern answer:

// In Activity A — register before onCreate completes
private val launcher = registerForActivityResult(
    ActivityResultContracts.StartActivityForResult()
) { result ->
    if (result.resultCode == RESULT_OK) {
        val data = result.data?.getStringExtra("updated_value")
        viewModel.handleUpdate(data)
    }
}

// Launch Activity B
launcher.launch(Intent(this, ActivityB::class.java))

// In Activity B — send result back
setResult(RESULT_OK, Intent().putExtra("updated_value", newValue))
finish()

The lifecycle consideration: the result callback fires during onResume() of Activity A. If you're observing a StateFlow in onStart() with repeatOnLifecycle, you don't need the callback at all — just update the ViewModel from B and let A observe the change.

What surprised me revisiting this

The lifecycle diagram gives you the what but not the why. Going back through the documentation carefully, three things stood out:

onPause() blocking — I knew it was called, but I hadn't internalized that slow onPause() directly delays the next screen appearing. I've definitely shipped code that violated this.
The two-Activity transition order — I knew A pauses before B starts, but I hadn't thought through the implication for exclusive resources until I re-read the ordering carefully.
SavedStateHandle being the real answer — I'd used onSaveInstanceState for years and ViewModel for a few more, but SavedStateHandle genuinely makes both feel like workarounds in comparison.

Tomorrow

Day 4 → Fragment Lifecycle vs Activity Lifecycle — they look similar on a diagram, and that's exactly why people keep getting them wrong.

What's a lifecycle bug you've shipped to production? Drop it in the comments — no judgment, we've all been there.

← Day 2: The 4 Android Components — What Senior Devs Get Wrong

Day 2/100: The 4 Android Components — What Senior Engineer Get Wrong

Hoang Son — Thu, 26 Mar 2026 16:22:41 +0000

This is Day 2 of my 100 Days to Senior Android Engineer series. Each post follows a consistent format: what I thought I knew → what I actually learned → interview implications.

🔍 The concept

Android has exactly four fundamental application components:

Activity — a single screen with a UI
Service — background work with no UI
BroadcastReceiver — responds to system-wide or app-wide events
ContentProvider — structured data sharing between apps

Every Android developer learns these in week one. What separates junior from senior isn't knowing the list — it's understanding the boundaries and the cost of each one.

💡 What I thought I knew

After years of building apps, my mental model was roughly:

Need a screen? → Activity (or Fragment)
Need background work? → Service
Need to react to a system event? → BroadcastReceiver
Need to share data with other apps? → ContentProvider

Simple enough. And for most day-to-day work, this is fine.

The problem is that this mental model is when to use them, not what they actually are — and the distinction matters enormously when things break.

😳 What I actually learned

Each component is a system entry point — not just a class

This is the insight that reframes everything.

When you declare a component in AndroidManifest.xml, you're not just registering a class. You're telling the Android system: "here is a door into my app." The system can open that door independently of your app's current state — even if no other part of your app is running.

This has real consequences:

User taps notification
    → System creates new Activity (entry point #1)

Device boots, BOOT_COMPLETED fires
    → System wakes your BroadcastReceiver (entry point #2)

Another app queries your ContentProvider
    → System starts your process just for the ContentProvider (entry point #3)

Your Application.onCreate() runs before all of these. Which means every entry point carries Application initialization cost — and if that initialization is slow or throws, it affects all of them.

The BroadcastReceiver trap most seniors fall into

// Registered in Manifest — looks innocent
class BootReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // DON'T do this
        val db = Room.databaseBuilder(context, AppDatabase::class.java, "db").build()
        db.someDao().doHeavyWork() // runs on main thread, no coroutine scope
    }
}

onReceive() runs on the main thread and has a hard time limit of ~10 seconds before the system ANRs. There is no coroutine scope. There is no lifecycle. The receiver is considered dead the moment onReceive() returns.

The correct pattern for anything non-trivial:

class BootReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // Hand off immediately — don't do work here
        SyncWorker.enqueue(context)
    }
}

Delegate to WorkManager and return. That's it.

Service is not what you think in 2024

Service runs on the main thread by default. Not a background thread. Not a coroutine. The main thread.

class MyService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        // This is still the main thread
        // Heavy work here = ANR
        return START_STICKY
    }
}

The distinction that matters now:

Type	Visibility	Use case
`Service` (background)	None	Legacy. Avoid on API 26+. System kills it aggressively.
`ForegroundService`	Persistent notification	Music playback, navigation, active uploads
`WorkManager`	None	Deferrable, guaranteed background work
`CoroutineWorker`	None	WorkManager + coroutines, the modern default

Since API 26 (Android 8.0), background services are killed almost immediately when your app goes to the background. If you're still using plain Service for background processing, you're relying on behavior that the system actively works against.

ContentProvider is the most misunderstood of the four

Most developers think: "I don't share data with other apps, so I don't need ContentProvider."

But here's what they're missing — ContentProvider initializes before Application.onCreate().

Process starts
    → ContentProviders init (in manifest order)
    → Application.onCreate()
    → Activity/Service/Receiver entry point

Libraries like WorkManager, Firebase, and Jetpack Startup exploit this deliberately. They ship a ContentProvider with nothing inside — just an onCreate() — to auto-initialize without requiring you to add code to your Application class.

// From Jetpack App Startup — the entire trick
class InitializationProvider : ContentProvider() {
    override fun onCreate(): Boolean {
        // Runs before Application.onCreate()
        // Perfect for library auto-init
        AppInitializer.getInstance(context!!).discoverAndInitialize()
        return true
    }
    // query, insert, etc. — all throw UnsupportedOperationException
}

If you've ever wondered how a library "just works" without any setup code — this is usually how.

🧪 The mental model that stuck

Think of each component as having a lifecycle owner and a thread contract:

Component          | Lifecycle owner      | Default thread  | Survives process death?
-------------------|----------------------|-----------------|------------------------
Activity           | User (navigates)     | Main            | No (state via Bundle)
Fragment           | Activity / BackStack | Main            | No (state via Bundle)
Service            | You (stopSelf)       | Main (!)        | Maybe (START_STICKY)
ForegroundService  | You + notification   | Main (!)        | Yes, while notif shows
BroadcastReceiver  | Single onReceive()   | Main            | No — dies immediately
ContentProvider    | Process lifetime     | Binder thread   | Yes, while process lives
WorkManager        | System scheduler     | Background      | Yes, survives reboot

When something breaks — a crash, an ANR, unexpected behavior after process death — I now ask: which entry point triggered this, and what are its thread and lifecycle contracts?

That single question resolves about 60% of the confusion.

❓ The interview question

Here's the version of this question that trips people up at the senior level:

"Your app needs to sync data when the device finishes charging. Walk me through the component choices and the tradeoffs of each approach."

The naive answer: BroadcastReceiver for ACTION_BATTERY_CHANGED.

The senior answer considers:

Is this deferrable? (Yes → WorkManager with requiresCharging(true))
What if the sync takes > 10 seconds? (Rules out BroadcastReceiver body entirely)
What if the user force-stops the app? (WorkManager handles re-scheduling; a plain Receiver doesn't)
What's the battery and data impact? (Constraints API)

val syncRequest = PeriodicWorkRequestBuilder<SyncWorker>(1, TimeUnit.HOURS)
    .setConstraints(
        Constraints.Builder()
            .setRequiresCharging(true)
            .setRequiredNetworkType(NetworkType.UNMETERED)
            .build()
    )
    .build()

WorkManager.getInstance(context).enqueueUniquePeriodicWork(
    "periodic_sync",
    ExistingPeriodicWorkPolicy.KEEP,
    syncRequest
)

The question isn't testing if you know WorkManager exists. It's testing whether you reason about constraints, reliability, and system behavior — not just "which class do I instantiate."

What surprised me revisiting this

I thought I knew these components cold. What I actually found:

I'd internalized "Service for background work" without regularly questioning whether I needed a Service at all in 2024
I'd never thought carefully about ContentProvider initialization order — and now I see it everywhere in library source code
The "entry point" framing changed how I read crash reports. When I see a crash in a component I didn't expect to be running, I now know to look for which entry point woke up the process

Tomorrow

Day 3 → Activity Lifecycle — the diagram you've seen a hundred times, and the three scenarios it doesn't show you.

Found a gap in your own understanding? Drop it in the comments — I read every one.

← Day 1: Going Back to Basics as a Senior Android Dev

Day 1/100: Going Back to Basics as a Senior Android Dev

Hoang Son — Thu, 26 Mar 2026 16:14:14 +0000

Five years.

That's how long I've been writing Android code. I've survived the transition from Java to Kotlin, from XML layouts to Jetpack Compose, from AsyncTask to Coroutines. I've shipped apps to millions of users, debugged production crashes at 2 AM, and mentored junior developers.

So why am I starting a series called "100 Days to Senior Android Engineer"?

The moment that started this

A few weeks ago, a colleague asked me something that should've been simple:

"Hey, can you explain exactly what happens to a running coroutine when the system kills our process?"

I opened my mouth. I closed it.

I knew the answer — survived state gets lost, ViewModel is gone, onSaveInstanceState is your last checkpoint. I've handled this in production code dozens of times.

But I couldn't explain the mechanism. The chain of events. The why.

That gap bothered me more than I expected.

The real reason seniors go back to basics

There's a difference between knowing how to use a tool and understanding why the tool works the way it does.

After years of solving problems under deadline pressure, I've built up a lot of "muscle memory" — patterns I reach for automatically, solutions that work but whose reasons I've forgotten. That's fine for shipping features. It's not fine when:

You're designing a system from scratch and need to reason about tradeoffs
A junior asks "why?" and you realize you don't have a satisfying answer
An interviewer digs two levels deeper than your prepared answer

The most dangerous knowledge is the kind that feels solid but has invisible gaps underneath.

What this series is (and isn't)

This is not a beginner's guide to Android. I'm not going to explain what an Activity is.

This is a senior engineer going back through every layer of Android development — from the fundamentals up to system design — with fresh eyes and a commitment to actually understanding the why behind every concept.

Over the next 100 days, I'll cover:

Phase	Days	Topics
🏗 Foundation	1–28	Android Core, Process/Memory, Kotlin, Coroutines & Flow
🏛 Architecture	29–49	Jetpack, MVVM/MVI, Clean Architecture, DI, Modularization
⚡ Compose & Perf	50–63	Jetpack Compose deep dive, Performance optimization
🧪 Testing	64–77	Testing strategy, Networking, Offline-first
🧩 Advanced	78–98	System Design, Security, Soft Skills, Interview Prep
🎯 Finale	99–100	Distilled insights from the entire journey

Every 7th day is a weekly recap — a structured summary of what I covered, what surprised me, and what questions I still have.

The format

Each daily post will follow a consistent structure:

🔍 The concept
💡 What I thought I knew
😳 What I actually learned (the interesting part)
🧪 Code example or mental model
❓ Interview question this maps to

Some posts will be short and punchy. Others — like the ones on Coroutines, Compose recomposition, or System Design — will be longer deep dives.

I'll write about real gaps I discovered, not just textbook summaries. If I already know something cold, I'll say so and move on quickly. If something surprised me, I'll spend more time on it.

Why I'm publishing this publicly

Accountability, mostly.

But also because I've learned that teaching forces clarity. The moment I try to write about something, I discover exactly where my understanding breaks down. Every post in this series is a forcing function.

And if someone else finds it useful — even better.

A note on language

I'm Vietnamese, and some of this material I'll also share in Vietnamese communities. But for Dev.to, everything will be in English, because the technical concepts deserve precise language and I want to think carefully about how to express them.

What's next

Day 2 → The 4 fundamental building blocks of Android — and a question about BroadcastReceiver that trips up more seniors than juniors.

If you've been writing Android for a few years and want to audit your own understanding, follow along. I'd genuinely love to hear where your gaps are — drop them in the comments and I might make them a future post.

This is Day 1 of my 100 Days to Senior Android Engineer series. I publish 3–4 times per week — follow me on Dev.to so you don't miss a day.

9 Pro Tips to Truly "Tame" Claude for Coding – Turn It Into a Real Engineering Partner

Hoang Son — Thu, 18 Dec 2025 09:40:51 +0000

Hey folks, I'm Shawn. I've been a software engineer for over 6 years, shipping production code at startups and big tech alike. In the last year, I've leaned heavily on AI coding assistants—Claude in particular—because it's one of the strongest models out there for reasoning about code.

But here's the truth: if you just throw prompts at Claude and accept the first output, you'll waste hours fixing hallucinations, cleaning up messy code, or dealing with forgotten context.

After countless sessions (and plenty of frustration), I've distilled a set of battle-tested practices that turn Claude from a "code generator" into a genuine engineering collaborator.

Here are my 9 pro tips to tame Claude and dramatically improve your coding workflow.

1. Avoid the "Goldfish Brain"

Claude loses context across chat sessions. Starting fresh every time is a productivity killer.

Fix: End every meaningful session with a "State of the Union" summary.
Prompt template:

Please write a comprehensive "State of the Union" prompt that summarizes:
1. What we achieved in this session.
2. The current state of the codebase.
3. The exact next steps we need to take.
4. Any known bugs or edge cases.

I will use this prompt to start our next session.

Copy-paste it at the beginning of your next conversation—Claude instantly remembers everything.

2. Communicate Visually – Use Claude's "Eyes"

Claude has excellent computer vision capabilities. Stop describing UI bugs or schemas in long paragraphs.

Prompt template:

[Uploads screenshot of the broken mobile navbar]

Look at the attached screenshot. The 'Sign Up' button is overlapping with the logo on iPhone screens.
Here is my current Tailwind CSS code for the navbar.
Based on the visual evidence, tell me exactly which classes to change to fix the alignment.

Just screenshot it.

Screenshot the UI with annotations
Paste full-colored error logs
Share DB schema diagrams instead of raw SQL

The results are far more accurate.

3. The Stop Rule – Force Clarifying Questions

Prevent Claude from assuming your tech stack, versions, or business logic.

Prompt template:

I want to build a web scraper to track prices on Amazon.

Before you write any code:
1. Ask me 3 questions about the scale (how many products?).
2. Ask about anti-bot detection requirements.
3. Ask about where we are storing the data.

Do not assume I want to use Selenium or Python. Ask first.

4. Play RPG with the AI

Claude tends to take the path of least resistance. Force it to present options like an RPG menu.

Prompt template:

This PostgreSQL query for the 'User Dashboard' takes 3 seconds to run. It needs to be faster.

Please analyze the query and provide 3 options:
[Option 1]: Quick fix (Index optimization).
[Option 2]: Clean Code (Refactoring the joins/subqueries).
[Option 3]: Over-engineered (Materialized views or caching strategy).

Wait for my selection.

5. Mine Diamonds After the Storm

After a grueling 2–3 hour debugging marathon, don't just celebrate "it's fixed." That's your golden window for process improvement.

Prompt template:

Okay, we finally fixed the database connection refused error. 
It was a race condition in the docker-compose startup order.
Don't just move on. Please analyze precisely WHY this happened and explain the 'wait-for-it' script solution we implemented. 
I want to understand the root cause so I don't face this again.

Habit: Always reflect and generalize the lesson into a reusable rule in a Troubleshooting_Tips.md file.

6. Generalize Every Insight

Fixed a specific bug? Great—but don't stop there.

Context: You found out that useEffect was causing an infinite loop due to an object dependency.

Prompt template:

You were right—the infinite loop was caused by passing a new object reference to the `useEffect` dependency array on every render.

Please generalize this finding. Create a generic entry for my `Troubleshooting_Tips.md` titled "React useEffect Pitfalls: Object References".
Format it with:
- The Problem Pattern
- The Solution (useMemo or primitive values)
- A code snippet example.

7. Reuse Hard-Won Knowledge

Next time you hit a similar issue—don't start from zero.

Opening prompt:

[Uploads 'Troubleshooting_Tips.md']

I am about to configure the API routes for a new Next.js project.
Read my attached `Troubleshooting_Tips.md` file first.
Check rule #5 regarding "CORS configurations in Vercel" and tell me exactly how to apply it to this new `next.config.js` file so I don't run into that issue again.

8. Reverse Thinking – Force Claude to Be the Tester First (TDD Style)

Facing complex logic? Don't let Claude jump straight to implementation.

Pro move: Make it write comprehensive tests first.

I need to write a Python function `calculate_shipping(weight, destination, is_prime_member)`.

First, write a set of `pytest` cases that cover:
1. Standard domestic shipping.
2. Heavy items (>50lbs) surcharge.
3. International shipping to excluded countries (should raise error).
4. Prime member free shipping edge cases.

I will approve the tests before you implement the logic.

With solid test cases approved upfront, generating correct implementation code often takes fewer than 10 regenerations.

9. True TDD Workflow with Claude

Context: Creating a new Redux slice for a shopping cart.

Prompt template:

I need to create a Redux toolkit slice for a `ShoppingCart`.

DO NOT write the slice yet.
First, write the unit tests for the reducer logic:
- Adding an item that already exists (increment quantity).
- Removing the last item (remove from array).
- Handling negative quantities (should not be possible).

Once these tests are ready, I'll paste them into my editor, and you will write the code to pass them.

This produces dramatically cleaner, more reliable code.

Final Thoughts

Apply these 9 practices consistently, and Claude evolves from a hit-or-miss code monkey into a thoughtful, reliable engineering partner—one that thinks deeply, rarely hallucinates, remembers long-term context, and helps you ship cleaner code faster.

I've seen my iteration speed double and bug rates drop significantly since adopting this mindset.

What other tricks do you use to get the most out of Claude (or other coding AIs)? Drop them in the comments—I’m always learning! 🚀

Mastering JSON Prompts: Elevating Your AI Workflow as an Engineer

Hoang Son — Wed, 29 Oct 2025 11:12:33 +0000

Hey folks, I'm Shawn, if you've spent any time wrangling APIs or parsing data in mobile apps, you know JSON is the backbone of structured communication. But what if we flipped the script and used JSON not just for data exchange, but to instruct AI models with precision? That's the power of JSON prompting – a technique that's transformed how I approach automation in my daily grind. In this post, I'll walk you through why it's a game-changer, how to build effective ones, and some real-world examples tailored to mobile development. Whether you're building banking features or optimizing user flows, this can save you hours of trial-and-error with AI tools.

Why JSON Prompts Beat Conversational Chitchat

In the fast-paced world of app development, especially when dealing with sensitive data like in financial services, vagueness is the enemy. Traditional prompts to AI – like "Generate a login flow for my Android app" – often spit out inconsistent or overly generic code. JSON prompts flip this by enforcing structure, much like how we define schemas for Retrofit API calls or Room databases.

Here's why I've made them a staple:

Predictable Outputs: Specify exact fields, rules, and formats, reducing the "AI lottery" where one run works and the next flops.
Scalability for Teams: Easy to reuse and tweak, just like templating JSON configs in your build.gradle or shared preferences.
Efficiency in Production: Cuts down on API costs by minimizing retries, and ensures outputs integrate seamlessly into tools like Gson for parsing.
Edge Over Basics: While others drown in mediocre AI-generated code, you build reliable systems – think automated UI component generators that always adhere to Material Design guidelines.

From my experience, this approach has helped streamline everything from prototyping network requests to generating test data sets, turning AI into a reliable co-pilot rather than a wildcard.

Structuring Your JSON Prompts: The Blueprint Approach

Think of a JSON prompt as a well-defined interface contract for your AI. Start simple, then layer in details. Here's a step-by-step:

Define Your Objective Clearly: Be explicit. Instead of "Help with mobile auth," say "Generate a secure authentication flow for an Android banking app."
Break It Down into Keys and Values: Identify components as JSON fields. Use arrays for lists, objects for nested structures.
Add Instructions and Constraints: Include rules like tone, length, or compliance (e.g., GDPR-friendly for user data handling).
Wrap with AI Directives: Tell the AI to output in JSON format only, to keep things parseable.

A basic template might look like this:

{
  "task": "GenerateAndroidAuthFlow",
  "appContext": "Banking app with biometric login",
  "requirements": [
    "Support fingerprint and PIN",
    "Handle offline scenarios",
    "Integrate with Firebase Auth"
  ],
  "outputFormat": {
    "steps": [],
    "codeSnippet": "",
    "potentialIssues": []
  },
  "instructions": "Output must be valid JSON. Focus on Kotlin code for modernity."
}

Feed this to an AI like Grok or ChatGPT, and you'll get a structured response ready to copy-paste into Android Studio.

Real-World Examples in Mobile Development

Let's dive into examples I've adapted from my workflow. These are inspired by common mobile challenges, showing how JSON prompts can generate actionable outputs.

Example 1: Generating a REST API Response Handler

For handling JSON responses in an Android app, say for fetching transaction history:

Prompt JSON:

{
  "task": "GenerateApiHandler",
  "endpoint": "/transactions",
  "responseStructure": {
    "transactionId": "string",
    "amount": "double",
    "date": "ISO8601 string",
    "status": "enum: SUCCESS, PENDING, FAILED"
  },
  "language": "Kotlin",
  "framework": "Retrofit with Gson",
  "errorHandling": "Include try-catch for network errors and JSON parsing failures",
  "outputFormat": {
    "dataClass": "",
    "retrofitInterface": "",
    "usageExample": ""
  }
}

AI Output (simplified):

{
  "dataClass": "data class Transaction(val transactionId: String, val amount: Double, val date: String, val status: String)",
  "retrofitInterface": "interface ApiService { @GET(\"/transactions\") suspend fun getTransactions(): List<Transaction> }",
  "usageExample": "viewModelScope.launch { try { val transactions = apiService.getTransactions() } catch (e: Exception) { // Handle error } }"
}

This ensures the code is consistent and ready for your ViewModel.

Example 2: UI Component Description for Accessibility

For generating accessible UI elements in a mobile app:

Prompt JSON:

{
  "task": "GenerateAccessibleButton",
  "component": "Login Button",
  "platform": "Android",
  "features": [
    "Content description for screen readers",
    "High contrast colors",
    "Touch target size compliance"
  ],
  "styleGuide": "Material 3",
  "outputFormat": {
    "xmlSnippet": "",
    "kotlinBinding": "",
    "accessibilityRationale": ""
  }
}

This could output XML for your layout and bindings, ensuring compliance without manual tweaks.

Best Practices: Lessons from the Trenches

To make JSON prompts work reliably:

Test Iteratively: Run the prompt multiple times with variations – like different API endpoints – and refine for consistency.
Keep It Modular: Use variables (e.g., placeholders like [Endpoint]) for reusability, similar to how we parameterize Dagger modules.
Handle Edge Cases: Include fields for "edgeScenarios" to stress-test, preventing crashes in production apps.
Evolve with Tools: As AI models update, tweak your prompts. I've found combining with tools like Android's Compose for UI generation amps up the value.
Avoid Overkill: Start with 5-10 fields; don't bloat it like an over-engineered fragment.

Common pitfalls? Hard-coding values makes them brittle – always parameterize. And always validate the output JSON in your app's parser to catch issues early.

Wrapping Up: Level Up Your AI Game

JSON prompting isn't just a trick; it's a mindset shift towards engineering AI interactions like we do software. In mobile dev, where data integrity and user experience are paramount, this technique has been a lifesaver for prototyping and automation. Give it a spin on your next project – you might find yourself building a library of reusable prompts that supercharge your team.

Got questions or your own twists? Drop a comment below. Let's geek out on this!

The Figma-to-n8n “Ninja Move”: Zero-Touch Asset Sync (with Chat Commands + AI Quality Checks)

Hoang Son — Sun, 31 Aug 2025 09:00:20 +0000

Hey there, design warriors and code slingers! Ever feel like you're trapped in a never-ending loop of downloading Figma assets, renaming them like a digital janitor, and shoving them into repos while praying nothing breaks? Picture this: You're knee-deep in a sprint, the designer's dropped a "quick update" bomb, and suddenly you're playing asset Tetris across Android and iOS for multiple markets. Chaos ensues—mismatched icons, pixelated nightmares, and that one guy yelling, "It works on my machine!" We've all been there, and it's about as fun as debugging IE6.

But what if I told you there's a ninja move to flip the script? Enter n8n (that's "n-eight-n," an open-source workflow automation tool that's like Zapier on steroids). We're talking zero-touch syncing of Figma assets straight to your mobile repos, triggered by a casual chat command. No more manual handoffs. Add in AI-powered quality checks, delta detection for only-what-changed efficiency, and automated pull requests (PRs) on Bitbucket. Hands-free bliss for designers, design-ops folks, and engineers alike. By the end of this tutorial, you'll have a pipeline that delivers assets across markets and platforms like a well-oiled shuriken. Let's dive in and automate the tedium out of your life.

What We’re Building

In a nutshell, we're crafting a chat-driven n8n workflow that listens for commands like "Check Figma updates for GOPH" or "Quality check all markets TDS-200." It parses your intent, exports only the relevant Figma assets for specific markets (like Philippines via GOPH or South Africa via GOSA), detects changes, optionally runs AI vision analysis for quality/duplicates, and ships updates to Android/iOS repos with auto-generated branches, commits, and PRs. Notifications hit Slack or chat, logs go to Postgres, and the whole thing can evolve into scheduled runs. It's selective, efficient, and extensible—perfect for multi-market apps.
Here's a quick ASCII diagram of the pipeline:

User Chat
   │   (“check goph tds-100”, “quality check all markets”)
   ▼
n8n Chat Trigger → LLM Intent Parser → Fallback Parser
   │         (extract: action, markets, scope, ticket → auto-branch: feature/{ticket}-{action}-{markets}-{version})
   ├── Split by Market (e.g., GOPH, GOSA, SLSA)
   │     ├─ Env Setup (dependencies bootstrap)
   │     ├─ Figma Export (market-specific config: .figmaexportrc.<market>.js)
   │     ├─ Delta Detection (Python: new/modified/deleted → JSON output)
   │     └─ [Opt-in] AI Vision Quality Check (Ollama/LLaVA: score, issues, duplicates)
   │
   └── If Changes Detected:
         ├─ Copy Assets to Origin Dir
         ├─ Android Path: SVG → VectorDrawable Conversion → Repo Checkout → Deploy Assets → Update Changelog/Version → Commit/Push → Bitbucket PR
         ├─ iOS Path (Parallel): SVG Conversion (multi-worker) → .imageset Generation → Repo Ops → Commit/Push → Optional PR
         ├─ Notifications: Slack/Chat Summary (e.g., "5 new icons shipped!")
         └─ Logging: Persist Metrics/Interactions to Postgres

Grounded Workflow Details

This isn't some hypothetical fluff—it's based on a real n8n setup I've battle-tested. We'll break it down with friendly subheads, bullets, and pseudocode to keep things digestible. The flow starts chat-driven for flexibility but can hook into cron schedules later.

Chat-Driven Intent → Filtered Execution

Everything kicks off with a chat trigger—think Slack, Discord, or even a custom webhook. Users drop commands like natural language ninjas.

Trigger Examples: "Check Figma updates for GOPH", "Quality check all markets TDS-200", "Full pipeline SLSA new_only".
Intent Parsing: An LLM (Large Language Model) node extracts key bits: action (e.g., check_updates, analyze_quality, find_duplicates, generate_report, full_pipeline), markets (GOPH for Philippines, GOSA for South Africa, SLSA for Sanlam; defaults to all if omitted), scope (new_only, modified_only, or all_assets; defaults to new_only), optional ticket (e.g., TDS-123), and auto-generates a Git branch like feature/{ticket}-{action}-{markets}-{version} (e.g., feature/TDS-100-update-goph-v1.2).
Selective Markets: Only process requested ones to save time—e.g., "check ph ticket tds-100" targets GOPH on branch feature/TDS-100-update-goph.
Fallback: If LLM parsing flakes, a simple function node with regex/string matching takes over.

Pseudocode for branch naming:
const ticket = items[0].json.ticket || '';
const action = items[0].json.action;
const markets = items[0].json.markets.join('-');
const version = getVersionFromChangelog(); // Custom func
return ticket ? `feature/${ticket.toUpperCase()}-${action}-${markets}-${version}` : 'main';

Environment + Figma Export

We set up a lightweight env for exports, pulling from specific Figma folders like Icons, Integration Logos, Pictograms, and Other.

Setup: Bootstrap Python libs (e.g., Pillow for imaging) and CLI tools like figma-export via n8n's Execute Command node. Use market-specific configs.
Export Command: Run figma-export use-config .figmaexportrc.<market>.js per market. Configs define file IDs, component IDs, and output dirs.
Secrets Handling: Store Figma access tokens in n8n Credentials or env vars like $FIGMA_TOKEN—never hardcode!

Example config snippet (sanitized):

// .figmaexportrc.goph.js
module.exports = {
  fileId: '{{$env.FIGMA_FILE_ID}}',
  token: '{{$env.FIGMA_TOKEN}}',
  output: './exports/goph',
  components: [/* array of component IDs */],
};

Delta Detection + Processing

No blind exports—detect changes to keep things lean.

Python Step: Script like getNewAssetsAndRename.py --market goph --folders "Icons,Integration Logos,Pictograms,Other" --scope new_only --chat-mode --output-json. Outputs JSON: { "new": 3, "modified": 2, "deleted": 0, "files": ["icon1.svg", ...], "timestamp": "2025-08-31" }.
Optional AI Vision: If commanded (or changes exist and opt-in), batch images to Ollama with LLaVA model. Returns { "quality_score": 0.95, "issues": ["blurry edge"], "duplicates": ["icon1 matches icon2"], "suggestions": "Sharpen borders" }.

If There Are Changes → Ship Them

Changes? Time to deploy like a boss.

Copy to Origin: Stash new assets in a central dir.
Android Path: Convert SVG to VectorDrawable via a Python script, checkout resources repo, deploy assets, bump version/changelog, commit, push, open Bitbucket PR.
iOS Path: Parallel conversion with svg2vector_enhanced.py -workers 4 -retry 3, generate .imageset folders, repo checkout, versioning, commit/push, optional PR.
Notifications: Slack summaries like "Ninja move complete: 5 assets updated for GOPH!" and chat replies.
Logging: Dump metrics (e.g., processed count, time taken) to Postgres for audits.

Prerequisites
Before we build, grab these:

Figma Stuff: Access token and file/component IDs—store in n8n Credentials or env vars like $FIGMA_TOKEN.
n8n: Self-hosted (docker-compose up) or cloud version.
Repos: Bitbucket/Git for Android/iOS resources; optional central storage (S3 or local).
Optional Extras: Python imaging libs (Pillow), node CLIs (figma-export), Ollama for local LLaVA vision model.

⚠️ Tip: Test on a staging Figma file to avoid prod mishaps.

Step-by-Step Build

Let's assemble this beast node by node in n8n. Assume you're in the workflow editor.
Trigger & Intent

Add a Chat Trigger node (or Webhook for Slack integration).
Connect to LLM Parser (e.g., OpenAI node with prompt: "Extract action, markets, scope, ticket from: {{$input.message}}").
Add Fallback Parser (Function node with JS regex for robustness).
Branch Naming: Function node to compute feature/{ticket}-{action}-{markets}-{version}. Masked example: Input "check ph tds-100" → Output branch "feature/TDS-100-check-goph-v1.0".

Market Splitting & Environment Setup

Split by Market: Use a Switch or Loop node to handle arrays (e.g., markets: ["goph", "gosa"]).
Env Setup: Execute Command: pip install pillow requests (one-time bootstrap; idempotent).

Figma Export

Per-market: Execute Command with figma-export use-config .figmaexportrc.{{$json.market}}.js.
High-level config: Defines SVG output, folders to pull.

Delta Detection

Run Python: python getNewAssetsAndRename.py --market {{$json.market}} --folders "Icons,Integration Logos,Pictograms,Other" --scope {{$json.scope}} --chat-mode --output-json.
Parse JSON output for decisions.

Optional AI Vision Analysis

If opt-in: Batch Loop over images → HTTP Request to Ollama: POST /api/generate with LLaVA prompt like "Analyze quality: score 0-1, issues, duplicates".
Non-blocking: Use Merge node to continue even if AI times out.

⚠️ Warning: Ollama needs GPU for speed; fallback to CPU if local.

Ship Changes

Copy Assets: Move files to origin dir.
Android: Execute svg_to_vector.py, Git nodes for checkout/commit/push, Bitbucket API for PR.
iOS (Enhanced): Load config JSON, run svg2vector_enhanced.py -workers 4 -retry 3, generate .imageset, Git ops, optional PR via config flag.
Update changelog: Append "Updated: [files] on [date]".

Inline tip: Use n8n's Git nodes for repo magic—set credentials securely.

Guardrails & Gotchas

Automation's great until it backfires. Here's how to ninja-proof it:

Secrets: Never log tokens; use n8n's encrypted Credentials.
Figma Limits: Batch exports (e.g., 50 components max); add Wait nodes for 429 rate limits.
Duplicates/Cache: Hash filenames or check ETags to bust caches.
Retries: Wrap long jobs in Try/Catch with exponential backoff.
Fallbacks: If AI parsing fails, default to check_updates all new_only.
Rollback: Revert commits or auto-close bad PRs via webhook.

⚠️ Gotcha: Git permissions—ensure n8n's service account has write access.

Power-Ups

Level up your ninja:

Auto-Changelogs/PRs: Generate PR bodies with asset thumbnails (base64 embeds).
Chat Scenarios: "Full pipeline" runs end-to-end; "Find duplicates" skips shipping.
Branch Strategy: Use staging branches for non-prod; merge to main post-review.
Optimizations: Add lossless compression (svgo) or LQIP (Low-Quality Image Placeholders) for previews.

Results & Impact

This setup saved my team ~10 hours weekly on asset wrangling—no more "works on my machine" drama. Fewer handoff errors mean happier designers and faster releases.

Before/After Table:

Aspect            | Manual Hell                     | Ninja Automation Heaven
------------------|--------------------------------|-----------------------------------
Time per Sync     | 1-2 hours/market               | <5 mins (background)
Error Rate        | High (mismatches, forgets)     | Low (deltas + AI checks)
Platforms         | Sequential, error-prone        | Parallel Android/iOS
Notifications     | Email chains                   | Instant Slack/chat + PRs
Scalability       | Breaks at 3+ markets           | Handles all with filtering

Screenshots? Imagine a sanitized PR with "5 new icons: [thumbnails]" and a Slack ping: "Assets ninja'd successfully!"

Minimal Importable Starter

Here's a stripped-down n8n workflow JSON snippet (import via n8n editor). Covers chat → intent → single-market export → delta → commit → PR. Replace placeholders!

{
  "nodes": [
    {
      "name": "Chat Trigger",
      "type": "n8n-nodes-base.webhook",
      "parameters": { /* webhook setup */ }
    },
    {
      "name": "Intent Parser",
      "type": "n8n-nodes-base.openAi",
      "parameters": { "prompt": "Extract from: {{$input.message}}" }
    },
    // ... Add more: Figma Export (Execute Command), Delta (Python), Git Commit, Bitbucket PR (HTTP)
    // Placeholders: {{$env.FIGMA_TOKEN}}, {{$env.REPO_URL}}, reviewers: ["@team-lead"]
  ],
  "connections": { /* Link nodes */ }
}

FAQ / Troubleshooting

401 Unauthorized? Bad Figma token—regen and update creds.
429 Rate Limit? Add delays; reduce batch size.
Git Permissions? Check service account keys.
Path Issues? Use absolute paths in scripts.
Ollama Not Found? Ensure it's running locally; fallback to no-AI.
No Changes Detected? Verify scope; clear caches.

CTA

Ready to unleash your inner asset ninja? Grab this template, import the starter into n8n, and tweak for your setup. Fork it on GitHub if you add twists like more AI smarts or platforms. Drop your customizations in the comments—let's crowdsource even better pipelines. Happy automating!

Từ Design System đến Disaster System: Một câu chuyện cười về Breaking Change

Hoang Son — Tue, 04 Mar 2025 16:10:40 +0000

Chào mọi người,

Hôm nay, tôi sẽ kể cho bạn nghe một câu chuyện có thật về việc tôi xây dựng một thư viện Design System bằng Jetpack Compose, rồi tự tay biến nó thành một "cơn ác mộng" cho các feature team trong công ty. Đây không chỉ là câu chuyện về code, mà còn là về stress, những đêm dài debug, và một bài học đắt giá pha chút hài hước để tôi không khóc thành tiếng. Nếu bạn từng làm việc với Jetpack Compose hoặc từng gây ra breaking change, hãy ngồi xuống, uống một ngụm cà phê, và cùng tôi cười vào nỗi đau này nhé!

Bắt đầu từ một giấc mơ đẹp với Jetpack Compose

Mọi chuyện bắt đầu khi tôi quyết định xây dựng một Design System bằng Jetpack Compose – công nghệ UI hiện đại, declarative, và đầy hứa hẹn của Android. Ý tưởng là tạo ra một thư viện chứa các component như button, text field, modal… để các team trong công ty có thể tái sử dụng một cách dễ dàng. Tôi tưởng tượng mình là một anh hùng: "Các bạn cứ việc gọi Composable, phần còn lại để tôi lo!" Các designer cũng rất hào hứng, liên tục gửi variant mới để tôi cập nhật thư viện. Nghe có vẻ tuyệt, đúng không? Nhưng rồi, tôi nhanh chóng nhận ra mình không phải siêu anh hùng, mà giống như một kẻ vụng về cầm cưa cắt nhầm chân mình.

Sai lầm số 1: Data Class – Tưởng bạn thân, hóa ra phản bội

Tôi dùng data class để định nghĩa các style trong Design System. Ví dụ:

data class ButtonStyle(
    val textColor: Color,
    val backgroundColor: Color
)

Rồi một ngày, designer bảo: "Thêm padding đi cho nó sang chảnh hơn!" Thế là tôi cập nhật:

data class ButtonStyle(
    val textColor: Color,
    val backgroundColor: Color,
    val padding: Dp
)

Kết quả? Crash tan nát ở phía feature team vì binary incompatibility. Tôi không biết rằng thay đổi cấu trúc data class là một "tội ác" trong API Guidelines của JetBrains. Lúc này, tôi chỉ muốn hét lên: "Padding à, mày có đáng để tao chịu cảnh này không?!"

Sai lầm số 2: "Chỉ đổi thứ tự param thôi mà, có sao đâu!"

Một lần khác, tôi "tối ưu" một hàm trong thư viện:

@Composable
fun PrimaryButton(text: String, style: ButtonStyle) { ... }

Tôi nghĩ: "Cho style lên trước cho nó quan trọng hơn đi!" Và thế là:

@Composable
fun PrimaryButton(style: ButtonStyle, text: String) { ... }

Hậu quả? JVM function signature thay đổi, các team dùng phiên bản cũ crash runtime. Tôi tưởng tượng họ nhìn lỗi mà thầm chửi: "Thằng nào làm cái hàm này vậy?!" Đúng rồi, chính tôi đây.

Sai lầm số 3: Optional Param và sự ngây thơ của tôi

Tôi từng nghĩ mình thông minh khi cố gắng giữ backward compatibility. Tôi dùng annotation @Deprecated với message rõ ràng để thông báo cho các team về những thay đổi sắp tới. Ví dụ:

@Deprecated("Use PrimaryButtonV2 instead", ReplaceWith("PrimaryButtonV2(text, style)"))
@Composable
fun PrimaryButton(text: String, style: ButtonStyle) { ... }

Tự hào lắm! Nhưng rồi tôi lại phạm một sai lầm chết người khi xử lý các optional parameter (nullable param). Theo best practice về parameter order từ Google cho Jetpack Compose:

Required parameters (bắt buộc).
Single Modifier = Modifier.
Optional parameters (tùy chọn).
(Optional) Trailing @Composable lambda. Tôi đã cố gắng tuân thủ thứ tự này. Ví dụ ban đầu tôi có:

@Composable
fun PrimaryButton(
    text: String,
    modifier: Modifier = Modifier,
    onClick: () -> Unit
) { ... }

Sau đó, designer gửi thêm variant, tôi thêm một optional param:

@Composable
fun MyButton(
    text: String,
    modifier: Modifier = Modifier,
    enabled: Boolean = true, // Optional param mới
    onClick: () -> Unit
) { ... }

Nghe thì hợp lý, vì tôi chen enabled (optional) vào trước onClick (trailing lambda), đúng theo thứ tự Google khuyến cáo. Nhưng tôi quên mất một điều: việc chen optional param vào giữa làm thay đổi JVM binary signature! Các team dùng phiên bản cũ – vốn gọi hàm theo thứ tự param cũ – crash ngay lập tức. Lẽ ra tôi nên để nguyên thứ tự cũ và tạo ra một hàm mới với param mới và giá trị default, sau đó đánh @deprecated cho hàm cũ, như thế này:

@Deprecated(
  message = "Maintained for compatibility purposes. Use another overload",
  level = level = DeprecationLevel.HIDDEN
)
@Composable
fun MyButton(
    text: String,
    modifier: Modifier = Modifier,
    onClick: () -> Unit
) { ... }

@Composable
fun MyButton(
    text: String,
    modifier: Modifier = Modifier,
    enabled: Boolean = true
    onClick: () -> Unit
) { ... }

Nhưng không, tôi đã quá tự tin và không dùng Kotlin Binary Compatibility Validator (BCV) để kiểm tra. Kết quả là hàng loạt ticket bug bay đến, kèm theo những ánh mắt nghi ngờ từ feature team.

Hậu quả: Stress và những đêm dài tự vấn

Các team bắt đầu gọi tôi là "kẻ phá hoại Design System". Mỗi lần tôi push code mới, họ lại thấp thỏm: "Liệu lần này có crash nữa không?" Tôi thì stress đến mức tối nào cũng ngồi debug, vừa code vừa tự nhủ: "Mình viết thư viện để giúp người ta mà, sao giờ mình thành nhân vật phản diện vậy trời?" Designer thì cứ gửi variant mới, còn tôi thì vừa muốn cập nhật, vừa sợ phá thêm thứ gì đó.

Và nếu tôi được làm lại hả?

Sau tất cả drama này, tôi quyết định viết bài blog để xả stress và chia sẻ kinh nghiệm xương máu. Đây là những gì tôi học được:

Đọc tài liệu chính thức: API Guidelines của JetBrains và best practice của Google không phải để trưng bày, mà để cứu bạn khỏi những sai lầm ngớ ngẩn.
Cẩn thận với data class: Nếu cần thêm property, hãy tạo class mới hoặc dùng default param thay vì sửa trực tiếp.
Không chen optional param lung tung: Thêm param mới ở cuối hàm để tránh phá binary signature, đặc biệt với Jetpack Compose.
Dùng Kotlin BCV: Công cụ này là cứu tinh để phát hiện breaking change trước khi bạn đẩy code lên production.
Giao tiếp là chìa khóa: Báo trước cho các team khi có thay đổi lớn, đừng để họ bất ngờ với crash.
Cười để sống: Khi mọi thứ rối tung, hãy tự cười vào mình một chút – ít nhất bạn sẽ không khóc.

Hiện tại, tôi đang refactor lại thư viện, áp dụng các best practice tử tế hơn, và cố gắng lấy lại niềm tin từ feature team. Nếu bạn cũng từng gây ra breaking change với Jetpack Compose (hoặc bất kỳ thứ gì khác), hãy kể tôi nghe câu chuyện của bạn nhé!

Kết luận

Design System bằng Jetpack Compose là một giấc mơ đẹp, nhưng nếu không cẩn thận, nó có thể biến thành "Disaster System". Hy vọng câu chuyện của tôi giúp bạn tránh được những cái hố tôi đã ngã (và ngã khá đau). Còn giờ thì tôi đi uống cà phê đây, vì sau tất cả drama này, tôi xứng đáng được thư giãn một chút.

Happy coding, và đừng quên: Breaking change không phải tận thế – chỉ là một bài kiểm tra xem bạn có đủ kiên nhẫn để debug hay không thôi!

Blog tiếp theo tôi sẽ nói về một số guidelines khi phát triển APIs trong một thư viện UI Design System.

Kotlin Multiplatform không thể làm được hết tất cả. Lí do chính xác để bạn nên thử nó.

Hoang Son — Mon, 11 Mar 2024 10:58:18 +0000

Nguồn: https://dev.to/piannaf/kotlin-multiplatform-can-t-do-it-all-which-is-exactly-why-you-should-try-it-1p85

Bản dịch sẽ có sai sót về lỗi chính tả hoặc ngôn phong của người dịch, các bạn nên đọc kỹ bài gốc để có thể nắm rõ hơn về kiến thức được chia sẽ trong bài.

Trước khi đi vào vấn đề, mình muốn nhấn mạnh rằng mỗi công cụ đều được thiết kế để giải quyết những bài toán nhất định, nhưng không có công cụ nào là toàn năng, có thể giải quyết hết mọi vấn đề. Nếu team của bạn đang trong giai đoạn gấp rút, hoặc nếu việc tạo ra giao diện người dùng chất lượng cao không phải là mục tiêu hàng đầu, thì các bạn có thể cân nhắc lựa chọn một nền tảng phát triển đa nền tảng từ đầu đến cuối như Xamarin, Flutter hay React Native. Sử dụng những nền tảng này, bạn có thể dễ dàng viết ứng dụng chạy trên cả Android và IOS, và hoàn thành công việc một cách nhanh chóng. 🎉!

Giờ đây, nếu bạn đã có giao diện sẵn cho ứng dụng, hoặc muốn tinh chỉnh giao diện cho phù hợp với từng nền tảng riêng biệt, bạn nên xem xét đến việc sử dụng Kotlin Multiplatform (KMP).Vì sao ư? Đơn giản là vì KMP không có UI – ít nhất là trong thời điểm hiện tại. Tuy nhiên, những gì mà nó làm được - và thực sự làm rất tốt, đó là business logic cho các ứng dụng Android và IOS.

Mặc dù tất cả các giải pháp đa nền tảng khác đều mong muốn hỗ trợ tất cả các layer của ứng dụng, nhưng chúng không thể đáp ứng đầy đủ được chúng.

Và thực tế, việc chia sẻ mã nguồn UI qua các nền tảng khác nhau không phải lúc nào cũng là điều được ưa chuộng.Thường thì sau khi hoàn thành, chúng ta sẽ phải mất nhiều lần chỉnh sửa để UI trở nên gần gũi và phù hợp với từng nền tảng, điều này sẽ tiêu tốn khá nhiều thời gian phát triển cũng như gây áp lực không nhỏ lên đội ngũ phát triển để hoàn thành dự án đúng hạn.Hơn nữa, về phía business thường ưu tiên phát triển thêm tính năng mới hơn là chú trọng đến chất lượng của UI. Việc chia sẻ UI không chỉ mang rủi ro mà còn ít khi đem lại lợi ích cho tinh thần làm việc hay cho mục tiêu kinh doanh.

Khác với Xamarin, Flutter hay React Native, Kotlin Multiplatform không tồn tại trong một hệ sinh thái độc lập. Nó giống như cuốn sách “chọn lựa cuộc phiêu lưu của riêng bạn”, điều này làm cho nó trở nên vô cùng mạnh mẽ.

Mặc dù hiện tại Kotlin Multiplatform (KMP) chỉ có một số lượng hạn chế các thư viện (dù số lượng này đang dần tăng lên), nó vẫn cho phép bạn sử dụng toàn bộ các thư viện và công cụ hiện có trên cả iOS và Android. Nhờ vậy, bạn không cần phải chờ đợi sự phát triển của các thư viện mới, hoặc tìm kiếm giải pháp thay thế. Điều này là một hạn chế lớn khi sử dụng Flutter hay React Native, nơi bạn thường xuyên gặp phải các trở ngại đáng kể.

Kết quả từ việc sử dụng Kotlin Multiplatform chỉ đơn giản là tạo ra các package khác nhau trên Android và framework trên iOS. Điều này có thể giúp tiết kiệm một lượng lớn thời gian và giảm bớt những khó khăn, bởi bạn sẽ mất ít thời gian hơn cho việc viết mã cầu nối hoặc phải viết lại hoàn toàn những phần còn thiếu so với các giải pháp khác.

Khi lập trình business logic trên Flutter, team của bạn phải bắt đầu với việc viết logic bằng Dart - một ngôn ngữ không được sử dụng rộng rãi, trong một hệ sinh thái mới, cùng với một cộng đồng nhỏ và gặp khó khăn trong việc kết nối nó với mã nguồn đã có sẵn. Trên React Native, đội ngũ lập trình di động của bạn cần phải làm quen với hệ sinh thái web của JavaScript, bao gồm các IDE mới và công cụ khác. Còn với Xamarin, họ phải lập trình bằng C#, sử dụng Visual Studio, trong một cộng đồng nhỏ và ít hoạt động hơn. Thêm vào đó, dù sử dụng nền tảng nào đi nữa, đội của bạn cần phải thiết lập một cầu nối để giao tiếp giữa mã nguồn "native" và "non-native".

Với KMP, team của bạn lại có thể viết business logic dành riêng cho từng nền tảng, kết nối trực tiếp với nền tảng native mà không cần phải chờ đợi các thư viện hoặc tìm kiếm các giải pháp tạm thời hay phương án thay thế..

(Bạn có thể làm điều đó nếu bạn muốn, đó chính là một phần của cuộc phiêu lưu mà bạn chọn lựa). Và ngay cả khi có phát sinh vấn đề, khả năng chia sẻ linh hoạt với Kotlin Multiplatform có nghĩa là bạn chỉ cần khôi phục những phần code trực tiếp liên quan đến sự cố - không cần phải tháo dỡ toàn bộ hệ thống chỉ vì một lỗi nhỏ. Do đó, bạn luôn có nhiều lựa chọn.

Tất nhiên điều này rất quan trọng, bởi vì business logic sẽ xác định cách thức hoạt động của tất cả tính năng có trong ứng dụng. Bởi vì bạn đang viết code native một lần cho layer này nên bạn có thể tăng tốc thời gian phát triển và giúp chắc chắn rằng bạn có một code base thật sự vững chắc. Thêm nữa, viết bằng một trong những native code là một cách hiệu quả cao cho việc kiểm thử các bản phát hành sau này.

Kotlin Multiplatform, nói một cách khác, nó cung cấp cho team của bạn sự linh hoạt cao hơn.

Những phương án đa nền tảng khác cơ bản là độc quyền, dẫn đến việc bị ràng buộc bởi nhà cung cấp.Trên thực tế, nó cũng dẫn đến nhu cầu quản lý nền tảng thứ ba vì hệ sinh thái quá khác so với nền tảng native và vì chúng cố gắng giải quyết mọi thứ nhưng không thể giải quyết mọi thứ, bạn sẽ cần phải viết thêm code dành riêng cho nền tảng hơn là được quảng bá.

Không giống như Xamarin hay React Native, KMP không yêu cầu một Virtual Machine(VM). Flutter cũng không yêu cần một VM trên sản phẩm thương mại, nhưng nó mang đến cho bạn một hệ sinh thái non-native đang được viết trên ngôn ngữ non-native, không giống như KMP tôn trọng ngôn ngữ native và hệ sinh thái cho riêng từng nền tảng. KMP là một giải pháp đa nền tảng tốt nhất cho team của bạn có thể sử dụng hôm nay.

KMP không che giấu sự thật rằng bạn đang làm việc với nhiều nền tảng vì nó đã biên dịch thành thư viện gốc cho iOS hoặc Android.

Không có lớp xử lý trung gian nào cả, giúp loại bỏ hầu hết các rào cản trong quá trình tương tác. Vì Kotlin Multiplatform làm việc cùng với hệ sinh thái nền tảng native thay vì tạo ra một hệ sinh thái riêng biệt, các nhà phát triển có thể sử dụng những công cụ và thư viện mà họ vẫn thường dùng, kể cả những đổi mới mới như SwiftUI và Jetpack Compose. Những hạn chế bạn gặp phải không phải là bế tắc bởi vì bạn luôn có thể tìm cách giải quyết chúng bằng Kotlin, Swift, hoặc bất kỳ ngôn ngữ nào khác phù hợp và an toàn nhất.

Tổng kết, đây là do lường của tôi về thế giới đa nền tảng. Tuần tới tôi sẽ chia sẻ thêm chi tiết về các quan điểm này về KMP.Nếu bạn thấy KMP thú vị, hãy chia sẻ với tôi qua bình luận.

DEV Community: Hoang Son

Day 7/100: Week 1 Recap — 6 Android Fundamentals I Thought I Knew Cold

What I covered this week

The 6 most important things I (re)learned

1. Android components are entry points, not just classes

2. onDestroy() is not a safe place to save critical state

3. Fragment has TWO lifecycles — and mixing them up leaks memory

4. singleTask clears your back stack — and it's silent about it

5. Context lifetime mismatch is the root cause of most leaks

6. ContentProvider initializes before Application.onCreate()

The question I couldn't answer confidently until Day 3

What surprised me most about Week 1

Into Week 2

One question for you

Day 6/100: Context in Android — The Wrong One Will Leak Your Entire Activity

🔍 The concept

💡 What I thought I knew

😳 What I actually learned

What Context actually is

The lifetime mismatch that causes leaks

But applicationContext isn't always correct

The decision table

The this vs requireContext() vs requireActivity() confusion in Fragments

The WeakReference anti-pattern

The ContextThemeWrapper you didn't know you were using

🧪 The rule of thumb that actually works

❓ The interview questions

What surprised me revisiting this

Tomorrow

Day 5/100: Intent, Task & Back Stack and Why launchMode is a trap

🔍 The concept

💡 What I thought I knew

😳 What I actually learned

A Task is an OS-level concept, not an app concept

launchMode — what each value actually does

Intent flags — the lower-level control

Deep links and the Task problem

taskAffinity — the setting nobody talks about

🧪 The mental model that stuck

❓ The interview questions

What surprised me revisiting this

Tomorrow

Day 4/100: Fragment Lifecycle — Why It's More Confusing Than Activity's

🔍 The concept

💡 What I thought I knew

😳 What I actually learned

The full Fragment lifecycle has 9 callbacks, not 6

The two lifecycles visualized

The leak that this causes

this vs viewLifecycleOwner — the mistake that causes crashes

The callback where I always initialize views wrong

Fragment-to-Fragment communication the right way

🧪 The mental model that stuck

❓ The interview questions

What surprised me revisiting this

Tomorrow

Day 3/100: Activity Lifecycle — The Diagram You've Seen 100 Times

🔍 The concept

💡 What I thought I knew

😳 What I actually learned

The diagram has a ghost: the back stack

The configuration change trap

onPause() is your last guarantee

The two-Activity transition sequence

🧪 The mental model that stuck

❓ The three interview questions

What surprised me revisiting this

Tomorrow

Day 2/100: The 4 Android Components — What Senior Engineer Get Wrong

🔍 The concept

💡 What I thought I knew

😳 What I actually learned

Each component is a system entry point — not just a class

The BroadcastReceiver trap most seniors fall into

Service is not what you think in 2024

ContentProvider is the most misunderstood of the four

🧪 The mental model that stuck

❓ The interview question

What surprised me revisiting this

Tomorrow

2. `onDestroy()` is not a safe place to save critical state

4. `singleTask` clears your back stack — and it's silent about it

6. `ContentProvider` initializes before `Application.onCreate()`

But `applicationContext` isn't always correct

The `this` vs `requireContext()` vs `requireActivity()` confusion in Fragments

The `WeakReference` anti-pattern

The `ContextThemeWrapper` you didn't know you were using

`launchMode` — what each value actually does

`taskAffinity` — the setting nobody talks about

`this` vs `viewLifecycleOwner` — the mistake that causes crashes