| Age | Commit message (Collapse) | Author |
|---|
|
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 manually starting the connection after server name
insertion.
|
|
This removes the need to write a SafeArea on each use of
ConnectionStatus and replaces it by exactly one occurrence.
|
|
This is a second page to offer a form to set the Sia server name.
|
|
This makes sure there is only one class instance of MaterialApp.
|
|
The old name class UI was not adding much information and is not well
suited to be differentiated to upcoming other *Page classes.
|
|
This simplifies the main function and adheres more to Flutter
conventions.
|
|
On Android the bottom bar with the connection state used to be hidden by
the three Android navigation buttons.
|
|
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)
|
|
The user otherwise cannot trust the state of the contacts because the
app could just be disconnected from the broker.
|
|
That balances the scopes of UI and ContactList better and allows to add
more Widgets on the UI level.
|
|
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.
|
|
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
|
