commit 711eeeb5402ff5f861a5b6c7f2bc17a12eceeb70
author Eitan Goldberger <eitang@google.com> Fri May 31 23:35:36 2024
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Fri May 31 23:35:36 2024
tree cbb8446765d587ce9b75fbd5f2d5e71f39ca6be3
parent b244480e168c8bedd0c4a72af8fe2c222bc16f2b

[Read aloud] Refactor to separate server-side and app-side voice state.

We were keeping track of the responses from the VoicePackManager in the
same object as we were keeping track of our own application state. This
change decouples the client-side state and the responses that we receive
from the backend.

This introduces `voicePackInstallStatusServerResponses`, which is
essentially a cache of the server side statuses, and
`voiceStatusLocalState`, the state that our UI application needs.

For example, if we send a request to install a language, we mark it as
installing on the client side, if that's not the state yet on the server
side. Or, if the server says that it's INSTALLed but we don't see it yet
in getVoices(), we can mark it as not having been downloaded yet in the
client logic, and not have to overwrite the server response by
differentiating between INSTALLED and DOWNLOADED states. Or, if
installation takes a long time, we can mark it as failed in the client
side state, and keep the state representing the server as still
downloading.

I have more examples of where this was slowing down my development
where I needed to modify and react to application state, but needed to
be careful about overwriting the server responses for other parts of the
application that were using it. So I figured this was a good time to make the change.

Change-Id: I2ec4c8d9dd19ff2f43cf0f40b73b5a81a1e93001
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5584467
Commit-Queue: Eitan Goldberger <eitang@google.com>
Reviewed-by: Kristi Saney <kristislee@google.com>
Cr-Commit-Position: refs/heads/main@{#1308968}