Challenge 1: Spot and Fix a Memory Leak — Solution

object AnalyticsManager {
    private var appContext: Context? = null

    fun init(context: Context) {
        appContext = context.applicationContext
    }
}

// Why context.applicationContext specifically fixes the leak:
//
// context.applicationContext returns a reference to the single,
// app-wide Application object — an object that genuinely lives for as
// long as the entire app process does, the same lifetime as
// AnalyticsManager itself (a singleton "object", per Kotlin Fundamentals
// Chapter 8). Holding a reference to it long-term is completely safe,
// because nothing is being kept alive PAST its natural lifetime.
//
// The original bug was storing the raw "context" parameter directly —
// if init(context) were ever called with an Activity's own Context
// (e.g. "this" from inside an Activity's onCreate), AnalyticsManager
// (which lives as long as the whole app process) would hold that
// Activity reference indefinitely, even long after the Activity itself
// was destroyed (e.g. the user navigated away or rotated the device).
// The garbage collector cannot reclaim that Activity's memory as long as
// AnalyticsManager still references it — a real, classic memory leak.

Notes:
- .applicationContext is available on ANY Context (Activity, Fragment,
  Application itself) and always returns the same single
  Application-scoped instance regardless of where it's called from —
  this is the exact same underlying concept as Course 2 Chapter 5's
  @ApplicationContext Hilt qualifier, just accessed directly here
  instead of via dependency injection.
- This same principle is why a ViewModel (Course 2, Chapter 2) should
  never hold a direct Activity/Fragment reference at all — its lifetime
  can outlive a specific Activity instance (surviving rotation), so any
  reference back to that specific instance risks becoming stale or
  leaking exactly like this example.