Skip to content

Android: keep showing last loadpoint data through a transient fetch failure - #283

Open
webalexeu wants to merge 1 commit into
evcc-io:mainfrom
webalexeu:fix/widget-unreachable-cache
Open

webalexeu wants to merge 1 commit into
evcc-io:mainfrom
webalexeu:fix/widget-unreachable-cache

Conversation

@webalexeu

Copy link
Copy Markdown
Contributor

Follow-up to #255.

The loadpoint widget's fetch had no fallback: any failure, including a single transient one (Wi-Fi handoff right after screen-on, Doze, a brief server restart), replaced the card with "Server unreachable" until the next update cycle - even though a manual reload moments later would already succeed again.

  • Caches the last successfully-parsed loadpoint per widget instance, tagged by which server + loadpoint it belongs to. A background/periodic fetch failure falls back to that cache when the tag matches the current config, instead of blanking the widget.
  • Reconfiguring a widget to a different server or loadpoint needs no explicit cache-clearing step - the tag simply stops matching, so the old loadpoint's data is never shown for the new one.
  • An explicit user action (reload tap, mode button) still shows "Server unreachable" on failure rather than silently falling back - the user asked "is it working right now", so that gets a straight answer instead of stale data with no indication.
  • NoData (server reachable, nothing at that index) is untouched - that's a real answer from a reachable server, not a network problem, and showing old data there would be misleading.

…ailure

The widget's load() treated any fetch failure as Unreachable, with no
fallback - a single blip (Wi-Fi handoff after screen-on, Doze, a brief
server restart) blanked a working widget until the next update cycle,
even though a manual reload right after would already succeed again.

- Cache the last successfully-parsed loadpoint JSON per widget
  instance, tagged by which server+loadpoint it belongs to. On a
  background/periodic fetch failure, fall back to it if the tag
  matches the current config; reconfiguring to a different loadpoint
  naturally stops matching, so there's nothing to clear explicitly.
- An explicit user action (reload tap, mode change) still reports
  Unreachable on failure rather than silently showing stale data -
  that one-shot flag is consumed by the very next load regardless of
  outcome, so it never leaks into a later background refresh.
- Narrowed the recomposition trigger to (server, loadpoint, refresh
  nonce) instead of the whole Preferences blob, since load() now
  writes the cache into that same blob on success and a broader key
  would treat that write as "config changed" and reload again.
@webalexeu

Copy link
Copy Markdown
Contributor Author

@naltatis What do you think ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant