Developing Order History in Mobile Apps
Order history looks simple: a list with cards, status, date, amount. But behind this simplicity lies several non-trivial tasks — pagination with different loading strategies, correct status display with real-time updates, and a details screen that needs to open from push notifications.
Pagination and loading
Cursor-based pagination is preferable to offset for order history: user scrolls down, new items are added, instead of the entire list shifting. In React Native — FlatList with onEndReached (triggers onEndReachedThreshold * viewport from the end). Typical mistake: onEndReached fires multiple times in quick succession on fast scroll. Solution — isLoadingMore flag + check before request.
On Flutter — ScrollController with addListener, check position.pixels >= position.maxScrollExtent - 200. Or ListView.builder with itemCount: items.length + (hasMore ? 1 : 0) — last item renders CircularProgressIndicator.
Caching. First 20–30 orders cache locally — user sees them instantly next time, while background update runs. On Android — Room with @Dao query by userId, sorted by date. In RN — MMKV for fast IO (10x faster than AsyncStorage on large volumes).
Order statuses and real-time
Status "in transit" should update without app reload. Three approaches:
-
WebSocket —
socket.io-clientin RN orweb_socket_channelon Flutter. Subscribe to specific order channel by its id. - Server-Sent Events — simpler than WebSocket for one-way updates.
-
Polling — every 30–60 seconds, as WebSocket fallback. Via
useEffect+setIntervalin RN,Timer.periodicon Flutter.
Visual display of statuses — timeline with steps (created → confirmed → assembling → handed to courier → delivered). Each step with icon and timestamp. Color coding: green — completed, blue — current, gray — upcoming, red — canceled/error.
From practice: food delivery app, iOS Swift + UIKit. Order history opened from push and showed details correctly — only if app was already running. On cold start from notification, details screen opened empty. Reason: deep link processed before login flow completed. Added pending deep links queue — after successful login, navigation executed from queue.
Details screen
Order details include: item list with images and quantities, delivery address, courier info (name, phone, photo), map with tracking, total with breakdown.
Map with tracking — separate complexity. MapKit (iOS) / Google Maps SDK (Android) / flutter_map (Flutter). Courier marker updates via WebSocket. Polyline route — via Directions API. Minimum 1–2 additional days of work.
"Reorder" button — adds all items to cart with stock check. Unavailable items — notify user separately, don't silently skip.
What's included
- Order list with pagination (cursor-based)
- Order card: number, date, status, amount, item preview
- Details screen with full composition and status timeline
- Filtering by status (active / completed / canceled)
- Recent orders caching for offline
- "Reorder" button
- Deep link support for opening specific order from push notification
Timeline
2–3 business days — list with details and statuses. With real-time courier tracking on map — plus 1–2 days. Price calculated individually.