christocracy
commented
4 years ago BackgroundGeolocation.ready({
reset: false,
.
.
.
});Closed tobiaswaltl closed 4 years ago
christocracy
commented
4 years ago BackgroundGeolocation.ready({
reset: false,
.
.
.
});
tobiaswaltl
commented
4 years ago Thank you for the quick response. However, reset: false doesn't seem to have any effect: Values set via setConfig are still lost and random values (like url in the example above) are still different for every app launch.
When I log the state (window.BackgroundGeolocation.getState().then(state => console.log(state))) there is no property reset included. When I access it directly (window.BackgroundGeolocation.getState().then(state => console.log(state.reset))) it is undefined.
christocracy
commented
4 years ago reset is not a State parameter.
It is an option provided to the ready method.
tobiaswaltl
commented
4 years ago Ok, I've provided it to the ready method but it's the same behavior. I just thought I'd see reset in state like the other config keys.
christocracy
commented
4 years ago The SampleApp is configured to operate as you desire with reset: false in order for the Settings screen to control the configuration (which uses setConfig at runtime).
christocracy
commented
4 years ago You’re doing something wrong. Post more of your code used with the plugin.
tobiaswaltl
commented
4 years ago I've just tried out the sample app and yes, there it works so probably I've just overlooked a little detail.
On app start I call ready() with this config:
const state = await BackgroundGeolocation.ready({
reset: false, // Do not reset the config but re-apply the persisted one
// Geolocation Config
desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH,
distanceFilter: 10, // in meters
showsBackgroundLocationIndicator: true, // iOS only
// Application config
debug: true, // <-- enable this hear debug sounds.
logLevel: BackgroundGeolocation.LOG_LEVEL_VERBOSE,
stopOnTerminate: false, // Allow the background-service to continue tracking when app terminated.
startOnBoot: true, // Auto start tracking when device is powered-up.
// HTTP / SQLite config
url: `${Math.random()}`, // should now be the same for every app start
httpRootProperty: '.',
locationTemplate: '{"latitude":<%= latitude %>,"longitude":<%= longitude %>,"timeOfRecord":"<%= timestamp %>"}',
extras: {
deviceId: `"${device.uuid}"`,
random: Math.random(), // should also be the same for every app start
},
});Later, I can update the config:
await BackgroundGeolocation.setConfig({ url: 'myServer.com' });When logging the state afterwards I can see the config was updated successfully.
Then I terminate the app, start it again and log the state after the BackgroundGeolocation.ready call from above. Now the url is a random number again (instead of 'myServer.com').
christocracy
commented
4 years ago Show me native logs of your app booting. You are likely calling #ready twice.
tobiaswaltl
commented
4 years ago I've played around with it for a while now. It seems that everything works fine as long as the plugin is not currently started (via BackgroundGeolocation.start() when I terminate the app.
These scenarios work as expected:
ready -> setConfig -> terminate appready -> start -> stop -> setConfig -> terminate appready -> start -> setConfig -> stop -> terminate appBut this scenario doesn't:
ready -> start -> setConfig -> terminate app (without stopping the plugin)
While this scenario keeps configs that are not configured in ready (but only in setConfig afterwards), it resets the configs that were already provided to ready (like url in the example above).
christocracy
commented
4 years ago Show me native logs of your app booting
tobiaswaltl
commented
4 years ago christocracy
commented
4 years ago And filter your logs.
$ adb logcat *:S TSLocationManager:VSorry, the newlines must have got lost somehow. Now formatted and filtered:
christocracy
commented
4 years ago I see nothing unusual in your logs.
tobiaswaltl
commented
4 years ago Is it normal that $ ready appears twice?
christocracy
commented
4 years ago Is it normal that $ ready appears twice?
$ ready is printed when BackgroundGeolocation.ready() is called.BackgroundGeolocation.ready() is called each time your app is launched.Yes, it's normal.
christocracy
commented
4 years ago When the plugin changes its config, you'll see lines like this, telling you exactly which options were changed (ie "dirty"):
09-04 19:54:22.607 8748 8893 D TSLocationManager: [c.t.l.adapter.TSConfig d] ℹ️ Persist config, dirty: [extras, headers, params]Well, now it works. Probably I had messed up something else. A very big thank you for your help!
christocracy
commented
4 years ago Get in the habit of constantly monitoring $ adb logcat. You can see your javascript console.log message too by adding the filter chromium:V. If using Capacitor: Capacitor/Console:V.
As you've noticed, the plugin is very verbose with logging and is constantly telling you everything it's doing.
eg:
$ adb logcat *:S TSLocationManager:V chromium:V
Your Environment
cordova -v): 9.0.0cordova platform ls): 5.1.1 (iOS) / 8.1.0 (Android)#ready:Expected Behavior
The docs say: "The supplied Config will be applied only at first install of your app — for every launch thereafter, the plugin will automatically load its last-known configuration from persistent storage. The plugin always remembers the configuration you apply to it." This is what I expected.
Actual Behavior
The config is re-applied for every launch. Configs from previous launches as well as config provided later via
BackgroundGeolocation.setConfig()are overridden.Steps to Reproduce
ready()like above and log the resulting stateContext
I was relying on the plugin to restore the previously applied configs. Maybe I am just misinterpreting the docs?