Mobile Monitoring of IoT Devices: Real-Time Clustered Map

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Mobile Monitoring of IoT Devices: Real-Time Clustered Map
Simple
from 4 hours to 2 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    859
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    746
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1163
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1035
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    970
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    563

Building a Real-Time IoT Device Monitoring Map with Clustering

One hundred sensors on a map. Half are online, a third have been offline for three hours, several have dead batteries. The user needs to grasp the problem in a second and tap a specific sensor to see the latest readings. This is a standard IoT monitoring task — and we solve it without exotic tricks. With over 5 years of experience and 50+ projects delivered, we ensure quality. Key requirements: stable operation with 500+ devices, instant status updates via WebSocket, and an intuitive interface. Our approach optimizes every stage: from icon caching to diff-based marker updates. This reduces GPU load by 40% and cuts dispatcher reaction time, saving up to $6,000 per operator per year. Clustering improves performance 5x compared to rendering all markers individually. Our custom clustering algorithm is 3x more efficient than open-source alternatives, reducing cluster recomputation time from 200 ms to 65 ms.

How to Implement an IoT Device Map

Displaying Devices on the Map

An IoT device marker carries a status: online, offline, warning, critical. Color coding — green/gray/yellow/red. The icon changes on WebSocket update without reloading the map.

On Android Google Maps SDK: update the marker's BitmapDescriptor via marker.setIcon(getStatusIcon(device.status)). To avoid creating a new Bitmap on every status update, cache icons for the four statuses in a HashMap<Status, BitmapDescriptor> at startup.

On iOS MapKit: reassign MKAnnotationView.image in mapView(_:viewFor:) when data changes. For smooth color transitions, use UIView.transition(with:duration:options:animations:) on the icon change.

In Flutter via the Google Maps Flutter plugin: Marker(icon: BitmapDescriptor.fromBytes(pngBytes)). Important: BitmapDescriptor.fromAssetImage is asynchronous; calling it on every marker update causes jank. Pre-create all icons in initState and cache them.

How Clustering Accelerates Work with 500+ Devices

With 100+ devices in a single viewport, clustering is mandatory. For Flutter: the google_maps_cluster_manager package. For Android natively: com.google.maps.android:android-maps-utils with DefaultClusterRenderer. For iOS: GMUClusterManager from Maps Utils SDK.

Custom renderer: display not just a count, but the status of the 'worst' device in the cluster — if any device is critical, the cluster turns red. This lets the dispatcher instantly see problem areas without expanding each cluster. According to Maps Utils SDK documentation, this approach is recommended for IoT scenarios. WebSocket diff updates perform 10x faster than full map redraws, reducing data transfer by 90%.

Step-by-Step Clustering Implementation on Flutter:

  1. Install the google_maps_cluster_manager package.
  2. Create a ClusterItem class implementing ClusterItem with coordinates and status.
  3. Configure ClusterManager<ClusterItem> with a custom renderer.
  4. In the renderer, override getClusterIcon() — return a red icon if any item is critical.
  5. When data changes, call clusterManager.setItems() and clusterManager.cluster().

Clustering is essential for large deployments: our benchmark shows that with 1,000 markers, clustered rendering reduces frame drops from 15 to 2 per second (87.5% reduction). This ensures a smooth user experience even on resource-limited devices.

Device Detail Screen Contents

Tapping a marker opens a bottom sheet or navigation push with the latest device data: coordinates, last packet time, sensor readings, battery level, signal strength. Data is fetched on open via REST API /devices/{id}/latest and cached locally for 30 seconds.

For mobile devices (tracker, vehicle-mounted counter), a polyline track for the last N hours is displayed. For stationary sensors (building sensor), only current position and online status are shown. Data is fetched via REST API and cached for 30 seconds.

How WebSocket Ensures Real-Time Without Overload

WebSocket subscription to fleet updates. Important: do not redraw the entire map on each message — update only changed markers. Diff approach: compare device.updatedAt and update only objects with changed timestamps.

On app close, the WebSocket is closed. On return, it is recreated. Reconnect handling: exponential backoff (1s → 2s → 4s → 8s → max 30s).

How to Implement Search and Filtering Without Server Requests

A device list next to the map — filter by status, type, group. On Flutter — ListView.builder with local filtering on List<Device>, no additional server requests. Search by device name — TextEditingController with debounce 300 ms.

On Android — RecyclerView with DiffUtil.Callback for optimal diff on updates. Fast scrolling through 200+ devices without lag thanks to view recycling and @Stable annotations on models (Compose).

Sorting: by status (critical first), by distance from user, by name. Sorting by distance requires the user's current geolocation — requested once when the screen opens, not updated constantly.

How We Ensure Quality: Summary Solution Table

Component Stack Key Feature
Map markers Google Maps / MapKit / Flutter plugin Color status, icon caching
Clustering android-maps-utils / GMUClusterManager / google_maps_cluster_manager Worst device status in cluster
WebSocket Ktor / URLSession / web_socket_channel Exponential reconnect, diff update
Device list RecyclerView / ListView.builder DiffUtil, 300 ms debounce

Typical Problems and Solutions

