Let's design the Facebook News Feed for Android. I want you to implement pagination from scratch — do not use Jetpack Paging 3 library. I want to see that you understand the underlying mechanics. Where would you like to start?

Before jumping into design, I'd like to confirm the functional requirements first, then the non-functional requirements. That way we have a shared understanding of scope.

Functional Requirements (what the app does):

• Display a scrollable feed of posts (text, images, mixed)
• Each post shows author info, content, timestamp, and engagement counts (likes, comments, shares)
• Pull-to-refresh to get the latest posts
• Infinite scroll with pagination — no "Load More" button
• Search posts by keyword
• Filter posts by type (photos only, text only, viral)
• Create a new post

Non-Functional Requirements (how the app behaves):

• Offline support — cached feed should be available without network
• Survive configuration changes (screen rotation) without data loss
• Smooth scrolling at 60fps even with heavy image content
• Testable architecture — unit tests for business logic without Android framework
• Scalable to millions of posts without client-side performance degradation

Does this match what you had in mind, or should I adjust the scope?

That's a solid list. Let's go with this. How would you approach the high-level architecture?

I'd go with MVVM (Model-View-ViewModel) with a Repository pattern. Here's the data flow — from top to bottom:

The key idea: Room is the single source of truth. The UI never talks to the network directly. It observes Room via Kotlin Flows. When we need fresh data, we hit the API and write results into Room — the Flow automatically emits the update.

This gives us offline support for free. If the network fails, the user still sees cached data.

Good. Let's see some code. Walk me through the data layer first.

Starting with the Room entity and DAO, then Retrofit, then the Repository that ties them together.

What does the API contract look like? Walk me through the request and response for cursor-based pagination.

The API uses cursor-based pagination. The client sends an opaque cursor string (the ID or timestamp of the last item it saw) and a page size. The server returns the next page of items plus the cursor for the following page.

Here's the contract:

Now the Repository — the bridge that makes Room the source of truth:

How does the ViewModel expose state to the UI? And how does rotation work?

One data class represents the entire screen state. One StateFlow emits it. The ViewModel survives rotation because the ViewModelStore is scoped to the Activity's lifecycle, not the Fragment or Compose destination.

I notice the ViewModel is calling repository methods directly. Would you keep it this way?

For a small feature, calling the repository directly is fine. But this is a feed app that will grow — we will add post creation, liking, sharing, reporting, bookmarking, search with analytics tracking, and more. If all that logic sits in the ViewModel, it becomes a god class.

I would introduce UseCases (also called Interactors). Each UseCase encapsulates one piece of business logic. The ViewModel becomes a thin orchestrator that just wires UseCases to UI state.

Benefits:

• Single Responsibility: Each UseCase does exactly one thing. ObserveFeedUseCase observes the feed. RefreshFeedUseCase refreshes it. LoadNextPageUseCase paginates.
• Reusability: If a notification screen also needs to refresh the feed, it can reuse RefreshFeedUseCase without duplicating the logic.
• Testability: You test each UseCase in isolation. The ViewModel test just verifies it calls the right UseCase at the right time.
• Readability: The ViewModel constructor tells you everything the screen does at a glance — just read the UseCase names.

Now the ViewModel becomes much cleaner — it just wires UseCases to state:

Show me the Compose screen that ties this together.

Good. Now add search with debounce and filtering. Also, how would you find the top 5 trending posts efficiently? Think about the data structure.

For search, I'd debounce the input by 300ms using Flow.debounce() so we're not hammering the database on every keystroke. Combined with flatMapLatest, any in-flight search gets cancelled when a new query arrives.

For the "Top 5 trending" — this is a classic Top-K problem. Sorting the entire list would be O(N log N), but we can do it in O(N log K) using a min-heap (PriorityQueue) of size K. As we scan each post, if its score beats the heap minimum, we evict the min and insert the new one.

Can you show me exactly how debounce and flatMapLatest work with Flows? What does flatMapLatest actually do?

debounce(300) waits for 300ms of silence before emitting. User types "a", "ab", "abc" rapidly — only "abc" gets emitted because the previous values were superseded within 300ms.

flatMapLatest cancels the previous inner flow when a new value arrives. If a search for "ab" is still hitting the database when "abc" comes in, it cancels the "ab" query and starts "abc" instead. No wasted work, no stale results leaking through.

Together: debounce reduces the number of emissions, flatMapLatest ensures only the latest emission's work actually completes.

What happens when the user creates a new post but the network fails? How do you handle that?

This is an optimistic update + retry queue pattern.

Step 1: Write to Room immediately with a syncStatus = PENDING flag. The post shows up in the feed instantly — the user sees it right away. We can dim it slightly or show a small "sending..." indicator.

Step 2: Attempt to sync to the server in the background via a coroutine. If it succeeds, update syncStatus = SYNCED and replace the local ID with the server-generated ID.

Step 3: If it fails, mark it as syncStatus = FAILED. Show a retry affordance on the post card. Also enqueue a WorkManager one-time work request with exponential backoff — it will retry even if the user kills the app.

Step 4: On next app launch, check for any PENDING or FAILED posts and attempt to sync them.

Let's add a Like button to each post. When the user taps it, the like count increments and the heart fills in. Walk me through how you'd implement this end to end.

This is another optimistic update problem — same pattern as post creation, but simpler. The user expects instant feedback when they tap the heart. We cannot wait for a network round-trip. Here is the approach:

Step 1: Update Room immediately. Toggle the isLikedByMe flag and increment/decrement likeCount in the local database. Since the UI observes Room via Flow, the heart fills in and the count updates instantly.

Step 2: Fire-and-forget API call. Send the like/unlike request to the server in the background. No loading spinner, no blocking.

Step 3: Handle failure. If the API call fails, revert the local state — toggle isLikedByMe back and adjust the count. Show a subtle toast or snackbar: "Couldn't like this post. Try again."

Step 4: Deduplication. If the user taps like/unlike rapidly, we debounce the API calls. Only the final state gets sent to the server. This avoids flooding the backend with toggle requests.

First, I need to add isLikedByMe to the entity:

Now the UseCase. This is where the optimistic update + rollback logic lives:

In the ViewModel, wiring the like action is one function:

And in Compose, the PostCard gets a callback:

You've mentioned optimistic updates twice now — for post creation and likes. Can you talk about the broader consistency model here?

This entire architecture is built on eventual consistency, not strong consistency. Here is what that means practically:

At any given moment, the local Room database and the remote server may disagree. The user might see 235 likes locally but the server has 238 because three other users liked the post in the last 10 seconds. That is fine. When the feed refreshes, the server sends the authoritative state and Room converges.

The contract is: the client is always eventually correct, but never guaranteed to be immediately correct.

Where we use eventual consistency in this app:

• Like counts: Optimistic local increment, server corrects on next sync. Off by a few is acceptable — users do not notice if they see "235 likes" vs "238 likes" for 30 seconds.
• Post creation: The post appears locally with PENDING status. The server may take a few seconds to process it (image upload, content moderation, etc.). Once synced, the local record is updated with the server ID and SYNCED status.
• Feed ordering: The local feed might be stale by a few minutes. Pull-to-refresh or background polling brings it up to date. We do not need WebSockets for a feed — the cost is not worth the marginal freshness gain.
• Deleted posts: If another user deletes a post, we might still show it until the next refresh. The server returns a 404 or omits it from the response, and our local copy gets cleaned up.

Why not strong consistency? Because it means blocking the UI on every network call. The user taps "like" and waits 200ms-2000ms for a spinner before the heart fills. That feels broken. Users care about responsiveness more than perfect accuracy on social metrics.

The trade-off: We accept momentary staleness in exchange for instant UI feedback. The worst case is the user sees a count that is off by a small amount for a short time. The best case — which is most of the time — is that the optimistic update was correct and the server confirms it.

Let's do a quick rapid fire. Short answers, show you can think on your feet.

Q1: How do remote API data and local Room data get married together? Have you used RemoteMediator?

RemoteMediator is part of Paging 3 library. It sits between the PagingSource (Room) and the network. When Paging detects that Room has run out of cached data, it calls RemoteMediator.load() which fetches the next page from the API, writes it into Room, and then Paging reads from Room again.

