Mobile work spans more than one request or screen
The company intranet combines Home, Messenger, and Work tabs with mail, approvals, schedules, documents, and organization information. Slow requests and notification launches can expose data from different moments.
I worked on preserving readable state, opening the correct destination from notifications, and preventing partial failures or late responses from looking like successful current results.
Make data sources and completion states explicit
Cache first, then replace with the network result
The mail inbox paints its local SQLite snapshot before receiving live data. Cache-only and network reads are separate so the user starts with readable content and the same screen can then receive the latest result.
Route notifications into their actual context
I connected mail and approval notifications to their detail screens, including launch-time routing. FCM token rotation re-registers the token, and channel mute state is reflected while connected.
Distinguish partial failure and stale responses
Mail and approval batch actions distinguish transport failures, partial success, and duplicate results. Late responses are discarded after page changes instead of replacing the current list.
Resume training from server-owned progress
I carried lastPositionSec from the training response through the domain model to the player. Both the native video player and YouTube path receive the resume position when the user reopens the lesson.
More predictable behavior around everyday interruptions
Mail starts with readable cached content and swaps in fresh results. Notifications open the related document, batch actions report actual completion, and training screens receive saved playback progress.
The work focuses on explaining which state is visible and what a request completed when connectivity, navigation, and background events overlap.
Trace
- Flutter
- iOS and Android app
- BLoC + SQLite
- State and cache-then-network reads
- SSE + FCM
- Real-time updates and push destinations
