The current version of the OpenTracks app lacks the functionality for comprehensive data management and CRUD operations on user profiles and run data. There is no implementation to manage or interact with this data post-entry.
Proposed Solution:
Implement a robust system for managing user profiles and run data, enabling the following functionalities:
Our feature aims to enhance the user experience by enabling users to save and manage data related to their runs, including personal information and detailed GPX data. The core functionality will allow for creating, reading, updating, and deleting (CRUD) operations on user profiles and run data.
Feature Details:
User Profile and Run Data Management: Users can add, look at, change, or remove their own information and details about their runs. This covers personal info and detailed GPX data.
Expected Outcome/Result:
Persistent Data Storage: Users can now save their run data, including routes, times, distances in a secure and reliable manner.
This data is stored externally, meaning it can be retrieved and viewed anytime, from any device where the user has access to their account.
Alternative Solutions:
Before settling for Firebase DB, a variety of external data storages were considered. The first question is always whether to go for SQL or noSQL architectures, and we opted for noSQL given the flexibility, scalability, and efficiency it provides.
Several viable noSQL options exist, but for an Android app a great starting point is typically a direct integration with Firebase and their real-time database API, since they belong to the same ecosystem.
Lastly, we considered using a graph-based database, which is typically a good choice for social media and friend system, but figured it was overkill for the expected number of users and anticipated functionality.
Testing:
To test the correctness of this feature, a set of automated tests will be written for every persistence API method created, including CRUD on User Profile, CRUD on Run and various connection scenarios.
A last metric to assess correctness is that Groups 14 and 15 should easily and swiftly integrate with this code.
Feature Request:
External Persistence Capability
The current version of the OpenTracks app lacks the functionality for comprehensive data management and CRUD operations on user profiles and run data. There is no implementation to manage or interact with this data post-entry.
Proposed Solution:
Implement a robust system for managing user profiles and run data, enabling the following functionalities: Our feature aims to enhance the user experience by enabling users to save and manage data related to their runs, including personal information and detailed GPX data. The core functionality will allow for creating, reading, updating, and deleting (CRUD) operations on user profiles and run data.
Feature Details:
User Profile and Run Data Management: Users can add, look at, change, or remove their own information and details about their runs. This covers personal info and detailed GPX data.
Expected Outcome/Result:
Persistent Data Storage: Users can now save their run data, including routes, times, distances in a secure and reliable manner.
This data is stored externally, meaning it can be retrieved and viewed anytime, from any device where the user has access to their account.
Alternative Solutions:
Before settling for Firebase DB, a variety of external data storages were considered. The first question is always whether to go for SQL or noSQL architectures, and we opted for noSQL given the flexibility, scalability, and efficiency it provides.
Several viable noSQL options exist, but for an Android app a great starting point is typically a direct integration with Firebase and their real-time database API, since they belong to the same ecosystem.
Lastly, we considered using a graph-based database, which is typically a good choice for social media and friend system, but figured it was overkill for the expected number of users and anticipated functionality.
Testing:
To test the correctness of this feature, a set of automated tests will be written for every persistence API method created, including CRUD on User Profile, CRUD on Run and various connection scenarios.
A last metric to assess correctness is that Groups 14 and 15 should easily and swiftly integrate with this code.