| Age | Commit message (Collapse) | Author |
|---|
|
It is annoying to type the server domain name on every app start. This
should be way more ergonomic.
As a minimal first step reading from the database is implemented and
tested with an externally injected database.
|
|
This lets the user select the fully qualified domain name (FQDN) of the
MQTT broker.
The FQDN is not yet preserved after a manual disconnect.
|
|
This makes use of the state machine in the UI and implements all states
and transitions planned so far.
|
|
This allows going back to the connection page and to choose a different
server. Furthermore it might be useful to force a new connection attempt
while auto-reconnect might be in a delay state.
|
|
The user should provide the fully qualified domain name (FQDN) of the
MQTT broker manually and then press connect to actually connect
including automated re-connects.
As a first step the initial connect is bound to the manual button in the
bottom bar. To reduce the scope the disconnect button is labeled
"(disabled)" to make clear this is not expected to work.
|
|
This does not yet work but the correct text based on the page is
displayed.
This is based on a state machine based implementation suitable to
implement the state handling cleanly.
|
|
This prepares starting connection attempts on manual action only.
|
|
This prepares manually starting the connection after server name
insertion.
|
|
This is a second page to offer a form to set the Sia server name.
|
|
There are now three instead of two status states:
- "Connected" / MQTT connected, Sia server connected
- "Connection issue" / MQTT connected, Sia server disconnected
- "Disconnected" / all other cases (Sia server connection unknown)
|
|
This allows to use the app after a temporary disconnect between app and
MQTT broker.
|
|
The user otherwise cannot trust the state of the contacts because the
app could just be disconnected from the broker.
|
|
This is already the minimal viable product (MVP) for this app.
|
|
|
|
This map should be empty in the future and updated based on the incoming
MQTT messages.
A list was not the correct data structure for that since it requires to
iterate over the whole list to find the entry with a certain address.
But this is required to update the state of an already known contact.
|
|
|
|
This is now done with the refactored code organization and a strict UI /
data split.
|
|
The UI should not store the application logic state.
|
|
This follows recommendations [1] from the flutter documentation.
[1]: https://docs.flutter.dev/app-architecture/concepts
|