The flow is: UI requests page -> Paging checks Room -> Room is empty -> RemoteMediator fetches from API -> writes to Room -> Paging reads from Room -> UI renders.

In our current design, we wrote this logic manually in the Repository. RemoteMediator formalizes the same pattern with built-in support for REFRESH, PREPEND, and APPEND load types. For a production app at scale, I would migrate to Paging 3 + RemoteMediator because it also handles boundary callbacks, placeholder items, and load state tracking out of the box.

Q2: Does the current design handle screen rotation? How exactly?

Yes, fully. Three layers protect us:

• ViewModel survives rotation. It is scoped to the Activity lifecycle via ViewModelStore. When the Activity is destroyed and recreated on rotation, the same ViewModel instance is returned.
• StateFlow caches the latest value. When Compose resubscribes after recreation, collectAsStateWithLifecycle() immediately gets the current state. No re-fetching, no flash of empty screen.
• Room persists data to disk. Even in the extreme case of process death (not just rotation), the feed data is already on disk. The ViewModel re-initializes, observes Room, and the UI is populated from cache.

Scroll position is handled by rememberLazyListState() in Compose, which saves and restores via the rememberSaveable mechanism internally.

Q3: Quick — write a thread-safe singleton in Java. Not Kotlin object, actual Java.

Double-checked locking with volatile:

Why volatile? Without it, the JVM can reorder the constructor — another thread might see a non-null reference to a half-constructed object. volatile prevents that reordering. Why double-checked? The outer null check avoids the synchronized overhead on every call after initialization. The inner check ensures only one thread creates the instance.

Q4: What if the singleton needs a parameter — like a Context? You cannot pass it to getInstance() every time. Show me.

Same double-checked locking, but with a parameter on first call. In Kotlin this is cleaner with a reusable delegate:

Key detail: Always store context.getApplicationContext(), never the Activity context. Storing an Activity context in a singleton leaks the entire Activity — the GC cannot collect it because the singleton (which lives forever) holds a reference.

Q5: You are using Room as the source of truth. What happens when you ship a schema change and the migration fails on a user's device?

If a Room migration fails and you have no fallback, the app crashes on startup — the database cannot be opened. There are two strategies:

• Destructive fallback: Call .fallbackToDestructiveMigration() on the database builder. Room wipes the database and recreates it from scratch. You lose cached data but the app works. For a feed app, this is acceptable — the data is re-fetched from the server on next launch. You would NOT do this for an app with user-generated local data (notes app, offline-first todo list).
• Manual migrations: Write explicit Migration(1, 2) classes with ALTER TABLE statements. Test them with MigrationTestHelper in instrumented tests. This is the safe production approach.

In practice, I use both: manual migrations as the primary path, with destructive fallback as the safety net. If the migration has a bug, at least the app opens instead of crashing in a loop.

Q6: LazyColumn or RecyclerView? Which one and why?

LazyColumn for new code. It eliminates the Adapter, ViewHolder, DiffUtil, LayoutManager boilerplate entirely. With items(key = { ... }), it handles stable IDs and diffing automatically. animateItemPlacement() gives free reorder animations. And since the rest of our UI is Compose, mixing in a RecyclerView would mean maintaining an interop layer for no reason.

The only exception: if you have an existing large RecyclerView with complex custom ItemDecorations, ItemAnimators, and ItemTouchHelpers that would be painful to rewrite, keep it and wrap it in AndroidView inside Compose. Do not rewrite working code just for the sake of Compose purity.

Q7: A coroutine inside viewModelScope.launch throws an unhandled exception. What happens?

viewModelScope uses SupervisorJob + Dispatchers.Main.immediate. Because of the SupervisorJob, one child coroutine failing does NOT cancel sibling coroutines. But the exception still propagates to the CoroutineExceptionHandler — and if you have not installed one, it crashes the app via the default uncaught exception handler.

Fix: either wrap the body in try/catch, use runCatching, or install a CoroutineExceptionHandler on the launch. For our feed, every coroutine that touches the network has a try/catch that updates _uiState with an error message instead of crashing.

Q8: Why Hilt over Koin or manual DI?

Hilt is compile-time. If a dependency is missing, you get a build error, not a runtime crash in production. Koin is runtime — the graph is resolved when you call get() or inject(). A missing binding only blows up when that screen is opened by a real user.

Hilt also integrates natively with ViewModel, WorkManager, Navigation, and Compose via @HiltViewModel and hiltViewModel(). No manual factory boilerplate.

Trade-off: Hilt has more annotation processing overhead (slower incremental builds) and a steeper learning curve with its component hierarchy. For smaller apps, Koin's simplicity might win. For a team-scale app like this feed, compile-time safety is worth the build cost.

Q9: You mentioned 60fps smooth scrolling earlier. Where does the "16ms per frame" number come from? What is jank?

The display refreshes at 60Hz — that is 60 frames per second. 1000ms / 60 = ~16.6ms per frame. The system has to measure, layout, and draw every frame within that budget.

Android uses a VSync signal — a hardware tick from the display that says "time to draw the next frame." The Choreographer listens to VSync and schedules the work: input handling, animation ticks, view traversal (measure/layout/draw). If all of that finishes within 16ms, the frame is delivered on time. Smooth.

Jank is what happens when a frame misses the deadline. The Choreographer could not finish the work before the next VSync tick, so the display shows the old frame again. The user sees a stutter or hitch — dropped frame. Common causes: doing disk I/O or network on the main thread, inflating heavy layouts, GC pauses from excessive allocations, or nested layouts causing exponential measure passes.

For our feed: Compose's lazy composition + image loading on a background thread (Coil/Glide) + no main-thread database access (Room enforces this) keeps us within budget on most frames.

That was a really strong session. You started with clear requirements, made deliberate architecture choices and justified them well, wrote clean production code, and handled the follow-ups with depth. The way you walked through the optimistic update pattern and eventual consistency showed you've dealt with real-world trade-offs, not just textbook answers.

I especially liked that you introduced UseCases proactively as the app grows — that shows you think about maintainability, not just getting it to work.

We'll be in touch. Thanks for your time.

Thank you — I enjoyed the discussion. Looking forward to hearing from you.

Let's design the Facebook News Feed for Android. Users should be able to scroll through an infinite feed of posts. You can use any library you want.

Got it. Let me clarify a few requirements first.

Functional requirements:

• Users can scroll infinitely through the feed
• Each post shows author, content, image, and like count
• Pagination happens automatically as the user scrolls near the bottom
• Users can like/unlike a post
• Swipe-to-refresh clears and reloads the feed

Non-functional requirements:

• Feed should work offline (previously loaded posts visible)
• No jank — smooth scrolling even with large lists
• Efficient memory usage — don't load all 1M posts into RAM
• Configuration changes (rotation) should not reset the feed position or reload data
• Initial load should be fast (show posts within 1-2 seconds)

Good. Now walk me through the architecture. What layers do you need?

I'll use MVVM with Clean Architecture and separate layers for UI, business logic, and data.

Here's the architecture:

Why MVVM with Paging 3?

• Paging 3 handles all pagination state internally — no need to manually manage loading, error, and success states
• ViewModel survives config changes, and cachedIn(viewModelScope) caches the PagingData flow
• Room automatically invalidates the PagingSource when data changes, triggering UI updates
• RemoteMediator bridges network and local DB — perfect for offline-first apps
• The ViewModel becomes very thin — just a pass-through of the repository's PagingData flow

Before we write any Paging code, what does the API contract look like?

