iOS state doesn't persist across reboots

[tananaev]

I received quite a few reports that enabled state doesn't persist across phone reboots. It used to work on earlier version of the plugin. Any ideas why it could be happening?

Example config:

{
  "geolocation": {
    "distanceFilter": 75.0,
    "desiredAccuracy": 10,
    "disableElasticity": true,
    "pausesLocationUpdatesAutomatically": true,
    "showsBackgroundLocationIndicator": false
  },
  "app": {
    "stopOnTerminate": false,
    "preventSuspend": false
  },
  "http": {
    "autoSync": false,
    "url": "http://demo.traccar.org:5055/",
    "params": {
      "device_id": "68003259"
    }
  },
  "activity": {
    "disableStopDetection": false
  },
  "persistence": {
    "locationTemplate": "{\"timestamp\": \"<%= timestamp %>\",\"coords\": {\"latitude\": <%= latitude %>,\"longitude\": <%= longitude %>,\"accuracy\": <%= accuracy %>,\"speed\": <%= speed %>,\"heading\": <%= heading %>,\"altitude\": <%= altitude %>},\"is_moving\": <%= is_moving %>,\"odometer\": <%= odometer %>,\"event\": \"<%= event %>\",\"battery\": {\"level\": <%= battery.level %>,\"is_charging\": <%= battery.is_charging %>},\"activity\": {\"type\": \"<%= activity.type %>\"},\"extras\": {},\"_\": \"&id=68003259&lat=<%= latitude %>&lon=<%= longitude %>&timestamp=<%= timestamp %>&\"}",
    "maxRecordsToPersist": -1
  },
  "logger": {
    "logLevel": 5,
    "logMaxDays": 1
  },
  "isMoving": true
}

[christocracy]

I just tried a device reboot. I see my state persisted.

And I use reset: false so that the Config provided to .ready(config) is ignored so that my settings screen drives the Config, rather than being reset/reapplied each time .ready(config) is run.

My demo app starts up in last known State.enabled. All my Settings are same as before device reboot.

[tananaev]

Interesting. I guess I should use reset false as well. What does it actually reset when true? Does it reset the enabled plugin state? Would setting false cause any side effects, like some values are ignored?

[WD-J]

I thought I'd mention a small error I experienced, which made the think that the state was not persisted.

When calling await bg.BackgroundGeolocation.state prior to calling BackgroundGeolocation.ready, state.geolocation.locationAuthorizationRequest reports null, while state.locationAuthorizationRequest reports the expected value. Perhaps this was an oversight when migrating to the compound config? I don't know if this applies to any other parameters.

I ran into this because I was unnecessarily passing the state config to BackgroundGeolocation.ready when setting locationAuthorizationRequest conditionally:

Config(
  geolocation: GeoConfig(
    locationAuthorizationRequest: state.isFirstBoot
        ? 'WhenInUse'
        : state.geolocation.locationAuthorizationRequest,
  ),
),

That being said, reset: false works, and I now do locationAuthorizationRequest: state.isFirstBoot ? 'WhenInUse' : null.

[christocracy]

Interesting. I guess I should use reset false as well. What does it actually reset when true? Does it reset the enabled plugin state? Would setting false cause any side effects, like some values are ignored?

reset: false is typically not necessary (reset: true is the default). I designed it specifically for my demo apps, as I said, so I can drive the config from a complex Settings screen and not have my config reset back to the Config provided to .ready(config) each time the app launches. For example, I might do some testing with useSignificantChangesOnly: true -- I don't want that reset back to default each time I launch the app.

If you're dynamically changing the Config in your app using .setConfig, and you want those current values to "stick", rather than having .ready(config) applied each time, then sure, go ahead and use reset: false. Just be aware, during development, that tweaking your .ready(config) is going to be ignored unless you uninstall / re-install the app.

Does it reset the enabled plugin state?

State params, such as enabled, never get reset. the only thing that changes State.enabled is calling .start() or .stop()

@WD-J

thought I'd mention a small error I experienced, which made the think that the state was not persisted.

iOS or Android?

[WD-J]

iOS or Android?

Android

Just be aware, during development, that tweaking your .ready(config) is going to be ignored unless you uninstall / re-install the app.

That is critical to be aware of - thank you for mentioning that. Perhaps that should be mentioned in the parameter doc comment as well.

[christocracy]

It is documented.

Why do you think you need reset: false? 99% of use-cases don't need it.

[WD-J]

It is documented.

So it is. I was referring to line 156-157 in config.dart

  /// Determines whether to reset the existing Config to defaults before appying new config (default true)
  bool? reset;

Why do you think you need reset: false?

I don't think I do necessarily, but it's convenient. As you said:

If you're dynamically changing the Config in your app using .setConfig, and you want those current values to "stick", rather than having .ready(config) applied each time, then sure, go ahead and use reset: false.