Transport Monitoring Mobile App Development
Dispatcher looks at the map — 40 trucks, three of them haven't updated position for 20 minutes. Did the broadcast freeze? No network in the mountains? Or GPS antenna disabled intentionally? These are three different scenarios with different responses, and the app should distinguish them — not just color the dot gray.
What the Dispatcher Actually Needs
Monitoring app — not just "markers on a map." Dispatcher works with fleet of 20–200 units and needs:
- Real-time with metadata: coordinate + speed + direction + engine status + tracker battery level
- Track history: route for day/week with geocoded address of stops
- Geofencing: notification on enter/exit zone (warehouse, construction site, restricted territory)
- Alerts: speeding, long idle with engine running, deviation from route
All this requires different architecture on client.
Real-time Telematics Data Reception
Telematics blocks (Teltonika FMB, Wialon TK, Navixy OEM) transmit data via TCP or GPRS to server. Mobile app doesn't connect to trackers directly — it gets already-processed stream via WebSocket or MQTT client.
On Android use OkHttp WebSocket with EventBus or SharedFlow for delivering updates to ViewModel. On iOS — URLSessionWebSocketTask (iOS 13+) or Starscream for older targets. Updates come as JSON or protobuf — protobuf preferred with large fleet: 40 vehicles × 10 fields in protobuf takes ~1.5 KB vs ~8 KB in JSON.
Map: Performance with Large Fleet
200 markers on map with animation — already tough. Key solutions:
Annotations instead of SVG overlays. On iOS MKAnnotationView handles up to ~300 markers without noticeable lag. Beyond that — use MKOverlay with custom renderer drawing all points in one CALayer. On Android Google Maps SDK degrades after ~500 markers — switch to Mapbox Maps SDK v10 with SymbolLayer based on GeoJSON source: entire fleet updates with single source.setGeoJson(featureCollection) call.
Server-side clustering. At zoom < 11 clusters computed on server (PostGIS ST_ClusterKMeans), client gets ready centroids with count. Local clustering (Supercluster) suitable for fleets up to 300–400 units.
Movement animation. Tracker position updates every 10–30 seconds — marker shouldn't "jump." ValueAnimator with LatLngInterpolator (Android) or CABasicAnimation with CGPoint interpolation (iOS) — marker smoothly "glides" to new point.
Track History and Geocoding
Track for day — 2000–8000 points depending on recording interval. Display via Polyline / MKPolyline, but not entire track at once: load bbox of visible map area and request points only for it. At zoom "entire day" — discretize track on server via Douglas-Peucker algorithm.
Stop addresses — reverse geocoding via Google Maps Geocoding API or OpenStreetMap Nominatim (self-hosted). Cache results in SQLite to avoid repeating requests on history scroll.
Alerts and Notifications
Speeding, geofence events, long idle — triggers computed on server, push notification comes via FCM/APNs. On iOS use UNNotificationCategory with UNNotificationAction — directly from notification can open map with specific vehicle.
Geozones — GeoJSON polygons, ST_Contains check in PostgreSQL + PostGIS on each incoming tracker message. Mobile client only displays geozones and receives alerts — doesn't compute intersections locally.
Development Stages and Timeline
Mobile monitoring app developed parallel with telematics processing server or as overlay over existing platform (Wialon, Gurtam, Navixy — all provide SDK/API).
- Audit of telematics platform and API
- Dispatcher interface design: map, vehicle list, history, alerts
- Development: map → real-time → history → geozones → notifications
- Load testing (simulate 200+ trackers with 30 sec update frequency)
- Publication
MVP (map + real-time + history): 6–10 weeks. Full platform with geozones, alerts, mileage analytics and reports: 3–5 months. Cost calculated after existing infrastructure audit.