## 6 Implementation
### The HealthTracker Android Application  
The Android app is responsible for interfacing with both the monitoring devices to collect the data they generate and with the Cloud Computing Platform to store them. It has been implemented by exploiting _Android Studio_[28], which is the Integrated Development Environment (IDE) for native Android app development. The mobile app code was written using the _Koltin_ programming language. To better illustrate how it works, we refer to its user interface, which is shown in Figure 8, where we highlight its various parts by enclosing each one of them into a dashed-line rectangle and denoting them with a progressive number. The main functionalities provided by the app are authentication of the user within the HealthTracker system, activation and de-activation of health data acquisition from the monitoring devices, and the storage of these data on the Cloud Computing Platform. All functionalities are accessible through the various parts of the user interface. In particular, by looking at the Area (1) of the interface, we see the following icons (each corresponding to a specific function):  
* **Account:** shows user information following authentication. User authentication is performed by submitting the corresponding credentials (user email address and password), which are validated by means of the _Firebase Authenticator_[29] running on the Cloud Computing Platform. Before the initial authentication phase, the user can perform account registration, email confirmation, or password reset. After the login step has been completed. Session persistence is managed by means of the _Firebase Autth Android SDK_. In the current implementation, we have adopted _Single Factor Authentication_, whereby a user authenticates by just providing a username and a password. However, switching to _Multi-Factor Authentication (MFA)_, whereby additional identity verification information (e.g., a code sent via SMS) needs to be provided to the system to authenticate, is straightforward thanks to the already available MFA mechanisms provided by _Firebase Authenticator_. * **Devices:** displays buttons that enable users to initiate independent data recording for each device and upload the sensor readings afterward (see Figure 8). Notably, in Area (3) of the figure, two prominent \"Start\" and \"Stop\" buttons are present to control data recording on both devices simultaneously. Meanwhile, smaller \"Start\" and \"Stop\" buttons are utilized when the user intends to record data from a single device. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline  & **HealthTracker** & **Apple** & **Garmin** & **Google** & **Samsung** \\ \hline Cough frequency and intensity & ✓ & & & & \\ \hline Fall Detection & ✓ & ✓ & ✓ & ✓ & \\ \hline Heart rate monitoring & ✓ & ✓ & ✓ & ✓ & ✓ \\ \hline Nighttime breathing (e.g., snoring) & ✓ & & & & ✓ \\ \hline Temperature & ✓ & ✓ & ✓ & ✓ & ✓ \\ \hline Sweating & ✓ & & ✓ & & \\ \hline Tremors and hyperkinetic movements & ✓ & & & & \\ \hline \hline \end{tabular}
\end{table} 
Table 2: _Cont._As anticipated in Section 5, the Android app exploits the GATT protocol to communicate with both monitoring devices. This device-to-smartphone communication is implemented as follows: when the user presses the \"_Start_\" button in the _Devices Fragment_, the application checks if Bluetooth and GPS are enabled (it is necessary to perform a BLE Scan) or prompts the user to enable them and after all necessary permissions are granted, a _Service_ called _BLEService_ is responsible for starting each thread to enable the communication with the requested devices. Starting these threads from a _Service_ lets us record the data even when the application is in the background. The _BLESTConnectionThread_ and the _BLEViatomConnectionThread_ classes have been implemented to manage the communication, respectively, with the HDC device and with the Viatom Checkme O2 device. Despite being two separate threads, they work in similar ways.