The application is an implementation of an SSH client and a connectivity manager infused together. It included three main activity classes, where the function and the logic of the application take place, and five layouts files responsible to create the UI of the application. Following in Figure 9, is a representation of the Lifecycle of the activity and the transition from one activity to another within the application.
23
Figure 9. Lifecycle of the Application
When the user launches the application for the first time, the onStart() process takes place and the systems starts the application. While the OS loads the components of the application, the
24
user is introduced to a splash screen, which serves as a time window for the set-up of the application. This is the SplashScreen.java class and is depicted in Figure 10.
Figure 10. SplashScreen.java - Launcher Display of the Application
After the loading of the application is finished, ChooseConnection.java activity starts, with its respective layout being displayed on the screen for the user to interact with. It contains four buttons, and one TextView field, as shown in Figure 16. However, as depicted in Figure 11, initially they are only three of the buttons displayed on the screen. The fourth button, which is labeled “NEXT”, will be displayed only after the user is connected to a network either vie Bluetooth connectivity or via Wi-Fi.
25
Figure 11. ChooseConnection.java activity's UI
Each button is labeled with its corresponding functionality and the TextView field suggests the user to click one of the three grey buttons, in order to choose connectivity type. When the user clicks on the “Bluetooth” button, the device’s Wireless setting screen is displayed as shown in Figure 12. While on the Wireless settings screen, the user can turn on or off the
26
Bluetooth connectivity of the device and also enable Bluetooth Tethering capabilities on the device.
Figure 12. Wireless setting screen
If Bluetooth connectivity is enabled, the user is capable to see the paired devices that has previously paired the phone with and can choose to scan for new devices available in the area. By clicking on one of the devices listed in this view, the user initiates a connection with that device, over Bluetooth. Figure 13 illustrates the device’s Bluetooth functionality.
27
Figure 13. Bluetooth Settings screen - Paired Devices (left) Bluetooth Tethering (right)
In similar fashion, the user can access the Wi-Fi connectivity settings, by clicking on the “Wi- Fi” button. Once, the “Wi-Fi” button is clicked, the device’s Wi-Fi settings are displayed on the screen. A list of available networks is displayed and the user can choose to which network he wishes to connect to. Once he clicks on a network item from the list, if the network is not secured, the device will connect to that network without the need of any credentials. However, if the user chooses to connect to a network, which is secured by a password a dialog window will prompt the user to type a password for authentication. After the authentication is finished the device will be connected to the corresponding network. Figure 15 displays the User Interface of the device’s Wi-Fi setting.
28
Figure 15. Wi-Fi Settings screen
Finally, once the device is connected to some network, the user is returned to the ChooseConnection.java activity, where now the “NEXT” button is available for the user to click and proceed to the next activity of the application. Figure 16 shows the ChooseConnection.java activity, after the device is connected to a network.
29
Figure 16. ChooseConnection.java - Display of connected device.
In this instance of the ChooseConnection.java activity, the user is allowed to click the “NEXT” button and trigger the onCreate() and onStart() methods of the LoginActivity.java activity. Moreover, the UI of the application changes with a new layout being applied on the screen and the corresponding LoginActivity.java activity is instantiated. In this activity, a connection to the internet is already established by the ChooseConnection.java activity and now the user is able to communicate with the remote embedded system, over an SSH connection.
30
As mentioned earlier in the subsection 3.2 of Chapter 3, the SSH connection follow a client- server model. In our case our application is the client and thus the side which needs to provide some credentials for the authentication process from the server. For this reason, the UI of the LoginActivity.java includes four EditText Views, where they are going to be used for the user to input the required credentials, as well as a button which will be clicked to initiate the connection.
31
In Figure 17 we can see the UI of the LoginActivity.java screen. It consists of four EditTexts which are labeled according to the value that they pass in the java code, and a button labled “CONNECT” which the user clicks to start a connection. The first EditText, labeled as ”Host/IP Address” requires the user to input the hostname of the server he wants to access, or the IP Address of that server. The “Username” and “Password” EditTexts require the username of the client and the password with which he is trying to access the server. These two values, will be used on the server side for authentication and if they are correct they will grant access to the client. Finally, the “Port” EditText passes an integer value in the java source code of the application and is the number value of the server’s port which is listening for connection requests.
After all credentials are filled in, the user can click on the “CONNECT” button and trigger the connection process. However, if one or more of the EditText fields were left empty by the user or the input was incorrect, the connection will be declined by the server and the application will print out a Toast Message to inform the user about the error that occurred. Table 1, in subsection 4.3.1 shows a snippet of the source code which is responsible to handle this error.
Therefore if the credentials are incorrect or empty, the authentication procedure on the server side will fail and thus the connection will return false. That is, the application will not be able to proceed further and the user will be informed that an error occurred while trying to connect to the server. However, in case the credentials are correct and the authentication procedure is successful, a connection will be established between the application and the remote embedded system, this will grand the user with the ability to proceed on controlling the embedded system and run commands from within the application.
To do so, the application has to check if a connection is currently open and listening for data streams. If so, the application will chance its UI to another layout which will populate the screen with a few new buttons in a ScrollView. In Figure 18, we can see what this new layout will look like and what are the buttons that it includes.
32
Figure 138. Activity_main.xml - This is the layout which includes the command buttons
In the activity_main.xml layout we have included numerous buttons, which are responsive to the user’s click. Each button is responsible to send a command to be executed on the server, when the user clicks on it. We have labeled each button with the corresponding command that is being send to the server in order to smoothen the user experience. Moreover, we have preferred to execute commands with button clicks instead of user’s input type approach since it adds more simplicity and usability to our application.
The UI of the activity_main.xml layout is encapsulated inside a ScrollView, which allows the user to scroll on the screen and choose the command he wants to execute. It is easily noticed from Figure 18, that there are two slightly different buttons included inside the layout. The one is the “DISCONNECT” button and the other one is the “SUDO SUPERVISORCTL” button. In the case of the “DISCONNECT” button, when the user clicks on it, the application disconnects the channel which runs the commands as well as the session which is currently connected. That is, the application will terminate the SSH communication between the device and the embedded system and it will return the user to the activity_login.xml, which is the layout responsible for credential inputs. For the “SUDO SUPERVISORCTL” button, if the user clicks on this button a new process will be triggered. This button is responsible to start the supervisor set of commands, which is a different set of commands that the user has access to right now. This will result in a new layout being instantiated and displayed on the screen.
33
This new layout is of similar fashion with the activity_main.xml layout. That is, is a layout encapsulated inside a ScrollView, which contains buttons responsible to execute supervisor commands on the server end. The design of the new layout is depicted in Figure 19.
Figure 149. Activity_super.xml - Supervisor commands layout
This layout contains only the buttons that run supervisor commands, and there is not functionality implemented that affects the application directly. If the user wishes to exit the supervisor commands and go back to the main command thread, he has to click on the button “EXIT”, which will exit the supervisor command set and bring back on screen the activity_main.xml layout.
The whole application is terminated once the user totally exits the application. This can happen as a response to the user’s click on on-screen home button or the user exiting and then killing the app. Nevertheless, if the user remains inactive during a session for longer time interval than 83 minutes, the session automatically will disconnect which will result to the channel termination and the application returning on the credential input screen activity_login.xml layout. If the user wishes to reconnect to the server again, he should instantiate a new connection following the same procedure, with passing credentials and authenticating, from the beginning.
34