Noodo Driver
Order Delivery App
Driver app for Noodo Bakers deliveries: accept orders, navigate live, stream GPS in the background, and complete handoffs with QR verification, Flutter + Socket.IO on the shared delivery API.
- Role
- Full-stack developer
- Timeline
- Jun 2026 — Sep 2026
- Status
- Completed
Overview
Noodo Ride is the driver-facing half of the Noodo Bakers delivery platform. While the customer app handles ordering and payment, this app owns acceptance, navigation, live location, and proof of pickup/delivery.
Built in Flutter with clean architecture (domain / data / presentation), Riverpod, GoRouter, and Dio + Retrofit against the same Node API. Drivers see ready orders, accept or decline, start delivery on a Gebeta map with route and ETA, and complete the run with QR scanning and status updates. During an active delivery, a foreground location service keeps GPS flowing over Socket.IO so the customer side can track the driver even when the app is backgrounded.
Shows production delivery-ops work: realtime sockets, background location, map routing, and a tight order state machine, not just list/detail screens.
Problem
- Drivers needed a focused ops app, not the customer UI, to accept, navigate, and close deliveries reliably.
- Customer live-tracking only works if the driver’s GPS stays online while the phone is locked or backgrounded.
- Pickup/handoff needed a clear verification step so wrong bags and disputed completions drop.
Approach
- Shipped a Flutter driver app on the shared delivery API with a clean accept → navigate → complete flow.
- Ran foreground location + Socket.IO so driver position streams during active deliveries.
- Added QR scanning and explicit status transitions (accept, start, complete) tied to order state on the backend.
Challenges
- Keeping location and socket state healthy across app backgrounding, permission denials, and reconnects.
- Aligning driver actions with customer-visible order status without double-updates or stuck “out for delivery” jobs.
- Making map + bottom-sheet delivery UX usable one-handed on the road.
Results
- A production driver client that closes the loop with the Noodo customer app and API.
- Realtime tracking and verified handoffs, the hard parts of delivery ops, not just order lists.
- Clear evidence of systems thinking across a multi-app product (customer + driver + API).
Architecture
Key features
- Driver auth and secure session (token refresh, secure storage)
- Home: stats, ready orders, active delivery card
- Order list with filters and status tracking
- Accept / cancel delivery assignment
- Start delivery → out-for-delivery flow
- Live map: restaurant + customer route, ETA, markers (Gebeta)
- Foreground GPS tracking while delivering (Socket.IO location stream)
- QR scanner for pickup / handoff verification
- Call customer / need-help actions from order detail
- Push notifications (FCM) for new assignments
- Profile: edit details, change password, delivery stats
- Delivery success confirmation screen
Mobile
- Flutter driver app (Android / iOS)
- Feature-first clean architecture: domain, data, presentation
- Riverpod + GetIt for state and DI
- GoRouter for auth-aware navigation
Networking & realtime
- Dio + Retrofit + Freezed against yamfoods-mobile-api
- Auth / retry / logging interceptors; secure token storage
- Socket.IO for order assignment events and live driver location
Delivery ops
- Order state machine: ready → accepted → out for delivery → delivered
- Foreground location service bound to active delivery
- Gebeta map routing, ETA, and delivery bottom sheet
- QR scan dialog for handoff verification
Platform services
- FCM + local notifications for new jobs
- Permission flows for location and notifications
- Profile and session management
Built at
MALTT Enterprise PLCBackend and Mobile Application Developer