Fragment Reference

Comments

Post a Comment

Popular posts from this blog

Activity & Intent Interview question and Answer

1) What are the four essential states of an activity? Active – if the activity is at the foreground Paused – if the activity is at the background and still visible Stopped – if the activity is not visible and therefore is hidden or obscured by another activity Destroyed – when the activity process is killed or completed terminated 2) What is a visible activity? A visible activity is one that sits behind a foreground dialog. It is actually visible to the user, but not necessarily being in the foreground itself. 3) When is the best time to kill a foreground activity? The foreground activity, being the most important among the other states, is only killed or terminated as a last resort, especially if it is already consuming too much memory. When a memory paging state has been reach by a foreground activity, then it is killed so that the user interface can retain its responsiveness to the user. 4) What are the four essential states of an activity? Ans.  Active, Paused, Stopped and Des...
Read more

Most Developers Build Offline-First Apps Wrong — Here's What They Miss with Room

Image
  When you say your app works offline… does it really? A surprising number of Android developers proudly add “offline-first” to their app descriptions. And sure, the app opens without internet. Maybe it even loads a few screens. But dig a little deeper and it becomes clear: most offline-first implementations fall apart fast. Why? Because building an offline-first experience isn’t about just storing data locally. It’s about doing it intentionally , with the right structure, cleanup, and flow. And the culprit behind most of the silent issues? Room Database. Not because Room is bad — but because it's misunderstood. Let’s walk through some of the most common mistakes developers make when using Room in offline-first apps — and what to do instead. Mistake 1: Saving the Entire API Response into Room Many devs take the raw JSON response from their API and store it directly into Room entities — every field, every nested object, even things the app never uses. Why it’s a probl...
Read more

A Reusable MVVM API Call Pattern in Jetpack Compose

Image
Building scalable Android apps requires clean architecture—and one of the best ways to manage your UI and logic is by combining MVVM with Jetpack Compose . However, API calls can get messy when not structured properly. In this post, I’ll show you how to build a reusable, clean API call structure using MVVM that works for any screen in your app. We'll use: ViewModel to manage UI-related data Repository for business logic and network State management using mutableStateOf Retrofit for networking This is not tied to any specific screen (like sliders, onboarding, etc.)—you can plug in your own model and API. Why a Reusable Pattern? Apps often repeat the same logic: Show loader Fetch data Handle errors Update UI Instead of repeating it everywhere, we'll abstract it once and just extend or plug in what’s needed per screen. 1. Define a Generic API Result Wrapper This wrapper lets us handle success, loading, and error states in a consisten...
Read more