React-native-background-geolocation: Utilizing autoSync mechanism without HTTP Requests (Firestore)

[lashae]

We have been using React Native Background Geolocation plugin for more than 10 months and we are a happy paid/licensed customer since the beginning of March 2018. Definitely, it is a super stable and beneficial layer for our product.

We are migrating our API-dependent features to Firestore as mush as possible and feasible. Firestore is a flexible and scalable database for mobile, web, and server development from Firebase and Google Cloud Platform. What makes it unique is that; it has a local database "copy" where you read/write from and it seamlessly synchronizes local edits to infinitely scalable remote database when network is available.

On the react-native-background-geolocation plugin side; we configured the plugin to collect n number of locations and autoSync/batchSync them to our endpoint when autoSyncThreshold is reached.

Now, what we would love to do is:

Configure the plugin to continue collecting n number of locations and when autoSyncThreshold is reached write/insert them to Firestore by using Firestore SDK instead of posting them to an API endpoint. Which will significantly reduce our technical debt since currently we need to maintain an independent GCP cloud function.

Currently it seems impossible to autoSync/batchSync since autoSync requires us to enable HTTP feature by configuring an #url as the documentation states.

If the above mentioned points miss some sort of existing functionality which can be used to cover our requirement please kindly point us to the correct configuration and implementation.

If we are correct that, our requirement is currently undoable via the current implementation of the plugin please kindly take this as a feature request such that we can plug-in to the "autoSync" event and implement our logic instead of HTTP post. If autoSync event callback is not implemented, plugin will continue to sync collected locations via HTTP, however if callback is implemented it will override the default behaviour. What do you think of this?

Our Current Environment

• Plugin version: git+ssh://[email protected]/transistorsoft/react-native-background-geolocation-android.git#2.12.0-beta.10
• Platform: Android
• OS version: 7.1.1
• Device manufacturer / model: emulator and GM Android One
• React Native version (react-native -v): 0.53.0
• Plugin config

{
  "odometer": 0,
  "schedulerEnabled": true,
  "enabled": true,
  "triggerActivities": "in_vehicle, on_bicycle, on_foot, running, walking",
  "stopTimeout": 5,
  "stopOnTerminate": false,
  "stationaryRadius": 25,
  "startOnBoot": true,
  "schedule": [
    "2 08:00-22:00",
    "3 08:00-22:00",
    "4 08:00-22:00",
    "5 14:50-22:00",
    "6 08:00-22:00",
    "7 08:00-22:00"
  ],
  "persist": true,
  "trackingMode": 1,
  "params": {},
  "notificationTitle": "text",
  "forceReloadOnLocationChange": false,
  "notificationPriority": -1,
  "forceReloadOnBoot": true,
  "isFirstBoot": true,
  "locationTimeout": 60,
  "extras": {
    "offset": 180,
    "user": {
      "subdomain": "text",
      "username": "text"
    }
  },
  "notificationSmallIcon": "",
  "locationUpdateInterval": 1000,
  "distanceFilter": 20,
  "forceReloadOnGeofence": false,
  "notificationText": "Text",
  "forceReloadOnMotionChange": false,
  "stopOnStationary": false,
  "stopAfterElapsedMinutes": 0,
  "forceReloadOnSchedule": false,
  "logMaxDays": 7,
  "activityRecognitionInterval": 10000,
  "deferTime": 0,
  "fastestLocationUpdateInterval": 10000,
  "elasticityMultiplier": 3,
  "headlessJobService": "com.transistorsoft.rnbackgroundgeolocation.HeadlessJobService",
  "allowIdenticalLocations": false,
  "heartbeatInterval": -1,
  "geofenceInitialTriggerEntry": true,
  "autoSyncThreshold": 20,
  "geofenceTemplate": "",
  "batchSync": true,
  "disableStopDetection": false,
  "method": "POST",
  "disableElasticity": false,
  "debug": true,
  "locationsOrderDirection": "ASC",
  "notificationLargeIcon": "",
  "desiredOdometerAccuracy": 100,
  "foregroundService": true,
  "geofenceProximityRadius": 1000,
  "autoSync": true,
  "headers": {
    "Authorization": "Bearer Token"
  },
  "maxDaysToPersist": 1,
  "httpRootProperty": "location",
  "httpTimeout": 60000,
  "desiredAccuracy": -1,
  "isMoving": false,
  "locationTemplate": "",
  "url": "apiUrl",
  "logLevel": 5,
  "maxBatchSize": -1,
  "maxRecordsToPersist": -1,
  "minimumActivityRecognitionConfidence": 75,
  "enableHeadless": true,
  "forceReloadOnHeartbeat": false,
  "notificationColor": "#3F51B5"
}

