Sample questions
Mobile Networking OfflineDifficulty 1
In an "offline-first" mobile app architecture, what is treated as the source of truth for the UI?
- aThe local on-device store✓
- bThe remote server, so the UI always waits for a network response before rendering
- cWhichever copy was fetched most recently, local or remote, decided per screen
- dAn in-memory cache that is cleared and rebuilt every time the app is reopened
Explanation:Offline-first means the UI binds to local storage; the network layer syncs data into that local store in the background, so the app is usable with or without connectivity.
Mobile Networking OfflineDifficulty 2
What best describes an "optimistic update" when a user performs an action (e.g. marking an item as done) in a mobile app?
- aThe action is disabled until the server confirms it can succeed
- bThe UI updates immediately, before the server confirms it✓
- cThe app waits for a loading spinner to finish before showing any change
- dThe action is queued silently and the user is told to check back tomorrow
Explanation:Optimistic update assumes success and updates the UI right away, giving instant feedback; if the server later rejects the change, the app must roll it back.
Mobile Networking OfflineDifficulty 2
A user taps "like" on a post; the UI instantly shows it as liked (optimistic update). The server request then fails with an error. What should the app do?
- aLeave the UI as liked and quietly retry the request forever in the background
- bCrash the screen so the user notices something went wrong
- cRevert the UI and show an error✓
- dAsk the user to restart the app before showing any post content again
Explanation:When the underlying request fails, the optimistic change must be rolled back to the last known-good state, and the user should be informed so they can retry or understand what happened.
Mobile Networking OfflineDifficulty 2
The same note was edited offline on a phone and, separately, on a tablet while both were disconnected. When both come back online, a "last-write-wins" strategy is applied. What happens?
- aBoth edits are kept and shown to the user as two separate notes
- bThe app refuses to sync until the user manually deletes one device's copy
- cThe edit with the shorter text automatically wins because it is simpler
- dThe most recent edit overwrites the other✓
Explanation:Last-write-wins resolves conflicts by timestamp: whichever change was made later replaces the other, which means the earlier edit's content is silently discarded — a known tradeoff of this strategy.
Mobile Networking OfflineDifficulty 1
What is the basic purpose of a "retry" mechanism for a failed network request in a mobile app?
- aTo automatically resend the request, since some failures are temporary✓
- bTo permanently disable that feature for the user's account
- cTo switch the app into offline mode and never contact the server again
- dTo delete the local data related to that request so it does not get shown as stale
Explanation:Many network failures are transient (dropped packet, momentary signal loss), so retrying the same request after a short wait often succeeds without any user action needed.
Mobile Networking OfflineDifficulty 2
An app retries a failed request after fixed 1-second waits every time: 1s, 1s, 1s, 1s... What is the main downside of this fixed-delay retry compared to exponential backoff?
- aIt uses noticeably more device storage than exponential backoff would
- bIf the server is struggling, clients keep hammering it at the same rate instead of easing off✓
- cIt cannot be implemented without a third-party networking library
- dIt requires the user to manually confirm every single retry attempt
Explanation:A constant retry interval does not adapt to sustained trouble: if the server (or network path) is degraded, all clients keep pounding it at the same rate. Exponential backoff spaces retries out further apart over time, reducing load during an outage.