Design and functionalities¶

• Design and functionalities
  • Logo Activity
  • Search Bluetooth Device
    • Foreground Service
    • Handler Thread
    • References

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 the 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, 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.

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

References¶

[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