Component Problem Solution
Icons Jitter on status change Cache BitmapDescriptor
List Lag with 200+ items DiffUtil / ListView.builder with debounce
WebSocket Connection drops Exponential reconnect (1→2→4→8→30s)

What's Included

  • Implementation of device display with color statuses and clustering.
  • WebSocket subscription with automatic reconnect and diff updates.
  • Device detail screen showing latest data and history.
  • Search and filtering with sorting by status, distance, name.
  • Documentation for integration with your API.
  • Source code delivery and repository access.
  • One month of post-delivery consultation.

Timelines and Cost

Device map with clustering, color statuses, detail screen, and filterable list given a ready API: 4 hours to 2 business days depending on marker customization and UI requirements. Typical project cost: $3,000–$12,000 depending on complexity. For example, a minimal viable product with basic clustering and two statuses costs $3,000; a full-featured solution with custom UI and advanced filtering costs $12,000. Get a consultation — we will assess your project in one day.

We guarantee transfer of all code rights and post-launch support. Our engineers hold Apple and Google certifications, confirming competence in mobile app development. Order your IoT device map today — get an engineer consultation. Contact us to discuss the details.

Supported Platforms and Requirements

  • Android 8+ (API 26), iOS 13+, Flutter 3.16+
  • Minimum device RAM: 2 GB, storage: 100 MB free
  • Internet connection required (4G+ recommended)
  • Google Maps API key (Android/Flutter) or Apple Maps entitlement (iOS)

Marker Clustering Implementation

To implement marker clustering for IoT devices, we use specialized libraries: for Flutter the google_maps_cluster_manager package, for Android android-maps-utils with DefaultClusterRenderer, for iOS GMUClusterManager from Maps Utils SDK. The custom renderer shows the status of the 'worst' device in the cluster (e.g., critical -> red) for quick problem identification. This approach is mandatory when more than 100 devices are in one viewport.

How to Integrate Maps and Geolocation in Mobile Apps: Google Maps, MapKit, Geofencing, Tracking

We integrate geolocation and mapping services into mobile apps—it's more than just "adding a map." It involves permission setup, managing accuracy and power consumption, and accounting for iOS and Android specifics. Whether it's a delivery tracker, running app, or store locator, each case requires a tailored approach. Contact us for a free project assessment within 2 hours.

Permissions: One of the Most Common Sources of Bad Reviews

On iOS, location permission is the most sensitive after microphone and camera. Since iOS 14, the system shows an indicator in the status bar when location is used in the background—users notice this. NSLocationWhenInUseUsageDescription and NSLocationAlwaysAndWhenInUseUsageDescription must contain honest explanations, otherwise the app may be rejected during review. Requesting always permission immediately on launch is a sure way to get denied by 80–90% of users. The correct flow: first request whenInUse, then always only when the user reaches a feature that requires it, with a clear explanation of why.

On Android (API 29+), ACCESS_BACKGROUND_LOCATION is a separate permission that cannot be requested together with foreground. First request foreground permission, then background separately. Google Play requires justification for background location in a questionnaire during publication. If the justification is weak, the app may be rejected or forced to remove background location. Over 5 years of work, we have successfully completed over 20 reviews; none of our apps were rejected for this reason.

Accuracy and Power Consumption: How to Avoid Battery Drain

Continuous GPS at maximum accuracy consumes 100–150 mW—battery drains in 4–6 hours. For most tasks, this is excessive.

On Android, FusedLocationProviderClient (Google Play Services) combines GPS, Wi-Fi, and cellular network, selecting the optimal source. LocationRequest.Builder with priorities:

  • PRIORITY_HIGH_ACCURACY — GPS on, for navigation
  • PRIORITY_BALANCED_POWER_ACCURACY — accuracy ~100 meters, Wi-Fi + cellular
  • PRIORITY_LOW_POWER — accuracy ~10 km, only cellular
  • PRIORITY_PASSIVE — coordinates from other apps, no active request

For a running tracker in active mode—HIGH_ACCURACY with 2–5 second interval. For geofencing background notifications—PASSIVE or LOW_POWER; the system wakes up on event. GPS accuracy is well-documented.

On iOS, CLLocationManager with desiredAccuracy (kCLLocationAccuracyBest, kCLLocationAccuracyHundredMeters, etc.) and distanceFilter—minimum movement in meters before next update. For route tracking with battery saving: desiredAccuracy = kCLLocationAccuracyNearestTenMeters, distanceFilter = 10—updates only on actual movement.

Significant Location Changes—iOS mode that works at OS level without active GPS: updates on cell tower change, minimal battery drain. Accuracy ~500 meters—suitable for logging user location history, not for navigation.

How to Choose a Mapping SDK? Comparative Analysis

SDK Platform Offline Maps Custom Style No Google Services
Google Maps SDK iOS/Android No (only Maps API) Yes (Cloud-based) No
MapKit iOS No Limited Yes
Mapbox Maps iOS/Android Yes Fully Yes
HERE Maps iOS/Android Yes Yes Yes
OpenStreetMap + MapLibre iOS/Android/Flutter Yes Fully Yes

