Design and functionalities¶

• Design and functionalities
  • Logo Activity
  • Search Bluetooth Device
    • Foreground Service
    • Handler Thread
  • Results
  • Goals page
  • Configs

When developing an Android Application, several parameters must be considered to not only deliver the intended functionalities without cluttering and compromising the user experience. This is especially important in Applications that aim to improve health-related behaviors. In this chapter, the group thought process when faced with this paradigm will be discussed. It is important to note that since the app is heavily dependent on the Vital Jacket device, most of the functionalities and even design choices were made around this factor. Because this is a device used for more medical-oriented purposes, the group assumed that the target segment would be someone customers with basic knowledge or at least curious to learn about general fitness terms and concepts.

One of the initial concerns when developing any mobile application is the User Experience (UI) or, in other words, creating a positive experience for the user when interacting with the developed Application. For this, the user's hedonic needs were accounted by presenting a clean design and coherent color pallet throughout the various activities. This was achieved by choosing a dark mode as the default theme with vibrant arrangements of red combined with orange and blue. The same color style was purposefully maintained with the careful selection of the several icons chosen.

Logo Activity¶

When the user chooses to open the App, he is initially presented with the Logo Page comprising both the Icon and a Slogan, as depicted in Figure 1. This Activity lasts for 3 seconds and serves no functionality, being purely cosmetic. This was timed with a simple handler, a special Android object that will be further discussed below.

Fig. 1: StepNCount initial page.

Search Bluetooth Device¶

When the cycle of the initial activity comes to an end, the App switches automatically to the activity responsible for choosing the device to which the phone will connect. When the user selects the desired device, the Button will update its view with the MAC address chosen, serving as visual confirmation of the desired selection, as illustrated in Figure 2. Subsequently to the selection and button press, the App will wait 6 seconds but now with a designed purpose. This is done so the App has time to send the MAC address to the desired class, namely the service, and to perform the connection to the BioLib library. Once the connection is done, the user will be guided to the Main Page of the App, where the data from the week is displayed.

Fig. 2: Activity that pulls the MAC address of the desired device.

Foreground Service¶

From here, a few considerations had to be taken into account. Because the App should do most of its work when the user is not touching the phone (exercising) or even using other Apps (Spotify), the acquisition process had to be handled in the background. From this, Android provides many options for this type of operation, namely the Service class, which can be further subdivided into Intent Services, Job Intents, and Foreground Services. Albeit seeming like all these options could work, only one of these services is suited for our application. Since Android 8.0 (API 26), limitations to the execution of full Background services were implemented¹. The services are allowed to run when the App is being used but are killed shortly after the App goes to the background. This was to minimize Apps exploiting the device's resources without them knowing about it. Because of this, the only service that can run almost indefinitely and without restrictions is the Foreground Service², making it the obvious choice for our purposes. With this, the acquisition could be running even if the App is closed and the screen is locked. The only downside is that a notification will be displayed as long as the Service is running.

Handler Thread¶

Despite, working as intended, a foreground service is not capable of handling the acquisition alone. This is because these services, even though are running independently of the lifecycle of the Activities³, still run on the Main thread, that is, the UI thread. Trying to update the required UI views while also acquiring data would crash the App. Because of this, another thread had to be created to handle the acquisition within the Service running. When a thread is created, it loops through a Message Queue, each corresponding to a different task running sequentially independently from the UI thread. The Handler is the object responsible for integrating the Messages into the Queue. Furthermore, the Handler is also responsible for the actual execution of the Messages and serves as a communicator between the Acquisition Process and the UI Thread. A visual representation of this can be seen in Figure 3.

Once running, the service can only be destroyed if the Connection to the device is lost or it connects to a non-BioLib device. This was done because the App is only meant to work with a Vital Jacket device. Furthermore, if the service is destroyed while the user is actively using the App, this Search Activity will be started from the service itself. Therefore, this activity will be launched independently of the Activity the user is in, not allowing the user to use it without a valid connection. Moreover, communication with the database is also performed within this service, not allowing the App to lose data even if everything crashes. Once started again, the service loads the data from this database and updates the Views of the main page with the latest values for the steps, calories burned, time and distance walked or run.

Fig. 3: Visual representation of the different parts of a Thread. Adapted from⁵

Results¶

Once on the main page, the user can interactively visualize all the data from the week. All the progress bars and graphs are updated in real-time, with the graph adjusting its size in case the amount steps in that day surpass the maximum value of the week. The user can select one data point on the graph, which updates the day of the week with the UK local time, all the values of calories burned, time, and distance walked or run corresponding to the day selected are updated in the circular progress bars. Furthermore, the progress of that day corresponding to each one of those measures is also set. All of this can happen while the data point related to the current day in the graph keeps updating. Due to not providing an indicator of the battery of the device, an important factor for its correct use, a battery indicator was designed on this page as well. Four drawables were selected to represent a different stage of the battery depending on thresholds alongside the percentage left. Moreover, a status detection with three drawables is also provided (Figure 4). Finally, once the progress bar becomes full (in red), the user will be notified of completing the goal defined in the Goals Page, accessed through the button of the same name.

Fig. 4: The main screen of the Application

Goals page¶

Fig. 5: User-defined goals

Configs¶

Fig. 6: User input page

[1]https://developer.android.com/about/versions/oreo/background
[2]https://developer.android.com/guide/components/foreground-services
[3]https://developer.android.com/guide/components/activities/activity-lifecycle
[4]https://developer.android.com/guide/components/services
[5]https://www.youtube.com/watch?v=TN-CGfzvBhc&t=1221s