[christocracy]

Hundreds of other users use Firebase / Firestore.

Simply provide the Firestore REST API url to the plugin.

[lashae]

Dear @christocracy,

first of all, thank you for taking time for reading our pain-point and suggestion.

We already have a cloud function on operation to persist location records on Firestore which operates similar to Firestore REST API. However, that enforces us to manage token refresh procedure on mobile-client which means an additional HTTP request on every hour; since Firebase token TTLs are 1 hour at most. Moreover, HTTP requests are done at the time of request with HTTP overhead however Firestore, itself, maintains a pub-sub socket mechanism behind the scene and it does synchronization in a more power efficient way.

These points were the driving points when opening this issue. Let me express my suggestion once again:

Plugin will fire the "autoSync" event when autoSyncThreshold is reached and we may implement our logic on the autoSync event callback. If autoSync event callback is not implemented, plugin will continue to sync collected locations via HTTP, however if callback is implemented it will override the default behaviour.

Don't you think giving the opportunity to users to implement their custom sync logic and abstracting the synchronization logic will make this plugin more general-purpose?

[christocracy]

You're free to configure no #url and implement your own upload mechanism.

You'll want to implement a Headless Task for the case where your Android app is terminated.

I could possibly implement an autosync event if you'd like to fund it. In the meantime, you can execute #getCount.

[lashae]

I know that I can re-implement your autoSync mechanism by using the existing plugin infrastructure, however it is like rediscovering the continent America, isn't it and should I? I mean would you do if you were me?

If this feature request was addressing a specific requirement of which only my company will benefit, I would be more than glad to fund it therefore I appreciate your efforts and appraise this plugin in appropriate occasions. Moreover, we always keep in mind that; you may be available as a freelance workforce for our specific requirements around location-tracking problems.

However, since this feature request can be easily classified as an improvement to the things plugin deals with, it offers just a little bit more abstraction, I would be glad if you accept it in your backlog. When thinking that we are already a paid customer, do you think we can make feature requests?

Does it sound legit?

[christocracy]

Many of the features you're using were paid for by customers who came before you, particularly the Scheduler, which was funded with 30 hours @ $200 / hour.

[lashae]

Chris, I totally understand your approach. I have been in software industry for nearly 20 years and more than 5 years being a freelancer. I'm familiar with how it works.

First, in the principles perspective; do you accept any type of feature requests from your "paid/licensed" customers or you decide your backlog on your own and implement feature requests only if they are funded? I'm asking this to clarify our future business relations.

Second, in this issue context; do you agree to implement the feature with the below specs with funding (you can propose improvements on the flow/algorithm of course)?

• We will configure the plugin with:

"autoSync": true,
"batchSync": true,
"autoSyncThreshold": 20,
"distanceFilter": 20,

• Plugin will operate as before, by collecting 20 locations for every 20 meters (assume elasticityMultiplier is 1).
• We will Implement the proposed autoSync event's callback function in the headless task to whatever we would like to do for syncing which will return true when autoSync succeeds.
• When an autoSync is required on the plugin side (a. autoSyncThreshold is reached, b. User state became still after moving, c. User started to move after being still), plugin will check whether autoSync event callback is implemented;
  
  
  
  • If it is implemented it will call the callback and wait for it to resolve, after resolution if it returns true, plugin will delete the locations it had collected else it won't delete the collected locations.*
  
  
  • If it is not implemented it will check url configuration and run HTTP syncing incase url is set.
  
  

*: If the autoSync callback didn't return true, is it possible for the plugin to retry continuously, with delays like 5 minutes (or any other idea?), just in the builtin HTTP syncing feature?

And lastly, if you agree to implement the above feature; could you please share the amount of funding you ask for so that I can ask my company as well?

[TitanKing]

Just to let you know @lashae, I have recently implemented this successfully with Firebase like you want to do without the need for an autoSync callback.

It works very well and you have all the power you need. Here are some tips;

• Create a class that you can call both from the frontend and that you can use as a headless task (for when the app is closed)
• Now everytime a location change or heartbeat (or whatever you prefer) happens to count the location logs + other conditions.
• When conditions allow writing to firebase and clear database with the available react-native-background-geolocation methods.

Works well and is very reliable.

[christocracy]

Thanks for you help, as always @TitanKing

[lashae]

Thanks @TitanKing we will give it a try.