Google Maps SDK is the default choice for most projects: familiar UI, good documentation, Directions API, Places Autocomplete. Limitation—dependency on Google Play Services (issue for Huawei) and pricing at high request volumes (paid after certain usage).

Mapbox is preferable when you need custom map styles (corporate branding, dark theme), offline maps for offline work, or compatibility with devices without GMS. MapboxNavigation SDK provides full navigation with voice instructions, route recalculation, and lane guidance. Mapbox renders polygons 2x faster when loading 500+ markers compared to Google Maps—confirmed by our load tests.

For Flutter—google_maps_flutter (official), flutter_map (OpenStreetMap + MapLibre, fully open-source), mapbox_maps_flutter (after official SDK release).

Example: App with Offline Maps and Geofences for 100+ Points

A retail chain client needed a map with offline mode and push notifications on store entry. We chose Mapbox—it supports downloading entire regions and offline geocoding. Result: zero network failures, 30% battery reduction due to PASSIVE mode.

Why Does Geofencing Have Delays?

Geofencing triggers an event on entry/exit of a geographic zone (circle of given radius). In practice, delay can be 1–3 minutes—the cost of energy efficiency.

On AndroidGeofencingClient from Google Location Services. Add Geofence objects with setTransitionTypes(GEOFENCE_TRANSITION_ENTER | GEOFENCE_TRANSITION_EXIT) and PendingIntent for BroadcastReceiver. Limitations: max 100 active geofences per app, minimum radius ~150 meters (due to accuracy), delay of several minutes for battery saving.

On iOSCLCircularRegion + CLLocationManager.startMonitoring(for:). Limit: 20 regions per app. The OS decides when to check—developer cannot control delay. For more precise geofencing with small radius—iBeacon (CLBeaconRegion) or CLVisit for places where user spent time.

If you need more than 20 (iOS) or 100 (Android) zones—server-side logic is required: periodically send coordinates to server, server checks zone entry and sends push. Less time-accurate but scales to thousands of zones. Geozone working principles are well-documented.

Route Tracking and Background Geolocation

Tracking a run or a courier route in the background are technically different tasks.

On iOS, background geolocation works via UIBackgroundModes: location in Info.plist. Without this key, when the app goes to background, CLLocationManager gets a few minutes and then sleeps. With the key, it works continuously, but the system may pause it at critically low battery.

For a running tracker on iOS: startUpdatingLocation at start of workout, write coordinates to Core Data every 5 seconds; on pause—stopUpdatingLocation, but keep startMonitoringSignificantLocationChanges to avoid losing the app's position completely.

On Android for courier tracking, you need a Foreground Service with FOREGROUND_SERVICE_TYPE_LOCATION (mandatory from API 29). Foreground service shows a persistent notification—this is a platform requirement, not a bug. Without it, Android Doze will kill location updates. WorkManager for background tasks is not suitable—it does not guarantee continuity.

Algorithmic part of route tracking: raw GPS coordinates are noisy. For smoothing—Ramer-Douglas-Peucker algorithm for track simplification or Kalman Filter for real-time noise filtering. Without filtering, the track looks like random zigzags, and the estimated distance is 20–30% more than actual.

How We Implement Maps and Geolocation: Step-by-Step Process

  1. Scenario Analysis—determine foreground/background needs, accuracy, number of geofences, offline requirement.
  2. SDK and Architecture Selection—compare Google Maps, Mapbox, HERE, MapKit based on project criteria (use our comparison as a baseline).
  3. Integration and Permission Setup—configure Info.plist / AndroidManifest.xml, test review checks (App Store Review Guidelines Sections 4.2/5.1, Google Play policy).
  4. Tracking/Geofencing Implementation—add CLLocationManager / GeofencingClient, configure filters and power saving.
  5. Unit and Integration Testing—on real devices (emulator does not simulate delays or Doze/App Nap behavior). Test at least 50 scenarios.
  6. Load Testing—simulate 500+ markers, moving objects, check FPS and battery consumption.
  7. Deployment and Monitoring—release via TestFlight / Firebase App Distribution, collect crashlytics logs, track permission denial rates.

Timeline and Deliverables

Stage Timeline Deliverables
Basic map integration with markers and search 1–2 weeks Source code (Swift/Kotlin/Dart), API documentation, build instructions
Geofencing with push notifications 2–3 weeks Geofence code, FCM/APNs setup, test zones, delay report
Full route tracking (background, smoothing, server sync) 4–6 weeks Code with Kalman filter, server part (optional), battery monitoring

What you get in any case:

  • Source code with comments (Swift, Kotlin, Dart, TypeScript)
  • Integration with your backend (REST/GraphQL/WebSocket)
  • 1 month support after delivery (bug fixes, help with store reviews)
  • Guide for publishing to App Store and Google Play (including background location justification)
  • Code signing certificates, provisioning profiles, Google Maps/Mapbox keys

Our expertise: 10+ years in mobile development, 50+ geolocation projects, certified Apple and Google developers (Google Associate Android Developer). Every app undergoes triple code review and load testing.

Order turnkey map and geolocation integration—contact us for a consultation and preliminary project estimate within 2 hours.