Sprint 3
In this YouTube link you can check our ethical reflection about this sprint.
As per our app's development plan, we have incorporated two important strategies to ensure that our users have a seamless experience while using our application.
The first strategy is the "Network falling back to cache" approach. We understand that in today's world, having a reliable internet connection at all times is not always possible. Hence, we have designed our app in a way that even when the network is not available, our users can still access our app's features. In such cases, we provide our users with an older cached version of the content. We are mainly using Firebase caching to achieve this.
Since our app's functionality is dependent on other users' activities, it is imperative to ensure that our users can still access our app's content even when the network is not available. For instance, a user can plan their own events and create them, but they would need to connect to the network if they want to see the most recent activity related to sport events. With our "Network falling back to cache" approach, our users can access the most recent cached content even when the network is not available.
The second strategy we have implemented is the "Data fetching strategies: Pull (on user demand)" approach. As the name suggests, this approach involves retrieving the data from the network when the user commands it. In our app, we have ensured that no data is downloaded in the background. This is because the nature of our app does not require continuous background data downloading.
Additionally, we also implemented always online for the authentication features and default resources when nothing is stored in cache.
Scenario 1: A user is using our app to browse upcoming sports events in their area. While they are browsing, their internet connection suddenly drops. In this case, our app would detect the loss of connectivity and automatically switch to the cached version of the content. The user would be able to continue browsing and view the most recent sports events that were previously downloaded and cached on their device. Once the network connection is restored, the app would sync with the server and update the content with the latest data.
Scenario 2: A user creates an event in our app while they are offline. The app would automatically queue the event creation request and store it locally on their device. Once the user regains connectivity, the app would sync with the server and publish the event on our platform. This approach ensures that users can continue to use our app's features even when they are offline, and their data would be saved and synced automatically once the network connection is restored.
Overall, our app's "Network falling back to cache" approach and event queuing system are designed to provide a seamless user experience, regardless of connectivity issues. By allowing users to access cached content and queue their actions while offline, we can ensure that our users always have access to the most relevant and up-to-date content on our platform.
- Home View
- Stats view and features (Type 2 BQs display)
- Profile View
- BPM Monitor view and features
- Firebase Singleton implementation
- Leave event feature
- Assigned issues
- Merge requests
-
Business Question Implemented:
What is the distribution of users per sport? (Type 4)This business question was implemented via GCP Cloud Functions and displayed in a Google Data Studio dashboard:
-
Cloud Functions source code: https://gitlab.com/ISIS3510_202310_Team24/Analytics_Engine/-/blob/main/functions/src/index.ts
-
Google Data Studio Dashboard:
{width="800"}Link to the dashboard: https://lookerstudio.google.com/reporting/12d7ac50-3afd-4940-94f4-78c609f58695
-
-
Eventual Connectivity Strategies: All of the EC strategies implemented were all of the type "network falling back to cache", with a "Pull (On user demand) data fetching strategy.
The specific features that had these strategies implemented were:- My Stats Feature
- My Profile Feature
-
Local Storage Strategies: The local storage strategies used were Shared Preferences and DB Storage, more precisely, the use of RealmDB. The specific features that had these strategies implemented were:
- BPM Measurement feature (now the BPM data is stored locally in Realm)
- New: Settings View (Settings are stored in Shared Preferences)
-
Multithreading Strategies: The multithreading strategies used were Futures, asynchronous functions and Isolates, the specific features that had these strategies implemented were:
- My Stats feature (all of the calculations and rendering are now done asynchronously, previously it was sequential)
- New: RealmDB Cleanup feature (An isolate is spawned once the app is launched to clean old db data)
- New: Shared Preferences retrieval on Startup (A future is used to control succesful data retrieval)
- My Stats initial retrieval (A future is used to control succesful data retrieval)
- BPM Controllers initialization (Futures are used to control proper functionality in the BPM viewmodel)
-
Caching Strategies:
The caching strategies used relied mostly on Firebase's own caching system, however it was modified so data retrieval from cache was done manually instead of automatically. Furthermore, a manual max caching size set in Firebase's configuration. On another note, we also implemented CachedNetworkImages from the "Cached Network Image" library in order to store network images and handling proper caching.The functionalities that use caching are:
- My Stats Feature (Firebase Caching)
- My Profile Feature (Firebase Caching and CachedNetworkImage)
- Authentication view and features (Login/signup)
- List Events view
- User model, DTO and Repository implementation
- Icon selection and importing
- Firebase Performance Dashboard Integration: (BQ type 1) Which are the local features that take the longest time to execute compared to the average execution time? Which part in the code is causing this performance impact?
- Assigned issues
- Merge requests
-
Business Question Implemented:
Which is the most used feature and why is it the most used? (Type 3)This business question was implemented by using BigQuery data warehouse and displayed in a Google Data Studio dashboard:
-
Google Data Studio Dashboard:
{width="800"}Link to the dashboard: https://lookerstudio.google.com/reporting/9d320892-5b22-407d-900c-43723cffb673/page/rgIKD
-
-
Eventual Connectivity Strategies:
There were EC strategies implemented of the type "network falling back to cache", with a "Pull (On user demand) data fetching strategy. The specific features that had these strategies implemented were:
- List Events Feature.
- List Events with Filters Feature.
There were EC strategies implemented of the type "network only". The specific features that had these strategies implemented were:
- Login Feature.
- SignUp Feature.
There were EC strategies implemented of the type "generic fallback". The specific features that had these strategies implemented were:
- New: Local time feature on List Events.
-
Local Storage Strategies: The local storage strategies used were the use of Shared Preferences. The specific features that had these strategies implemented were:
- New: Add "Turn Off Autoreload from List Events" setting (Settings are stored in Shared Preferences).
-
Multithreading Strategies: The multithreading strategies used were Futures, asynchronous functions and Isolates, the specific features that had these strategies implemented were:
- New: Get hour on List Events (Now we are obtaining the current hour from an API asynchronously to help the user in the events scheduling).
- New: New events autoreload feature on List Events (A stream is used to notify the screen when there are new events to visualize on the list)
- Events retrieval (A future is used to manage getting the list of events).
- User creation (A future is used to manage user signup).
- User login (A future is used to manage user login).
-
Caching Strategies:
The caching strategies used relied mostly on Firebase's own caching system, however it was modified so data retrieval from cache was done manually instead of automatically. The functionalities that use caching are:- List Events Feature (Firebase Caching)
- List Events with Filter Feature (Firebase Caching)
- Create Event view and features
- Event details view and features
- Event model, DTO and Repository implementation
- Join event feature
- (BQ type 1) How many times has the app crashed over the past week? Which elements are causing the crashes?
- Assigned issues
- Merge requests
- Smart Feature
-
Business Question Implemented:
What are the most requested or desired features by users who are looking for sports partners? (Type 3)Is there a sport that is highly requested by users but not yet available in the app? (Type 3)
The google sheets api was configured with the project to be able to review all the requests of the users and with the updated information the dashboard is created.
-
Dashboard:
Link to the dashboard: https://docs.google.com/spreadsheets/d/1gXQMKMA4ywvonC7Pf4BBtTIamsVCNJmbzy7mwfRoIqE/edit?usp=sharing
-
Dashboard:
-
Eventual Connectivity Strategies:
There were EC strategies implemented of the type "network falling back to cache", with a "Pull (On user demand) data fetching strategy. On another note, we also implemented Firebase Caching that allowed us to queue user actions, such as create event so they are performed once the device reconnects to the network. The specific features that had these strategies implemented were:
- Event Detail
- Create Event (Creation queued with Firebase)
- Screen Help (Smart Feature with openai)
-
Local Storage Strategies: The local storage strategies used were the use of Shared Preferences. The specific features that had these strategies implemented were:
- New: Add a new feature in Create event that allows the user to save and load an event tameplate (Shared Preferences).
-
Multithreading Strategies: The multithreading strategies used were Futures, asynchronous functions and Isolates, the specific features that had these strategies implemented were:
- In the Context Aware feature an Isolate was implemented to be able to signal the user without blocking the main thread
- Event Detail (Async)
- Create Event (Futures)
- Google Spread Sheets API (Futures, Async, uses asynchronous calls to be able to modify the google sheets database)
- Geolocalizator call (Async, waits for the user to grant permissions to access the location and then makes an asynchronous request to get the data)
-
Caching Strategies:
The caching strategies used relied mostly on Firebase's own caching system, however it was modified so data retrieval from cache was done manually instead of automatically. The functionalities that use caching are:- Detail Event Feature (Firebase Caching)
- Create Event Feature (Firebase Caching)
- Auth features and views (login/signup)
- Crashlytics and performance analysis feature (BQ type 1).
- MVVM implementation
- Singleton implementation
- Models, DTO and repository implementation
- Functionality that uses external services (different from authentication): Crashlytics and performance analysis.
- Assigned issues
- Merge issues
- Caching strategy: Data is being cached over Firebase caching strategies defined by them. Even though, at the time Firestore is defined caching come along with its definition, I changed its configuration manually to make caching space unlimited. Caching configuration:
{width="700"}
-
Eventual Connectivity strategy: Network failling back to cache is implemented with Firestore help, when there is no connection Firestore will fetch its data with the one stored on cache. Also, Network Only was implemented on SignUp and LogIn processes. The following screenshots show how the system informs the user that that feature is not available until there is internet again, it block the login/signup button so user cannot login/signup until there is internet connection.
{width="700"}
Aditionally, Room database serves as a fallback when there is no internet connection when consulting data for the feature made for BQ type described below. - Local storage strategy: The local storage strategy was implemented to save user configuration information, which depends on the user's preferences. This was done by storing that information in a sharedPreferences file. This file is written every time the user manipulates the application settings. The implementation can be seen in the Settings ViewModel of the application, and the following code snippet shows the initialization:
{width="700"}
A local database was implemented using the Room library. In the statistics view, where we get the amount of events that didn't get enough participants, it serves as a fallback, in case there is no internet connection.
- Multithreading strategy: When consulting Room DB for resolving BQ type 2 described below or consulting Firestore events, I used multithreading. Those callings are not made on the main thread, as well as when the counting is being done.
- Business Question: BQ type 2: How many times has an event creator failed to bring the number of people he signed up for the activity?
- Home, stats and settings view/feature.
- Design pattern implemented: Observer (BrightnessController, BrightnessObserver)
- View implemented: ProfileActivity (activity_profile.xml)
- ViewModels implemented: PhotoViewModel, UserViewModel
- Repositories implemented: PhotoRepository, UserRepository
- Context aware functionality: Change the brightness of the screen depending on the brightness.
- Functionalities using sensors: Taking a photo to change the user picture. Change the brightness of the screen depending on the brightness
- Functionality that uses external services (different from authentication): Uploading user photo to Firebase Storage.
- Merge requests
-
BQ implemented (Type 2): Recommend an event to a user based on past attended events. A recommendation algorithm based on collaborative filtering was implemented, where a score is calculated for each event based on previous events to which the user has registered and the event with the highest score is recommended. The implemented algorithm is in the EventRecommender class within the Controller folder.
-
Caching Strategy implemented: The Picasso library was used to display the user's profile photo, and to display the image of the user's achievement, in the ProfileView.
{width="700"}
Local Storage strategies implemented:
- ViewHolder pattern: The Events adapter class is used to load the events in the ExploreView (it uses the ViewHolder pattern to assign view objects via the onBindViewHolder() method). This pattern is an optimization technique used in adapter implementations for RecyclerView in Android, and its goal is to minimize the number of calls to the expensive findViewById() function, which looks for a view within the layout hierarchy on each call.
{width="700"}
- Local Database: A local database was implemented using the Room library. In the explore view, where we get the events of the last 30 days, it serves as a fallback, in case there is no internet connection.
{width="700"}
{width="700"}
- Multi-threading strategy: To access the local database, an ExecutorService (ExecutorService is an interface in Java that provides a way to run tasks in background threads) was used to create background threads and perform read/write operations on the database so as not to block the main thread and to not interrupt the user experience.
{width="700"}
- Eventual connectivity strategy Get Events using Network falling back to cache. In case there is internet connection, the events are fetched from the firestore events collection. Otherwise, the user is shown the events stored in the local db, along with a notice telling him that he is offline.
{width="700"}
PS: Not all EC screens were shown since most have a similar message to the user that indicates the lack of internet connection.
| EC on Auth | Current Time | BPM Stats (Local Storage) |
|---|---|---|
 |
 |
 |
| Event Create Templates (Local Storage) | Settings (Local Storage) | Weather Forecast (CAS Isolate) |
|---|---|---|
 |
 |
 |
| EC on Event Details | EC on My Stats | EC on List Events |
|---|---|---|
 |
 |
 |