Posts

The "No-Permission" Camera Trick in Jetpack Compose: An Architect's Guide

Image
 A deep dive into Intent-based delegation, Activity Result APIs, and why you should stop asking for the CAMERA permission for simple uploads. As an Android developer, you’ve likely spent hours wrestling with runtime permissions — checking, requesting, and handling the “Never ask again” state. But for many common use cases,  you can capture images in Jetpack Compose without requesting camera permission. In this guide, we’ll explore how to leverage the  Activity Result API , the technical nuances of  Intent-based delegation , and the production “sharp edges” you need to watch out for. 1. The Power of Delegation (IPC) The reason we can skip the permission ceremony is based on  Intent-based Delegation . When you use the Activity Result contracts, your app never actually touches the camera hardware. Instead, it sends a request via  Inter-Process Communication (IPC)  to a “handler” app (typically the System Camera). The System Camera:  Holds the actual ...

Stop Over-Using @Stable: The Performance Tool You're Misunderstanding

Image
 Beyond the @Stable annotation: A senior-level guide to mastering recomposition boundaries and compiler inference. TL;DR Don’t annotate everything:   @Stable  is a precision tool, not a default "performance button." Unstable ≠ Automatic Recompose:  Unstable types simply prevent the compiler from  guaranteeing  a skip. Use it when:  The compiler fails to infer stability (Interfaces, Multi-module) or you have verified a skipping failure. The Risk:  Applying  @Stable  incorrectly creates "stale UI" bugs that are a nightmare to debug. How Stability Enables Skipping Compose relies on a mechanism called  Skipping . If a Composable’s inputs haven’t changed, Compose attempts to skip its execution. However, if the compiler cannot prove a type is stable, it  fails to apply the skipping optimization . The Mental Model: Stable Input  +  equals()  unchanged →  Skip  ✅ Unstable Input  → Cannot guarantee → ...

🚀 Improve Your Android App Performance with StrictMode

Image
 Stop UI Jank and ANRs by Catching Main-Thread Violations Before They Reach Your Users. In the competitive world of Android development, a “buttery smooth” 60fps experience (and up to 120Hz on supported devices) is the baseline for user trust. But as codebases grow, “hidden” disk I/O or network calls can creep onto the Main Thread, leading to micro-stutters or the dreaded  ANR (App Not Responding)  dialog. 💡 Key Takeaway:  If it touches the disk or the network, it should  never  run on the main thread. 🚨  Rule:  The main thread is for UI only — nothing else. StrictMode  is your automated “code police.” It doesn’t just find bugs; it enforces architectural discipline by catching performance violations during development before they ever reach a user’s device. ⚙️ Modern Setup: The “Zero Tolerance” Configuration The best practice is to initialize StrictMode as early as possible — usually in your  Application  class—and  only ...