## 3 Materials and Methods
### Web Ecosystem Design and Proof of Concept Implementation
#### 3.2.2 Smartphone Application
Once the registration process is completed, the user will access the main menu view. Once identified, the user can access all functions defined in the application, and the background services start running. The application stores the status of the session, not requiring a new login if the user accesses the application. Figure 4: Architecture of the smartphone application designed. Figure 5: Views representing the access to the application, including register and login operations. From the main menu, the user can access the list of available surveys (Figure 5(a)). In particular, Figure 5(b) represents a question from the physical activity survey, while Figure 5(c) represents an example of the depression survey. These recurrent surveys defined in the application can contain predefined questions and free text fields to introduce a numeric value. Finally, Figure 5(d) presents the survey of the consumption of occasional medication, which presents a list of different categories of medicines, including examples of common pharmacological brands. Once any survey is completed, the user must push the finish button. In that instant, the application codes the responses in JSON representation and sends them to the web platform. Despite medicine surveys, the rest of the surveys are designed not to allow multiple responses, and those fields asking for a number force the introduction of only numbers. After introducing the user interface of the application, we subsequently present the services developed in the application to offer its essential functionality. As previously depicted in Figure 4, the application has a general service always active, which is in charge of launching and managing other subservices focusing on particular tasks. These subservices are alive until they accomplish their purpose. In particular, this main service must surpass the restrictions imposed by recent Android versions over background services, which can kill services even if they have priority. We have implemented a pinned notification to force Android to believe that our application is in the foreground. This notification is also useful for the user, which can verify if the application is correctly running. Next, we present a description of the tasks performed by each subservice:  
* Location service: this subservice is executed by the general service every 30 min. It focuses on acquiring the location of the smartphone using the GPS and transmit it to the web platform aiming to obtain weather and pollution data. Due to this service, the application must ask for location permissions. * Wearable service: it is executed every 15 min, and its tasks are to verify if the wearable has information to transmit to the application. If there is data available, it starts a transfer process for its acquisition. Figure 6: Examples of the user interface related to surveys. Backup service: it is executed every 30 min, and it is in charge of verifying if there are data not sent to the web platform due to a connection problem. It is essential to note that this service does not store the location data since the external services do not implement queries over past instants.