Posts

Part 1: The "Lie-Fi" Problem & The Offline-First Mindset

Image
 How Senior Engineers use SSOT, Room, and Flow to build resilient, production-grade apps that never feel broken. TL;DR The Problem:  “Online-first” apps break in “Lie-Fi” (zombie connections). The Fix:  Move from Request-Response to  Single Source of Truth (SSOT) . The Flow:  UI observes Room → Network updates Room → UI reacts. Priority:  Choose  Availability  (AP) over strict Consistency. 1. The “Online-First” Fallacy In an online-first model, the  UI becomes tightly coupled to the variability of network conditions . This creates a fragile experience where usability is tethered to the health of a remote socket. The “Zombie” Connection (Lie-Fi):  The TCP socket hasn’t timed out, but no data is moving. The app waits for an  onResponse  that may take tens of seconds (or never) to resolve. To the user, the app isn't "waiting"—it's  broken . Real-World Failure Scenario: User “Likes” a photo → Network stalls → Heart doesn’t tur...
Post a Comment
Read more

Beyond the Surface: Mastering Jetpack Compose Preview Internals & Scalable Patterns

Image
 Why your inability to preview a Composable is actually a signal of technical debt. Most Android developers treat  @Preview  as a visual convenience. But for senior engineers, Preview is a  UI contract . If a Composable cannot be previewed without heavy workarounds, your architecture is likely trying to tell you something. 1. The Internal Mechanics: How It Actually Renders When you hit the “split” view in Android Studio, you aren’t running your app. You are engaging a coordinated dance between the Kotlin compiler, the Compose compiler, and the IDE. The Mental Model The rendering pipeline follows a strict sequence to simulate your UI without a full device environment: @Preview Discovery:  The IDE scans Kotlin metadata and Compose compiler tables. Adapter Layer:  A synthetic wrapper is generated to prepare parameters and environment. Layoutlib Sandbox:  A sandboxed subset of the Android framework provides a mock  Context  and resources. Bitmap ...
Post a Comment
Read more

Stop Polling Your APIs: A Principal Engineer's Guide to Real-Time Android

Image
 Beyond REST: A Staff-Level Guide to Reducing Battery Drain, Handling Connection Storms, and Mastering Event-Driven Architecture. In staff-level architecture, the choice of protocol is just the starting point. The real challenge is managing state when the network is unstable, the OS is throttling, and 100,000 clients are attempting to reconnect at the same millisecond. While REST polling is the default starting point for many, it becomes inefficient and hard to scale for high-frequency features like live order tracking. It significantly increases battery consumption and creates unnecessary server load. Here is the architectural blueprint for moving to a  real-time Android architecture  using MQTT while surviving the brutal realities of the mobile ecosystem. TL;DR: The Senior Engineer’s Cheat Sheet Polling:  OK for low-frequency updates (e.g., settings sync). MQTT:  Best for high-frequency, low-latency needs (e.g., live tracking). Android Reality:  Backgroun...
Post a Comment
Read more