Posts

Stop Using READ_CONTACTS: A Modern Android Contact Picker Guide

Image
 How to migrate to a zero-permission strategy, boost user trust, and write production-grade Kotlin code for the system contact picker. For over a decade, the standard for obtaining a phone number on Android was to add  READ_CONTACTS  to your Manifest, request a "Dangerous Permission," and query the entire database. But the era of broad data harvesting is over. Modern  Android permissions best practices  favor  system-provided pickers . Just as the Photo Picker replaced broad storage access, using the  Android contact picker  allows your app to get exactly what it needs — and nothing more. ⚡ TL;DR Avoid  READ_CONTACTS  unless you are building a Dialer or a Backup app. Use  ActivityResultContracts.PickContact()  to delegate selection to the OS. Resolve the  CONTACT_ID  explicitly from the returned URI before querying. Cache data immediately , as URI access is short-lived and not guaranteed to persist. 🧠 Why This Matter...

🚀 Mastering Jetpack Compose Lifecycle in Fragments

Image
 A practical guide to handling state, composition strategies, and lifecycle intersections in hybrid Android apps. TL;DR: The 30-Second Summary The Conflict:  Fragments have two lifecycles (Fragment instance vs. View hierarchy). The Problem:  By default,  ComposeView  can stay active in the background after  onDestroyView() , leading to memory leaks. The Fix:  Manually set  ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed . The Pro Move:  Use  collectAsStateWithLifecycle()  to pause data flows when the UI isn't visible. The Hidden Lifecycle Gap In Fragment-based apps, navigating away often destroys the  View  while keeping the  Fragment instance  alive in the backstack. As shown in the flow below, if your Compose UI isn’t explicitly told to follow the View’s lifecycle, it remains “attached” in a ghost state. The Lifecycle Flow: onCreateView()  ➜  ComposeView.setContent() Active State  ➜ U...