The API uses cursor-based pagination. The client sends an opaque cursor (the server's bookmark for where we left off) and a page size. The server returns the next page of items, a new cursor for the next request, and a boolean to signal the end.

Good. Now walk me through the core Paging 3 classes — PagingSource, PagingData, PagingConfig.

PagingSource is an abstract class that you implement. It's the interface between your data (network or database) and Paging. It has one method: load(params).

PagingData is a stream of paginated items. It's not a list — it's a cold Flow that emits items as pages are loaded. The UI collects this Flow and renders items incrementally.

PagingConfig holds configuration: page size, prefetch distance, max size in memory.

Pager is the orchestrator. You give it a config, a pagingSourceFactory, and optionally a RemoteMediator. Pager.flow emits PagingData streams.

Let me show you a simple PagingSource for network-only pagination:

Key points:

• The type parameters are PagingSource<Key, Value>. Key is the cursor type (String in this case), Value is the item type (Post).
• params.key is the cursor passed by Paging to fetch the next page. For the first load, it's null.
• params.loadSize is the page size (from PagingConfig).
• LoadResult.Page(data, prevKey, nextKey) returns the page of items and the cursor for the next page.
• prevKey is used for prepending (loading older items). In a top-down feed, we set it to null because we only append.
• nextKey is the cursor for the next page — usually the next_cursor from the API response.
• getRefreshKey() returns the key to use when the user swipes to refresh. Returning null means start from the beginning.

LoadParams types:

• LoadParams.Refresh(key, loadSize) — Initial load or swipe-to-refresh
• LoadParams.Append(key, loadSize) — Load the next page as user scrolls down
• LoadParams.Prepend(key, loadSize) — Load older items (for bidirectional feeds)

LoadResult types:

• LoadResult.Page(data, prevKey, nextKey) — Success, return items and next cursor
• LoadResult.Error(exception) — Network or parsing error, Paging shows retry UI

Nice. But now I want offline support. The feed should still show posts if there's no network. How do you handle that?

I'd use RemoteMediator as the bridge. The idea is:

• Room provides a PagingSource that reads from the local database
• RemoteMediator is a separate interface that fetches from the network and writes to Room
• Paging orchestrates both: fetch from RemoteMediator, write to Room, then Room's PagingSource emits the items to the UI
• If the network fails, Room's PagingSource still has cached data to show

Here's the RemoteMediator implementation:

Key points:

• LoadType.REFRESH: User swiped to refresh or initial load. Cursor is null (fetch from the beginning). We clear the old data and insert fresh posts.
• LoadType.APPEND: User scrolled to near the bottom. Get the oldest cursor from the database (via dao.oldestCursor()) and fetch the next page.
• LoadType.PREPEND: In a top-down feed, there's nothing to prepend. Return Success(endOfPaginationReached=true) immediately.
• db.withTransaction { ... } ensures atomic updates. If the delete and insert happen in a transaction, the UI won't briefly show an empty list.
• endOfPaginationReached: When true, Paging stops calling load() even if the user scrolls. When false, Paging will call load(Append) again when prefetchDistance is hit.

Good. Now show me the Repository and ViewModel. How do you wire PagingSource and RemoteMediator together?

The Pager class does the wiring. It takes a config, a pagingSourceFactory, and a RemoteMediator. The Pager.flow emits a Flow of PagingData. Here's the Repository:

The Repository returns a Flow of PagingData. The .map() at the end transforms each page's PostEntity objects to Post domain objects.

Now the ViewModel:

That's it! The ViewModel is just three lines. The magic is .cachedIn(viewModelScope).

What does cachedIn() do?

• PagingData is a cold Flow — each collector triggers a new PagingSource and RemoteMediator calls
• cachedIn() converts it to a hot (shared) Flow using ShareIn
• Multiple subscribers to viewModel.feed get the same PagingData stream and same scroll position
• Most importantly: config changes (rotation) don't restart pagination — the ViewModel survives, and the PagingData flow continues from where it was
• When viewModelScope is canceled (activity destroyed), the flow stops and cachedIn() cleans up

Now the UI. How do you render the PagingData in Compose?

Paging 3 provides a collectAsLazyPagingItems() extension for Compose. It converts PagingData into LazyPagingItems, which is a list-like interface that the LazyColumn can use directly.

Key points:

• collectAsLazyPagingItems() converts the PagingData Flow to LazyPagingItems. It's a Composable function, so it must be called inside a @Composable.
• items.itemCount is the number of items currently loaded (not the total — it grows as pages load).
• items[index] gets an item safely; it returns null if the item hasn't loaded yet.
• items.loadState is a LoadStates object with three properties:
• loadState.refresh — initial load or swipe-to-refresh state
• loadState.append — state of pagination (loading next page)
• loadState.prepend — state of prepending (rare for feeds)
• Each can be LoadState.Loading, LoadState.Error, or LoadState.NotLoading.
• items.refresh() triggers a full refresh (clears and reloads from page 1).
• items.retry() retries the failed page load without clearing.
• SwipeRefresh shows a spinning indicator when loadState.refresh is Loading.

How pagination is triggered:

• User scrolls down, approaches the bottom
• LazyColumn measures items, Paging detects when itemCount - currentVisibleIndex < prefetchDistance
• Paging automatically calls load(LoadParams.Append)
• RemoteMediator fetches next page and inserts into Room
• Room PagingSource emits new items
• LazyColumn re-renders with new items — all without manual triggers

Let me deep-dive on refresh. When the user pulls down to refresh, walk me through the entire flow.

Swipe-to-refresh flow:

1. User pulls down on the feed
2. SwipeRefresh.onRefresh callback fires, which calls items.refresh()
3. items.refresh() tells Paging to invalidate the current PagingSource
4. Paging destroys the old PagingSource and creates a new one
5. Paging calls RemoteMediator.load(LoadType.REFRESH)
6. RemoteMediator calls api.getFeed(cursor=null, pageSize) to fetch the first page of fresh posts
7. RemoteMediator wraps the DB write in a transaction and calls dao.clearAll() to delete old posts
8. RemoteMediator calls dao.insertAll(freshPosts) to insert the new posts
9. Room's PagingSource (which is still attached to the LazyColumn) detects the database change
10. Room automatically invalidates the PagingSource (because tables changed)
11. Room creates a new PagingSource and re-queries the database
12. The new PagingSource emits the fresh posts as a new page
13. LazyColumn re-renders with fresh posts
14. loadState.refresh transitions from Loading → NotLoading, SwipeRefresh spinner stops

Good. Now let's add a new feature: the user can like a post. How do you implement that efficiently?

I'd use optimistic updates: update the UI immediately, then sync to the server asynchronously. If the server fails, rollback.

Here's the UseCase:

How it works:

1. User taps the like button
2. We immediately update the database (optimistic): toggle isLikedByMe, increment/decrement likeCount
3. Room detects the change and invalidates the PagingSource
4. The UI re-renders with the new like state instantly (no spinner, no delay)
5. In the background, we call api.likePost(postId) asynchronously
6. If the API succeeds, great — we're done
7. If the API fails (network error, 500, etc.), we catch the exception and rollback the DB change
8. Room detects the rollback and re-renders the UI with the original state

This gives the user instant feedback while ensuring data consistency. By the time the user opens a different app and comes back, the API call has finished and the state is synced.

Let's add search and filters. Users can search for posts and filter by liked posts. How do you combine this with Paging?

The key is to use flatMapLatest on a query/filter StateFlow. Each new query creates a new Pager:

How it works:

• _query is a MutableStateFlow that holds the current search text
• .debounce(300) waits 300ms after the user stops typing before emitting the query (reduces API calls)
• .flatMapLatest cancels the previous search and starts a new one. Unlike flatMapConcat (which queues searches), flatMapLatest discards old results if the user types again
• repository.searchFeed(query) returns a new Pager for each query
• .cachedIn() still works — each search result is cached separately

The Repository would look like:

Good design. Now some follow-up questions to test deeper knowledge.

Sure, go ahead.

Q1: Hot flows vs cold flows in the ViewModel. PagingData is a cold Flow, right? But you call cachedIn() on it. How does that work?

Good question. By default, PagingData is a cold Flow — each collector triggers a new PagingSource and RemoteMediator calls. cachedIn() internally uses shareIn() to convert it to a hot/warm shared flow. ShareIn uses a scope (viewModelScope in our case) to manage the lifetime. Multiple subscribers share the same PagingSource. When viewModelScope is canceled, the shared flow is closed. Without cachedIn(), config changes would create a new collector, triggering a new PagingSource, which is wasteful and causes the list to reset.

Q2: Explain the private _uiState pattern. Why do you use private MutableStateFlow and expose a public val as StateFlow?

The pattern is: private MutableStateFlow (only the ViewModel can write), public val as the read-only Flow or StateFlow (the UI can only read). This is for encapsulation and preventing external code from mutating state directly.

For PagingData, we don't expose a mutable version — the feed val is a Flow>, which is inherently immutable from the collector's perspective. We don't need a separate _feed private field because Paging handles mutability internally.

For StateFlow (e.g., _query in search), we'd do:

private val _query = MutableStateFlow("")
val query: StateFlow<String> = _query.asStateFlow()

This way, the UI can read query but not write to it. Only the ViewModel can call _query.value = "new value".

Q3: What does .asStateFlow() do? When would you use it?

.asStateFlow() converts a MutableStateFlow to a read-only StateFlow. It's the same underlying object, but the returned type is StateFlow, which doesn't expose .value setter or .tryEmit() method. It's purely a type-level encapsulation for the public API. Use it to prevent the UI from accidentally (or maliciously) modifying state.

Q4: The user rotates the device. Walk me through what happens to the feed, the ViewModel, and the scroll position.

Rotation is a config change:

1. Activity is destroyed (onDestroy called)
2. Activity is recreated with a new Compose state
3. The old ViewModel is NOT destroyed — it survives
4. The old ViewModel's feed Flow (with cachedIn()) is still "hot" and emitting
5. The new Compose composition calls collectAsLazyPagingItems() on the same feed Flow
6. Since the Flow is already cached and hot, the new collector receives the same PagingData stream (same items, same scroll position)
7. LazyColumn uses the key lambda to match items, so scroll position is preserved by Compose
8. User sees no flicker, no re-fetch, no scroll reset

Without cachedIn(), a new collector would trigger a new PagingSource, clearing the list and starting from page 1 — very jarring.

Q5: What happens if the process is killed and the app is restarted? Does the user see the old feed?

Process death is different from config changes. The ViewModel is destroyed, and the app restarts from scratch. But Room persists the database, so:

1. App process is killed
2. User reopens the app
3. New ViewModel is created, which creates a new Pager
4. Pager's pagingSourceFactory creates a new Room PagingSource
5. Room PagingSource reads from the database (which still has the old posts)
6. LazyPagingItems emits the old posts immediately
7. RemoteMediator.load(REFRESH) is called in the background (via initialize())
8. Fresh data is fetched and inserted, Room PagingSource is invalidated and re-emits with fresh data

So yes, the user sees the old feed briefly, then it refreshes to fresh data. It's a good user experience — the app feels fast (shows cached data) and keeps data fresh (refreshes automatically).

Q6: How would you implement a thread-safe singleton for the database?

With Hilt (which we're using), you don't need manual singletons — Hilt manages it via @Singleton on the @Provides method:

@Module
@InstallIn(SingletonComponent::class)
object DatabaseModule {
    @Singleton
    @Provides
    fun provideAppDatabase(context: Context): AppDatabase {
        return Room.databaseBuilder(context, AppDatabase::class.java, "feed.db").build()
    }
}

Hilt ensures there's only one AppDatabase instance in the SingletonComponent (application lifetime). If you didn't use Hilt, you'd use double-checked locking:

object DatabaseHolder {
    private var INSTANCE: AppDatabase? = null
    fun getInstance(context: Context): AppDatabase =
        INSTANCE ?: synchronized(this) {
            INSTANCE ?: Room.databaseBuilder(...).build().also { INSTANCE = it }
        }
}

The synchronized block ensures only one thread creates the database.

Q7: What's the difference between a parameterized singleton and a regular singleton?

A regular singleton has no parameters — it's created once for the entire app. A parameterized singleton is created once per unique parameter set. For example, you might want a separate database instance for each user account:

class DatabaseHolder {
    companion object {
        private val instances = mutableMapOf<String, AppDatabase>()
        @Synchronized
        fun getInstance(userId: String, context: Context): AppDatabase {
            return instances.getOrPut(userId) {
                Room.databaseBuilder(context, AppDatabase::class.java, "feed_$userId.db").build()
            }
        }
    }
}

This is useful for multi-user apps. But for a simple app, a regular singleton (one database) is more common.

Let's do rapid-fire. Short answers.

Q: Paging 3 vs Paging 2. Main differences?

A: Paging 2 used DataSource (one-shot, hard to test). Paging 3 uses PagingSource (suspension-based, testable). Paging 3 added RemoteMediator for offline-first. Paging 3 is Flow-based, not LiveData.

Q: What's maxSize in PagingConfig?

A: maxSize caps the total number of items held in memory. If set to 100, Paging never holds more than 100 items. Older items are dropped as new ones load. This prevents OOM on long scrolls.

Q: How to add headers/footers to the feed?

A: Use PagingData.insertSeparators(). You provide a lambda that returns a separator item between two data items. For example, insert a "LoadMore" footer by checking if nextItem == null.

Q: What about RecyclerView instead of LazyColumn? How does LoadStateAdapter work?

A: If using RecyclerView, Paging provides a LoadStateAdapter. It's a separate adapter that shows loading/error states. You combine your main adapter and LoadStateAdapter with concatAdapter. LoadStateAdapter observes loadState and renders the appropriate UI (spinner, retry button, etc.).

Q: How to test a PagingSource?

A: Create a mock RemoteMediator or use a fake API. Call pagingSource.load(LoadParams.Refresh). Assert the returned LoadResult. You can also use PagingTest utilities from paging:paging-testing.

Q: What about coroutine exception handling? What if api.getFeed() throws?

A: RemoteMediator.load() catches and returns LoadResult.Error. Paging handles it gracefully and shows an error state to the UI. For more complex error handling (logging, analytics), you can wrap the try-catch in a higher-order function or use a custom coroutine scope with SupervisorJob.

Q: Talk about the 16ms frame budget. What causes jank?

A: Android targets 60 FPS (16ms per frame). If a frame takes > 16ms, the screen freezes for the next frame, causing jank. In a feed, jank comes from: (1) heavy item composition (reduce recompositions), (2) main thread blocking (database/network calls must be in background), (3) large lists without virtualization (LazyColumn handles this). Paging 3 + Compose + Room handles this well — Room queries are fast, Paging prefetches so no blocking on scroll, Compose only renders visible items.

Excellent. You've covered the entire design well. Let me summarize:

• Architecture: MVVM with clean separation. Paging 3 handles pagination complexity.
• Core concept: PagingSource + RemoteMediator + Room. Network and database work together for offline-first.
• UI: LazyPagingItems + collectAsLazyPagingItems(). LoadState for error/loading handling.
• Caching: cachedIn(viewModelScope) survives config changes.
• Mutations: Optimistic updates with rollback. Room invalidates PagingSource automatically.
• Advanced: Search with flatMapLatest. Retry and refresh logic.

This is a production-ready design that handles real-world scenarios: offline, config changes, errors, and user interactions. Well done.

Thank you! I focused on using Paging 3 because it's the recommended approach — it saves so much boilerplate and is battle-tested. The offline support via RemoteMediator is crucial for a real app, and cachedIn() makes config changes painless. I'm glad the design felt thorough.

Design an expense sharing app like Splitwise. Start with requirements.

Let me break this down into functional and non-functional requirements.

Functional Requirements:

• Create groups and add members to them
• Add expenses to a group (who paid, who is it split among, amounts)
• View group balances (who owes whom how much)
• Settle up (record a payment from one person to another)
• Simplify debts (minimize number of transactions needed to settle all debts)
• Offline support — users can add expenses without network connectivity, sync when connection returns

Non-Functional Requirements:

• Offline-first — entire app must work fully offline, then sync when connected
• Conflict resolution — handle cases where two users edit the same group offline simultaneously
• Survive config changes (screen rotation) without losing state
• 60fps smooth UI (Compose + Flow)
• Testable architecture (dependency injection, clean layers)

Good. Scale question — how many groups per user? How many expenses per group?

For a single user: maybe 20-50 groups. Per group: hundreds to thousands of expenses (e.g., a year-long trip split among friends). Since we load expenses in full (no pagination), we keep each group's data under a few MBs in Room.

Now sketch the architecture. How do you organize an offline-first app?

MVVM + Clean Architecture + Offline-First Pattern. Here's the flow:

Key idea: User does action → ViewModel calls UseCase → UseCase writes to Room immediately → UI updates instantly from Room Flow → WorkManager syncs to server in background.

Define your Room entities. What fields do you need for offline sync?

The key insight: every entity needs metadata to support offline sync and conflict detection.

Two users in a group both add expenses offline. When they come back online, how do you handle conflicts?

There are several conflict strategies. Let me explain the main ones and when to use each:

Walk me through your caching strategy. What if data is stale?

I use Stale-While-Revalidate combined with Stale-If-Error. Here's the pattern:

Now the synchronization layer. Show me the Repository and how SyncManager pulls and pushes data.

Repository handles both local queries and sync logic. SyncManager is a WorkManager worker that runs in the background.

Here's a nasty edge case. The user adds an expense, the app sends it to the server, the server accepts and writes it to the database — but before the response reaches the client, the app is killed (process death, network timeout, user force-closes). The client never got the 200 OK. What happens on next sync?

Without protection, the SyncManager sees the record still has isDirty = true (because we never got the success response to mark it synced). So it pushes the same expense again — and now we have a duplicate on the server.

The fix is an idempotency key. Every write request carries a unique key (typically a UUID generated client-side at creation time). The server checks: "Have I already processed this key?" If yes, it returns the existing result without creating a duplicate.

The key insight: the idempotency key is generated once when the expense is created locally and stored in Room alongside the data. Every retry of the same expense uses the same key. The server deduplicates using this key, so even if we push the same expense 5 times, the server creates it exactly once.

What about edits? If I update an expense and the client dies after the server accepts — does the same idempotency key work?

For edits, the approach changes slightly. Each edit operation gets a new idempotency key — not the entity itself, but the mutation. So when the user edits an expense, we generate a fresh UUID for that specific update request.

But there's a simpler alternative for updates: the version field already protects us. If the client retries the same edit with the same version number, and the server already applied it (bumping version from 1 to 2), the retry arrives with version 1 and gets a 409 Conflict — the client then fetches the latest, sees it matches what it wanted, and marks it synced. No duplicate harm done.

Now the ViewModel. Show me how you handle UI state with Flows and avoid boilerplate.

I use a setState helper to reduce boilerplate on StateFlow updates.

Show me a simple Compose screen for viewing a group's expenses.

Simple example using collectAsStateWithLifecycle for lifecycle safety.

Explain the Simplify Debts problem. In a group, you have net balances. How do you minimize transactions to settle all debts?

The Problem: A owes B $10, B owes C $10, C owes A $5. Instead of three transactions, A can pay C $5, B can pay C $5. That's two transactions instead of three.

Algorithm:

1. Calculate net balance per person (sum of what they paid minus what they owe).
2. Separate into creditors (positive balance) and debtors (negative balance).
3. Greedily match largest debtor with largest creditor.
4. Use two heaps (or sort) and two pointers.

Time Complexity: O(N log N) for sorting, O(N) for matching. Total O(N log N).

Space: O(N) for lists.

Quick fire questions. No need for deep explanations.

Fire away.

How does WorkManager handle no network?

Use Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED). WorkManager won't start the job until network is available.

What if user deletes the app and reinstalls?

Server is the backup. On fresh install, user logs in, then we do a full sync from server. Server data populates Room.

How do you handle group member removal?

Soft delete the member record, keep expense history intact. Block the removed member from adding new expenses to the group.

Screen rotation — how do you keep state?

ViewModel survives rotation. StateFlow keeps the latest emission. Compose resubscribes instantly. No manual state saving needed.

Process death?

SavedStateHandle stores groupId. Room persists all data. On restore, OS reconstructs ViewModel, SavedStateHandle gives back groupId, ViewModel re-observes Room.

How do you avoid jank (frame drops)?

60fps = 16ms per frame. Heavy work (sync, conflict resolution) runs on Dispatchers.IO background threads. Compose UI thread handles only UI. Room queries are fast. No blocking on main thread.

Why Hilt over manual DI?

Compile-time DI, less boilerplate, integrates with ViewModel and WorkManager natively. No service locator antipattern.

How do you test sync logic?

Mock the API and Database. Test scenarios: new record syncs, conflict detected, retry on 409, push fails, pull succeeds but push fails. Use FakeRepository for UI tests.

Excellent. You covered everything. Any final thoughts?

Offline-first is all about reliability and user trust. Sync strategies prevent data loss. Caching makes the app feel instant. The Simplify Debts problem is a classic graph algorithm that often shows up in system design rounds.

Let's start simple. Tell me the difference between debounce and throttle. When would you use each one?

Debounce waits for the user to stop doing something for N milliseconds, then fires once. Every new event resets the timer. Think search bar — you type "kotlin", pause for 300ms, then the query fires once. If you keep typing, we keep resetting the timer.

Throttle, on the other hand, fires at most once per interval — no matter how many events come in. There are two flavors:

• ThrottleFirst: emit the first event, then ignore everything for N ms.
• ThrottleLatest: sample the latest value every N ms.

Search bar: use debounce because we don't want to spam the API. Button click: use throttleFirst to prevent double-tap. Scroll listener: use throttleLatest to emit position every 500ms for analytics.

Good. Can you sketch a timeline for me? Show what happens when a user types "hel" quickly, pauses, then types "lo" with events at T0, T50, T100, T200, T350, T400, T450?

Events:    T0(h)  T50(e)  T100(l)  T200     T350(l)  T400(o)  T450

Debounce (300ms timeout):
  Timer reset each event → fires once after 300ms of silence
  Fires at: T400 (after pause), T750 (after "lo" complete)
  Result: ["hel", "lo"]

ThrottleFirst (200ms window):
  First event fires, ignore next 200ms, then allow next
  Fires at: T0(h), T250(e), T450(l) [but only first in window]
  Result: [h, e, l, o] (simplified, only first per window)

ThrottleLatest (200ms sample):
  Sample and emit every 200ms, always latest value
  Fires at: T0, T200(l), T400(o), T600
  Result: [h, l, o] (latest value each 200ms interval)
            

Show me how to build a reactive search bar using Flow. Start with the built-in debounce operator.

Kotlin Flow comes with a built-in debounce() operator. Here's a typical ViewModel:

Good. Now implement debounce yourself from scratch. Pretend Flow doesn't have it built-in.

I'll use channelFlow to manage a coroutine that delays emission:

Why distinctUntilChanged() after debounce?

Consider this: user types "ab", then backspace to "a", then types "b" again. Three separate debounce emissions: "ab", "a", "ab". But we don't want to re-query the same "ab". distinctUntilChanged() filters consecutive duplicates, so we only emit when the value actually changes.

And why flatMapLatest instead of flatMapConcat?

flatMapConcat waits for each query to finish before starting the next. If the API is slow and the user types a new query, we're still waiting on the old one. flatMapLatest cancels the in-flight request and starts a new one. For search, that's what we want — only the latest query matters.

Now implement throttleFirst from scratch. How would you do it?

Track the last emission time. Only emit if enough time has passed since the last emission:

Now throttleLatest — that's a bit trickier. Show me how you'd build it.

For throttleLatest, we need a background ticker that samples the latest value at regular intervals. I'll use channelFlow again:

When would you use throttleLatest?

Scroll position tracking for analytics. As the user scrolls, the position changes rapidly — maybe 60+ events per second. But you only want to send analytics every 500ms. ThrottleLatest captures the latest scroll position at each interval.

Show me a real Compose search bar using the debounced Flow from your ViewModel.

I'll use collectAsStateWithLifecycle to observe the Flow safely:

Now show a throttled "like" button using throttleFirst.

I'll implement throttle logic directly in the click handler:

What if you want to debounce a Compose text field itself, not a ViewModel Flow?

Use snapshotFlow() to convert Compose state into a Flow, then apply debounce:

Rapid-fire. Can you debounce a button click?

Technically yes, but bad UX. Users expect instant feedback. Use throttleFirst instead — it gives immediate visual response while blocking duplicates.

What about snapshotFlow? Does that work for debouncing Compose state?

Exactly. snapshotFlow { textState }.debounce(300) reads Compose state reactively and debounces it. Perfect for converting mutable state into reactive Flows.

Should debounce logic live in the ViewModel or Repository?

ViewModel. Debounce is a UI concern — it's about how fast the user types, not business logic. The Repository shouldn't know or care about debouncing. Keep the concern at the right layer.

What if the API is slow and debounce fires faster than the previous request completes?

That's exactly why we use flatMapLatest. It cancels the in-flight request as soon as a new query debounces through. Only the latest request matters. If you used flatMapConcat, you'd queue all requests, which defeats the purpose of debouncing.

One more: how would you test debounce logic?

Use TestDispatchers and advanceTimeBy() to skip forward in time. Emit events, advance the clock past the debounce timeout, and verify the result was emitted exactly once.

Great. Before we wrap up, give me the one-sentence summary: when would you use each one?

Debounce: When you want the action to fire once after the user stops. (Search bars, text filtering.)

ThrottleFirst: When you want instant response but prevent rapid repeats. (Button clicks, double-tap protection.)

ThrottleLatest: When you want to sample high-frequency events at intervals. (Scroll tracking, resize listeners.)

Your API call fails because the server is momentarily overloaded. What do you do—just fail immediately, or try again?

I'd retry the request. But I wouldn't retry immediately—that would hammer the server and make things worse. I'd use exponential backoff: wait 1 second, then 2 seconds, then 4 seconds. Each retry waits longer than the last, giving the server time to recover.

Why is that better than just retrying immediately?

Imagine the server is under load and starts returning 5xx errors. If every client retries immediately—say, 10,000 devices all hit retry within a second—you get the "thundering herd" problem. All those requests hit the server at the same time, and it crashes again. Now there are even more retries. It's chaos.

With exponential backoff, those 10,000 devices don't all retry at once. Some wait 1 second, some 2, some 4. The retries are spread over time. The server gets breathing room. Load drops. It recovers. Everyone succeeds.

Write a retry function with exponential backoff.

Here's a simple one:

How do you use it?

Pass any suspend function as a lambda:

Walk me through the delays.

With default settings:

• Attempt 1 fails. Wait 1000 ms (1 second).
• Attempt 2 fails. Wait 2000 ms (2 seconds).
• Attempt 3 fails. Throw exception (no more retries).

Total wait time: 3 seconds before we give up.

Good. But what if 10,000 clients all use your backoff function? They all retry at exactly 1s, 2s, 4s. Isn't that still a thundering herd, just delayed?

Exactly right. We need jitter—randomness. Instead of waiting exactly 2 seconds, wait a random amount between 0 and 2 seconds. Now 10,000 retries spread across that interval, not all at once.

Are there different jitter strategies?

A few common ones:

• Full jitter: random(0, currentDelay). We wait 0 to 2 seconds on the second attempt. Simple, spreads load well.
• Equal jitter: currentDelay/2 + random(0, currentDelay/2). Guarantees a minimum wait. Less risky if you hit a retry immediately.
• Decorrelated jitter: min(maxDelay, random(initialDelay, previousDelay * 3)). More complex, but good for high-contention scenarios.

You're using Flow for your data layer. How do you add retry?

Kotlin's Flow has a built-in retry operator. You pass a predicate that decides whether to retry based on the exception:

That's immediate retry with a fixed delay. Can you add exponential backoff?

Yes. Create an extension function that wraps retry with exponential backoff:

You have a sync job that needs to run in the background. How does WorkManager handle retry?

WorkManager has built-in backoff. When you create a work request, you specify a backoff policy:

What's the difference between EXPONENTIAL and LINEAR?

EXPONENTIAL: 10s, 20s, 40s, 80s... (doubles each time). Better for server overload—you want to back off aggressively.

LINEAR: 10s, 20s, 30s, 40s... (adds 10s each time). Better for rate-limiting—consistent, predictable waits.

For most network errors, use EXPONENTIAL.

OkHttp is transparent. Can you intercept network calls and add retry logic?

Yes. Write a custom Interceptor:

How do you register it?

Add it to the OkHttp client when building:

Why Thread.sleep and not delay()?

OkHttp interceptors run on OkHttp's thread pool, not in a coroutine context. There's no suspend context available. delay() only works in suspending functions. We have to use Thread.sleep() to block the thread.

What if the server is completely down and isn't coming back up soon? Retrying forever burns battery.

Use the Circuit Breaker pattern. It has three states:

• CLOSED: Normal operation. Requests go through.
• OPEN: Too many failures. Stop making requests. Fail immediately.
• HALF_OPEN: Cooldown has passed. Try one probe request. If it succeeds, go back to CLOSED. If it fails, return to OPEN.

Usage?

Wrap your request with the circuit breaker:

Fast ones. Should you retry on 429 Too Many Requests?

Yes, but use the Retry-After header, not exponential backoff. The server tells you exactly when to retry.

Retry on SSL/TLS errors?

No. Certificate errors won't fix themselves on retry. Fail immediately and alert the user.

What about idempotency when retrying?

Always ensure retried requests are idempotent. Use an idempotency key on POST requests, or use PUT/PATCH. If the request succeeds but the response is lost, a retry with the same key returns the cached response, not a duplicate.

Is there a built-in retry {} in Kotlin stdlib?

No. Use the extension function we wrote, or Flow.retry(). That's it.

What happens if the coroutine is cancelled during delay()?

CancellationException is thrown. It propagates, stopping all retries. This is correct—if the caller cancels the request, we shouldn't keep retrying.

Summary?

• Exponential backoff: Double wait time on each retry. Prevents hammering a failing server.
• Jitter: Add randomness. Spreads retries across time. Prevents thundering herd.
• Cap max delay: Without a cap, waits grow to minutes. Use coerceAtMost(maxDelay).
• Flow.retry(): Use for reactive streams. Predicate-based retry with built-in backoff support.
• WorkManager: Built-in backoff policy. Returns Result.retry() to trigger it. Auto-adds jitter.
• OkHttp interceptor: Network-level retry. Transparent. Use Thread.sleep() for delays (not a coroutine context).
• Circuit breaker: Stop retrying if the service is dead. Saves battery. Three states: CLOSED, OPEN, HALF_OPEN.
• Selective retry: Only retry transient errors (5xx, timeout, IO exception). Don't retry 4xx or SSL errors.

Let's build LiveData from scratch. Before we touch any Android APIs, what's the core design pattern behind LiveData?

LiveData is built on the Observer pattern. At its simplest, we need three things:

• A value holder — stores the current data.
• A list of observers — anyone interested in changes.
• A notification mechanism — when the value changes, notify all observers.

Let's start with the simplest possible version:

class MyLiveData<T> {

    private var value: T? = null
    private val observers = mutableListOf<(T) -> Unit>()

    fun getValue(): T? = value

    fun setValue(newValue: T) {
        value = newValue
        observers.forEach { it(newValue) }
    }

    fun observe(observer: (T) -> Unit) {
        observers.add(observer)
        // Immediately dispatch current value (sticky behavior)
        value?.let { observer(it) }
    }

    fun removeObserver(observer: (T) -> Unit) {
        observers.remove(observer)
    }
}

This is functional but has zero lifecycle awareness. If an Activity is destroyed and we still hold a reference to its observer, we leak memory. That's what makes LiveData special — it auto-removes observers when the lifecycle dies.

Good foundation. Now tell me about the sticky behavior you just mentioned — when you call observe(), the observer immediately gets the current value. Is that always desirable?

It's a double-edged sword. For UI state (like a list of items), sticky is perfect — when you rotate the screen and the Fragment re-subscribes, it immediately gets the latest list without re-fetching.

But for one-time events like showing a Snackbar or navigating to a screen, sticky is a problem. You show the Snackbar, rotate, re-subscribe, and it shows again. This is the famous SingleLiveEvent problem.

The community solved this with wrappers like Event<T> that track whether the value has been consumed:

class Event<out T>(private val content: T) {

    private var hasBeenHandled = false

    fun getContentIfNotHandled(): T? {
        return if (hasBeenHandled) null
        else {
            hasBeenHandled = true
            content
        }
    }
}

With StateFlow + Channels, this problem goes away — you use StateFlow for state and Channel for events.

Let's make our LiveData lifecycle-aware. Walk me through the Android Lifecycle API and how LiveData hooks into it.

Android's Lifecycle library gives us two key interfaces:

• LifecycleOwner — any class that has a lifecycle (Activity, Fragment). Exposes lifecycle: Lifecycle.
• LifecycleObserver / LifecycleEventObserver — a class that wants to react to lifecycle changes (CREATED, STARTED, RESUMED, DESTROYED, etc.).

The key states are:

// Lifecycle.State (enum, ordered)
DESTROYED  →  INITIALIZED  →  CREATED  →  STARTED  →  RESUMED
                                  ↑            ↑
                            onStop goes    LiveData considers
                            back here      "active" from here

LiveData considers an observer active when the LifecycleOwner is at least STARTED. It only dispatches values to active observers. When the owner reaches DESTROYED, LiveData auto-removes the observer. No leaks.

Let me upgrade our class:

class MyLiveData<T> {

    private var value: T? = null
    private var version = 0  // tracks how many times setValue called

    // Each observer wrapper tracks its own last-seen version
    private val observers = mutableMapOf<(T) -> Unit, ObserverWrapper>()

    private inner class ObserverWrapper(
        val observer: (T) -> Unit,
        val lifecycle: Lifecycle
    ) : LifecycleEventObserver {

        var lastVersion = 0

        override fun onStateChanged(
            source: LifecycleOwner,
            event: Lifecycle.Event
        ) {
            // Auto-remove on DESTROYED
            if (lifecycle.currentState == Lifecycle.State.DESTROYED) {
                removeObserver(observer)
                return
            }
            // Dispatch if active and has pending value
            dispatchIfNeeded(this)
        }
    }

    fun observe(owner: LifecycleOwner, observer: (T) -> Unit) {
        // Don't register if already destroyed
        if (owner.lifecycle.currentState == Lifecycle.State.DESTROYED) return

        val wrapper = ObserverWrapper(observer, owner.lifecycle)
        observers[observer] = wrapper
        owner.lifecycle.addObserver(wrapper)
    }

    fun removeObserver(observer: (T) -> Unit) {
        val wrapper = observers.remove(observer)
        wrapper?.lifecycle?.removeObserver(wrapper)
    }

    private fun isActive(wrapper: ObserverWrapper): Boolean {
        return wrapper.lifecycle.currentState.isAtLeast(
            Lifecycle.State.STARTED
        )
    }

    private fun dispatchIfNeeded(wrapper: ObserverWrapper) {
        if (!isActive(wrapper)) return
        if (wrapper.lastVersion >= version) return  // already seen
        wrapper.lastVersion = version
        value?.let { wrapper.observer(it) }
    }
}

Why do we track a version number instead of just comparing old vs new value?

Two reasons:

• Same value, different intent: If I call setValue("loading") twice, both should dispatch. Version-based tracking ensures every setValue call triggers observers, even if the value is identical. Equality checks would silently swallow the second one.
• Background observer catch-up: When an observer goes inactive (Fragment in back stack) and comes back, we compare its lastVersion with the global version. If the global version is higher, the observer missed updates and we dispatch the latest value. Without versioning, we'd have no way to know if the observer is stale.

This is exactly how the real LiveData works internally — it has a mVersion field starting at -1 (START_VERSION) and increments on every setValue.

Now let's add thread-safety. LiveData has both setValue and postValue. What's the difference and how do we implement them?

The rule is simple:

• setValue() — must be called on the main thread. Dispatches synchronously to all active observers immediately.
• postValue() — can be called from any thread. Posts a Runnable to the main thread's Handler that calls setValue().

class MyLiveData<T> {

    private var value: T? = null
    private var version = 0
    private val observers = mutableMapOf<(T) -> Unit, ObserverWrapper>()

    // For postValue — pending value from background thread
    private val postLock = Any()
    private var pendingValue: T? = null
    private var hasPendingPost = false

    private val mainHandler = Handler(Looper.getMainLooper())

    private val postRunnable = Runnable {
        var newValue: T?
        synchronized(postLock) {
            newValue = pendingValue
            hasPendingPost = false
        }
        @Suppress("UNCHECKED_CAST")
        setValue(newValue as T)
    }

    fun setValue(newValue: T) {
        // Must be on main thread
        check(Looper.myLooper() == Looper.getMainLooper()) {
            "setValue must be called on the main thread"
        }
        version++
        value = newValue
        observers.values.forEach { dispatchIfNeeded(it) }
    }

    fun postValue(newValue: T) {
        // Can be called from any thread
        val shouldPost: Boolean
        synchronized(postLock) {
            shouldPost = !hasPendingPost
            hasPendingPost = true
            pendingValue = newValue
        }
        if (shouldPost) {
            mainHandler.post(postRunnable)
        }
    }

    // ... observe, removeObserver, dispatchIfNeeded same as before
}

I see you only post the Runnable if there isn't one already pending. What happens if I call postValue("A") then immediately postValue("B") from a background thread?

The observer only sees "B". Here's the timeline:

• postValue("A") — sets pendingValue = "A", hasPendingPost = true, posts the Runnable.
• postValue("B") — sets pendingValue = "B", but hasPendingPost is already true, so it does not post another Runnable.
• When the Runnable executes on main thread, it reads pendingValue which is now "B" and calls setValue("B").

This is a well-known gotcha. If you need every value delivered, use setValue on the main thread, or better yet — use StateFlow which has different semantics (conflation is explicit via MutableStateFlow).

This is also why real LiveData docs say: "If you called postValue multiple times before the main thread executed, only the last value would be dispatched."

In real codebases, I always see this pattern in ViewModels — a private MutableLiveData with a public LiveData. Why? And how does Google's actual class hierarchy work?

The class hierarchy is simple:

// Google's actual implementation
open class LiveData<T> {
    // setValue and postValue are PROTECTED
    protected open fun setValue(value: T) { ... }
    protected open fun postValue(value: T) { ... }

    // getValue is PUBLIC
    open fun getValue(): T? = ...

    // observe is PUBLIC
    fun observe(owner: LifecycleOwner, observer: Observer<T>) { ... }
}

class MutableLiveData<T> : LiveData<T>() {
    // Just makes setValue and postValue PUBLIC
    public override fun setValue(value: T) = super.setValue(value)
    public override fun postValue(value: T) = super.postValue(value)
}

MutableLiveData literally just changes visibility — from protected to public. That's it. No extra logic.

The backing-field pattern in ViewModel:

class FeedViewModel : ViewModel() {

    // Private — only ViewModel can mutate
    private val _posts = MutableLiveData<List<Post>>()

    // Public — UI can only read/observe
    val posts: LiveData<List<Post>> = _posts

    fun loadPosts() {
        viewModelScope.launch {
            val result = repository.getPosts()
            _posts.value = result   // setValue on main thread
        }
    }
}

This enforces unidirectional data flow. The Fragment observes posts but can never accidentally call setValue on it because the public type is LiveData (not MutableLiveData). Only the ViewModel controls mutations.

The same pattern exists for StateFlow:

private val _posts = MutableStateFlow<List<Post>>(emptyList())
val posts: StateFlow<List<Post>> = _posts.asStateFlow()

LiveData has Transformations.map and Transformations.switchMap. Can you implement map from scratch and explain when you'd use switchMap?

map transforms the value synchronously. Under the hood, it creates a MediatorLiveData that observes the source and applies the transform:

// Our from-scratch implementation
class MediatorLiveData<T> : MutableLiveData<T>() {

    private val sources = mutableMapOf<LiveData<*>, Observer<*>>()

    fun <S> addSource(source: LiveData<S>, onChanged: (S) -> Unit) {
        val observer = Observer<S> { onChanged(it) }
        sources[source] = observer
        source.observeForever(observer)
    }

    fun <S> removeSource(source: LiveData<S>) {
        val observer = sources.remove(source)
        if (observer != null) {
            @Suppress("UNCHECKED_CAST")
            source.removeObserver(observer as Observer<S>)
        }
    }
}

// map — synchronous transform
fun <X, Y> LiveData<X>.map(transform: (X) -> Y): LiveData<Y> {
    val result = MediatorLiveData<Y>()
    result.addSource(this) { value ->
        result.setValue(transform(value))
    }
    return result
}

switchMap is for async or dynamic sources — the transform returns a new LiveData, and switchMap swaps the subscription:

// switchMap — swap underlying LiveData source
fun <X, Y> LiveData<X>.switchMap(
    transform: (X) -> LiveData<Y>
): LiveData<Y> {
    val result = MediatorLiveData<Y>()
    var currentSource: LiveData<Y>? = null

    result.addSource(this) { trigger ->
        val newSource = transform(trigger)
        if (currentSource == newSource) return@addSource

        currentSource?.let { result.removeSource(it) }
        currentSource = newSource
        result.addSource(newSource) { value ->
            result.setValue(value)
        }
    }
    return result
}

Classic use case: user types a search query, you need to swap the Room database query:

class SearchViewModel : ViewModel() {
    private val query = MutableLiveData<String>()

    // Every time query changes, swap to a new Room LiveData
    val results: LiveData<List<Item>> = query.switchMap { q ->
        repository.search(q)  // returns LiveData<List<Item>>
    }

    fun onQueryChanged(text: String) {
        query.value = text
    }
}

Now that you've built LiveData from scratch, compare it to StateFlow. When would you still use LiveData today, and when is StateFlow strictly better?

Here's the honest comparison:

StateFlow wins on:

• Platform-agnostic: StateFlow is pure Kotlin — works in KMP (iOS, Desktop, Server). LiveData is Android-only, tied to androidx.lifecycle.
• Rich operators: combine, flatMapLatest, debounce, distinctUntilChanged, filter — all built into Flow. LiveData needs MediatorLiveData hacks for anything beyond basic map/switchMap.
• Coroutine-native: StateFlow lives in the coroutine world. No awkward bridging between callbacks and coroutines.
• No sticky-event problem: Use StateFlow for state, Channel for one-time events. Clean separation.
• Initial value required: MutableStateFlow<T>(initialValue) forces you to think about the initial state. LiveData starts as null by default, leading to NullPointerExceptions.

LiveData still has:

• Built-in lifecycle awareness: liveData.observe(viewLifecycleOwner) auto-manages subscriptions. With StateFlow, you need collectAsStateWithLifecycle() in Compose or repeatOnLifecycle(STARTED) in Views — it's one extra line, but you must remember it.
• Java-friendly: If your codebase is still mixed Java/Kotlin, LiveData works natively in Java. Flows require coroutines which are Kotlin-only.

The migration path:

// LiveData in ViewModel
private val _state = MutableLiveData<UiState>()
val state: LiveData<UiState> = _state

// StateFlow equivalent
private val _state = MutableStateFlow(UiState.Loading)
val state: StateFlow<UiState> = _state.asStateFlow()

// In Fragment (View system)
// LiveData:
viewModel.state.observe(viewLifecycleOwner) { render(it) }

// StateFlow:
viewLifecycleOwner.lifecycleScope.launch {
    viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {
        viewModel.state.collect { render(it) }
    }
}

// In Compose (no difference in complexity)
// LiveData:
val state by viewModel.state.observeAsState()

// StateFlow:
val state by viewModel.state.collectAsStateWithLifecycle()

Bottom line: For new projects, use StateFlow everywhere. Google's own Android team recommends it. LiveData is not deprecated, but it's in maintenance mode — no new features. If you're in an existing codebase with LiveData, migrate gradually using .asFlow() and .asLiveData() bridge extensions.

You've been using observe(owner, observer) which is lifecycle-aware. But there's also observeForever. When do you use it and what's the risk?

observeForever skips lifecycle entirely — the observer always receives updates regardless of the owner's state. You must manually call removeObserver or you'll leak.

There are two legitimate uses:

• Unit tests: Tests don't have a LifecycleOwner, so you use observeForever with InstantTaskExecutorRule to make LiveData dispatch synchronously on the test thread.
• MediatorLiveData internals: When a MediatorLiveData adds a source, it uses observeForever on that source, managing cleanup itself.

// Test setup for LiveData
@get:Rule
val instantTaskRule = InstantTaskExecutorRule()

@Test
fun `loadPosts updates livedata`() {
    val viewModel = FeedViewModel(fakeRepo)
    val values = mutableListOf<List<Post>>()

    viewModel.posts.observeForever { values.add(it) }

    viewModel.loadPosts()

    assertEquals(1, values.size)
    assertEquals(3, values[0].size)
}

// With StateFlow, testing is simpler — no Rule needed
@Test
fun `loadPosts updates stateflow`() = runTest {
    val viewModel = FeedViewModel(fakeRepo)

    viewModel.loadPosts()

    assertEquals(3, viewModel.posts.value.size)
}

Notice the StateFlow test is simpler — no observer registration, no Rule. You just read .value directly. Another point for StateFlow.

Let's put it all together. Show me the final, complete implementation of our from-scratch LiveData with all the pieces we discussed.

Here's the complete implementation with lifecycle awareness, setValue/postValue, observeForever, and proper cleanup:

open class MyLiveData<T> {

    @Volatile
    private var value: T? = null
    private var version = -1  // START_VERSION, like Google's

    private val observers = mutableMapOf<Observer<T>, ObserverEntry>()
    private val mainHandler = Handler(Looper.getMainLooper())

    // --- postValue machinery ---
    private val postLock = Any()
    private var pendingValue: Any? = NOT_SET
    private val postRunnable = Runnable {
        val newValue: Any?
        synchronized(postLock) {
            newValue = pendingValue
            pendingValue = NOT_SET
        }
        @Suppress("UNCHECKED_CAST")
        setValue(newValue as T)
    }

    // --- Value access ---

    open fun getValue(): T? = value

    protected open fun setValue(newValue: T) {
        assertMainThread("setValue")
        version++
        value = newValue
        dispatchToAll()
    }

    protected open fun postValue(newValue: T) {
        val shouldPost: Boolean
        synchronized(postLock) {
            shouldPost = pendingValue === NOT_SET
            pendingValue = newValue
        }
        if (shouldPost) mainHandler.post(postRunnable)
    }

    // --- Lifecycle-aware observe ---

    fun observe(owner: LifecycleOwner, observer: Observer<T>) {
        assertMainThread("observe")
        if (owner.lifecycle.currentState == Lifecycle.State.DESTROYED) return

        val entry = LifecycleBoundEntry(observer, owner)
        observers[observer] = entry
        owner.lifecycle.addObserver(entry)
    }

    fun observeForever(observer: Observer<T>) {
        assertMainThread("observeForever")
        val entry = AlwaysActiveEntry(observer)
        observers[observer] = entry
        dispatchIfNeeded(entry)
    }

    fun removeObserver(observer: Observer<T>) {
        assertMainThread("removeObserver")
        val entry = observers.remove(observer) ?: return
        if (entry is LifecycleBoundEntry) {
            entry.owner.lifecycle.removeObserver(entry)
        }
    }

    // --- Dispatch logic ---

    private fun dispatchToAll() {
        observers.values.forEach { dispatchIfNeeded(it) }
    }

    private fun dispatchIfNeeded(entry: ObserverEntry) {
        if (!entry.isActive()) return
        if (entry.lastVersion >= version) return
        entry.lastVersion = version
        value?.let { entry.observer.onChanged(it) }
    }

    // --- Observer wrappers ---

    private abstract inner class ObserverEntry(
        val observer: Observer<T>
    ) {
        var lastVersion = -1  // matches START_VERSION
        abstract fun isActive(): Boolean
    }

    private inner class LifecycleBoundEntry(
        observer: Observer<T>,
        val owner: LifecycleOwner
    ) : ObserverEntry(observer), LifecycleEventObserver {

        override fun isActive(): Boolean =
            owner.lifecycle.currentState.isAtLeast(
                Lifecycle.State.STARTED
            )

        override fun onStateChanged(
            source: LifecycleOwner,
            event: Lifecycle.Event
        ) {
            if (source.lifecycle.currentState == Lifecycle.State.DESTROYED) {
                removeObserver(observer)
                return
            }
            dispatchIfNeeded(this)
        }
    }

    private inner class AlwaysActiveEntry(
        observer: Observer<T>
    ) : ObserverEntry(observer) {
        override fun isActive() = true
    }

    companion object {
        private val NOT_SET = Any()
        private fun assertMainThread(method: String) {
            check(Looper.myLooper() == Looper.getMainLooper()) {
                "$method must be called on the main thread"
            }
        }
    }
}

// MutableLiveData — just promotes visibility
class MyMutableLiveData<T> : MyLiveData<T>() {
    public override fun setValue(value: T) = super.setValue(value)
    public override fun postValue(value: T) = super.postValue(value)
}

// Observer interface
fun interface Observer<T> {
    fun onChanged(value: T)
}