cesarbr / knot-setup-android Goto Github PK

Since the current texts were not considered descriptive enough, it's necessary to update them in such a way that is clear to the user what he/she is doing.

Since the app can only be uploaded to the play store without logs, logging should only be enabled while in debug mode.

The add-gateway button has no use in the current application since the writing of configurations to the gateways is not supported

When an item is discovered through mDNS, in the android api, if you wish to get the ip and the port of said item, you have to pass through a "resolve" stage. Since this is a resource demanding task the android api only allows users to resolve one item at a time, and so, when trying to resolve a second item whilst the first has not yet been resolved, causes the resolution process to fail.

With the new UI, it was necessary to use fragments to be held by each tab in the tab layout. As such, it's necessary to investigate how these fragments interact with each other and might influence the app flow.

The gateway list keeps displaying found items when leaving context even though they are unavailable

If the wifi is working but has no connection to the internet, android forces the apps to use mobile data. This behavior is not desirable because the user should be able to access the gateway, even if not connected to the internet.

With the new UI, the app needs access to Bluetooth and user location at the first view.

If there is more than one gateway at the same network and both the gateways have been discovered, the requests are always sent to the last discovered gateway.

When writing to the Thing several times using the knot-setup-app, after a while, the Thing stops advertising.

The app doesn't request the user to give access to the location which led to errors in more recent api's.

Avahi's Multicast DNS has shown unstable behavior when the network is congested, leading to undesirable behavior on the app.
It seems like a good idea to understand the context that leads to this situation as well as possible solutions.

To use mDNS the app needs to be connected to the same WI-FI as the gateway, so it should only be possible to use the app if the user is connected to a WI-FI.

Context
The gateway is configured and the user wants to register a device.
Expected Behavior
When device is plugged on the power supply a card should be shown. And if the device is removed from the power supply the card should be removed after a while.
Current Behavior
The card is not removed.
Possible Solution
For each device that is scanned, there is a timeout associated to it. If on the next scan the device was not discovered the timeout should remove the card from the card list
Steps to Reproduce

1. Configure the gateway
2. Connect to the gateway
3. Plug a device on the power supply
4. The user should see the device on the unregistered tab
5. If you unplug and plug the device again the user should see the same device on the card list but with a different MAC address

If the Openthread settings on the gateway change the Things uses the old settings until next login.

The ability to easily transform an Android device into a KNoT Thing is a very desirable feature to the KNoT platform. Taking this into consideration, it's necessary to discover what are the requisites and architectural components to make a good android API.

Prepare the app to be published at the play store. The preparations include: remove logs, add resources, add screenshots of the views, add an icon for the application and add a resource graphic.

As a user I would like to receive feedback from the app when some feature has failed to deliver or is taking too long to execute. e.g I make a get request and it either fails to find the gateway or takes too long to receive a response.

With the new UI, the app does not start scanning after location permission was given.

If a user has already prompted an email and the app logouts, the app doesn't fill the email field automatically.

As a user, I'd like to be able to log out from the app so the credentials for a gateway are deleted from this device

The application sends it's requests to a port whose value is hardcoded (80) and since we are using mDNS to transmit the port number, we should change the hardcoded value to a variable one.

Openthread configurations are being sent via mDNS as a txt field and since this was considered a security risk, we opted to change it by an https request.

The app is not giving any visual feedback to the user that it successfully wrote the Wi-Fi credentials to the gateway. This may lead to some confusion when using the app so it seems like a good idea to give the user a notification that the gateway has been successfully written to.

Write Wi-Fi credentials to the gateway by using its GATT service described by issue CESARBR/knot-gateway-netsetup#7

Make request for getting the openthread configurations via backend of the webui instead of multicastDNS

The splash activity was created to provide visual feedback for the user that the app was trying to connect to the gateway. But, since the interactions were so fast, it may lead the user to believe there is something wrong with the app.

The app currently uses rectangular buttons, it was considered a good idea to put rounded edges.

App is failing to find the gateways through mDNS due to be using a different string than the one being advertised.

If a characteristic write fails the app just stops with all the spinners spinning and giving no visual feedback whatsoever.

Read the masterkey from the gateway through the backend of the webui and write the masterkey to the thing using bluetooth.

In order to increase the overall code quality and optimize review time, a checkstyle tool is necessary. An interesting feature would be an automatic check after every push.

When leaving an activity and then returning to it, sometimes, fragments lose reference from their containing activity which causes the app to crash.

The add Gateway button and the add Thing button were deemed confusing by the app users, as such, it is necessary to replace the buttons by something more intuitive, such as tabs.

In order to keep the android code as clean and standardized as possible, a coding style tool should be used as default in the project.

Assets background are set to white, which sometimes causes the app to have superposing images.