Fix storage API and databroker interaction on start up 04/30304/2
authorScott Murray <scott.murray@konsulko.com>
Tue, 24 Sep 2024 20:10:43 +0000 (16:10 -0400)
committerScott Murray <scott.murray@konsulko.com>
Tue, 24 Sep 2024 20:20:40 +0000 (16:20 -0400)
commitbdc33c218e3e62e5a3121d3ab0de6e26ef7ad3eb
tree29c01094aafeb9aaab6d3aef04354502fefb9cd9
parent7ea2d37528da61ff40a50da5843397d51fc0e789
Fix storage API and databroker interaction on start up

Changes:
- The persisted values read in by the forced early init of the
  storage API were getting overridden by the defaults coming from
  the databroker in the case of preferences that map directly to
  VSS signals. Refactor the preference updating code to move the
  VSS updating calls to reusable functions in ValClient, and then
  use those to update the VSS signal values right after connecting
  to the databroker.
- Remove the recursive initialization call from UnitsNotifier's
  loadSettingsUnits function, as in my testing it broke start up,
  and the recursion seems incorrect.  There are definitely issues
  with racing with the storage API daemon, and the homescreen
  completely hangs if it is not running.  The fix for that is to
  switch to a more Flutter typical asynchronous initialization of
  the storage API connection, and future rework will be in that
  direction.
- Change various prints in the storage API code to debugPrint to
  start trying to clean up complaints from "flutter analyze".

Bug-AGL: SPEC-5250

Change-Id: I6dc9a45569453254d1565038048305f94d121db6
Signed-off-by: Scott Murray <scott.murray@konsulko.com>
lib/data/data_providers/units_notifier.dart
lib/data/data_providers/users_notifier.dart
lib/data/data_providers/val_client.dart
pubspec.lock