Project

General

Profile

Design and functionalities » History » Version 11

Version 10 (Miguel Rocha, 06/01/2023 21:56) → Version 11/31 (Miguel Rocha, 06/01/2023 21:58)

h1. Design and functionalities

{{>toc}}

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 .

h2. Design

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.

h2. 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 Java object that will be further discussed below.

p=. !{width:200px}Logo.jpg!
_Fig. 1: StepNCount initial page._

h2. 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. 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, that is, exercising, 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 .

work