sstent/FitTrack2
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Update spec, fix bugs, improve UI/UX, and clean up code

Browse Source
This commit is contained in:
sstent
2025-12-25 08:33:01 -08:00
parent 8fe375a966
commit df9dcb2f79
21 changed files with 1741 additions and 1055 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
FitnessSync/specs/002-fitbit-garmin-sync/research.md Normal file
View File

@@ -0,0 +1,30 @@
# Research: Fitbit/Garmin Data Sync
**Date**: 2025-12-24
This document outlines the research performed for the Fitbit/Garmin data sync feature.
## `garth` Library for Garmin Communication
**Decision**: The `garth` library will be used for all communication with the Garmin Connect API.
**Rationale**:
- The user's initial technical specification explicitly mentioned and provided examples using `garth`.
- The library appears to be actively maintained and provides the necessary functionality for fetching activities and health metrics.
- It handles the authentication flow with Garmin, which is a complex part of the integration.
**Alternatives considered**:
- `garminconnect`: The user's `requirements.txt` includes this library, but the technical details provided in the prompt favored `garth`. `garth` seems to be a more modern library for interacting with the Garmin API.
**Key Findings from User Prompt & `garth` Documentation:**
- The user's prompt provided detailed code snippets for using `garth` to fetch `DailySteps` and `DailyHRV`. This will serve as a strong starting point for the implementation.
- The `garth` library offers a variety of other metric types that can be explored for future enhancements (e.g., stress, sleep).
- Authentication is handled by the `garth.client.Garth` class, which needs to be configured with the user's credentials. The application already has a mechanism for storing API tokens, which will be used to store the Garmin credentials.
## API Endpoint Design
**Decision**: The API endpoints will be implemented as described in the user's initial technical specification.
**Rationale**: The user provided a complete and well-defined set of API endpoints, including request/response models and URL paths. This design is consistent with a standard RESTful API and meets all the requirements of the feature.
**Alternatives considered**: None. The user's specification was clear and complete.