Design Program Logic

[RunpengNie]

Design the core program logic: the main functionalities. Add the functionalities descriptions and details to Design Document.

[RunpengNie]

The basic functionalities we should have:

Milestone2:

1. Allow users to register an account or log in if they already have one.

   • Store user data securely, including usernames and passwords.

2. User Profile:

   • Allow users to create and manage their profiles.
   • Collect information such as age, weight, fitness goals, and exercise preferences.

3. Exercise Entry:

   • Provide an interface for users to input their exercise activities.
   • Include fields for exercise type (e.g., running, cycling, weightlifting), duration, distance, intensity, date, and any additional notes.
   • Allow users to specify whether the activity was cardio, strength training, or flexibility training.

4. Exercise Tracking:

   • Store exercise data for each user in a structured database.
   • Allow users to view a history of their exercise activities.
   • Calculate and display statistics like total distance, total time spent exercising, and calories burned.
   • Provide visualization tools, such as graphs or charts, to track progress over time.

Milestone5:

5. Goal Setting and Tracking

   • Enable users to set fitness goals (e.g., run 5 miles in 30 minutes).
   • Compare actual exercise data with set goals.
   • Send reminders or notifications to help users stay on track.

6. Reports and Insights:

   • Generate reports and provide insights into users' exercise habits.
   • Offer recommendations for improving workouts or achieving fitness goals.
   • Recommend alternative variations of exercises if the user doesn't have access to certain equipment.

7. Privacy and Security:

   • Ensure user data is stored securely and in compliance with data protection regulations.
   • Implement user privacy settings and data access controls.

8. Notifications and Reminders:

   • Send reminders for scheduled workouts.
   • Notify users of milestones or achievements.
   • Timer to time rest period between sets.

`Option for now 'means we don't need to implement it now, but we need to consider code scalability for these features during design.

Any thoughts? @TonyLiu836 @VincentXiao997

[RunpengNie]

@Junzhou-712 Check this post and feel free to share your ideas.

[TonyLiu836]

Looks good! I think it's quite a comprehensive list of functionalities.

Some more optional QOL features that I think might be useful for user:

• Allow user to track weight/fat percentage/etc over time.
• Recommend alternative variations of exercises if user doesn't have access to certain equipment.
• Timer to time rest period between sets.

[RunpengNie]

Looks good! I think it's quite a comprehensive list of functionalities.

Some more optional QOL features that I think might be useful for user:

• Allow user to track weight/fat percentage/etc over time.
• Recommend alternative variations of exercises if user doesn't have access to certain equipment.
• Timer to time rest period between sets.

Good ideas, I will add them to our future design!

[RunpengNie]

Class and Functionality design for milestone2:

// class design

User class{
    String name;
    String email;
    String phoneNumber;
    String location;
    String gender;
    double height;
    double weight;
    double bodyFatPecentage;
}

WorkoutEvent class{
    DateTime date;
    Duration/Period duration;
    List<IExerciseEvent> exercises;
}

IExerciseEvent interface{
    Duration/Period duration;
    String additionalNotes;
}

EnumType DistanceUnit{
    mile;
    kilometer;
    meter;
}

Cardio class: implements IExerciseEvent interface{
    String name;
    double distance;
    DistanceUnit unit;
}

EnumType WeightUnit{
    pound;
    kilogram;
}

Strength class: implements IExerciseEvent interface{
    String name;
    double weight;
    WeightUnit unit; 
    int reps;
}

Flexibility class: implements IExerciseEvent interface{
    String name;
}

Custom class: implements IExerciseEvent interface{
    String name;
    double distance;
    DistanceUnit unit;
    double weight;
    WeightUnit unit; 
    int reps;
}

// functionality desgin: 

CreateWorkoutEvent()
DeleteWorkoutEvent()
UpdateWorkoutEvent()
SearchWorkoutEvent()

CreateExerciseEvent()
DeleteExerciseEvent()
UpdateExerciseEvent()
SearchExerciseEvent()

CreateCustomizedExecriseType()
DeleteCustomizedExecriseType()

CreateCustomizedExecriseEvent()
DeleteCustomizedExecriseEvent()
UpdateCustomizedExecriseEvent()
SearchCustomizedExecriseEvent()

TrackTrainingHistory()
TrackUserStatus()

@VincentXiao997 @Junzhou-712 let me know if you have any questions!

[Junzhou-712]

Looks like we haven't covered the type class so far. I think we still need a ExerciseType cls to store the names to allow user to specify whether the activity was cardio, strength training, or flexibility training . For this feature, we don't need a series of events instead of a series of types.

Update: Sounds good

[RunpengNie]

Hi guys, the first PR of this issue has been merged, thank you for your effort! Now we want to push our development progress, and next step is our model/class design.

@TonyLiu836 Could you please implement User , DistanceUnit, WorkoutEvent and WeightUnit? After you finish, please make sure your PR name contains 7.2 and mention this issue in your PR page.

@Junzhou-712 Could you please implement IExerciseEvent, Cardio, Strength, Flexibility and Custom? After you finish, please make sure your PR name contains 7.3 and mention this issue in your PR page.

[VincentXiao997]

User table

int id(PK),
varchar/string name,
varchar/string email,
varchar/string phoneNumber,
varchar/string gender,
double height,
double weight,
double bodyFatPecentage,

WorkoutEvent table

int id(PK),
int UserId(FK to user table),
Date date,
DateTime startTime, (nullable)
DateTime endTime,(nullable)
int duration(constraint),

ExerciseEvent table

int id(PK),
int WorkoutEventID(FK to WorkoutEvent table),
int SportId(FK to PredefinedExercise table),
int disance,
int weight,
int rep,

PredefinedSport table

int id(PK),
varchar/string sportName(UQ constraint),
int TypeId (FK to ExerciseType table),
boolean containsDisance, true
boolean containsWeight, true
boolean containsRep, true

CustomizedSport table

int id(PK),
varchar/string sportName(UQ constraint),
boolean containsDisance, true
boolean containsWeight, true
boolean containsRep, true

[Junzhou-712]

User Model

Number id(PK),
string name,
string email,
string phoneNumber,
string gender,
double height,
double weight,
double bodyFatPecentage,

WorkoutEvent Model
Number id(PK),
Number UserId(FK to user table),
Date date,
DateTime startTime, (nullable)
DateTime endTime,(nullable)
Number duration(constraint),
List<ExerciseEvent>

ExerciseEvent Model
Number id(PK),
Number WorkoutEventID(FK to WorkoutEvent table),
Number SportId(FK to PredefinedExercise table),
Number disance,
Number weight,
Number rep,

<!-- PredefinedSport table is a set of rules stored in AWS Redis -->
PredefinedSport JSON model {
  "id": Number,
  "sportName": String,
  "TypeId": Number,
  "containsDistance": String,
  "containsWeight": String,
  "containsRep": String
}

CustomizedSport table
Number id(PK),
varchar/string sportName(UQ constraint),
boolean containsDisance, true
boolean containsWeight, true
boolean containsRep, true

Hey folks, I have updated the recent program logic. A debrief for the change is 1. we use a list to store ExerciseEvent in accordance with the logic of NoSQL. 2. For the PredefinedSport, we combined the suggestions from @VincentXiao997 and @RunpengNie which is designing a batch of JSON data stored in embedded Redis, thus we can maintain them by JSON configs instead of SQL script.

[RunpengNie]

User Model

Number id(PK),
string name,
string email,
string phoneNumber,
string gender,
double height,
double weight,
double bodyFatPecentage,

WorkoutEvent Model
Number id(PK),
Number UserId(FK to user table),
Date date,
DateTime startTime, (nullable)
DateTime endTime,(nullable)
Number duration(constraint),
List<ExerciseEvent>

ExerciseEvent Model
Number id(PK),
Number WorkoutEventID(FK to WorkoutEvent table),
Number SportId(FK to PredefinedExercise table),
Number disance,
Number weight,
Number rep,

<!-- PredefinedSport table is a set of rules stored in AWS Redis -->
PredefinedSport JSON model {
  "id": Number,
  "sportName": String,
  "TypeId": Number,
  "containsDistance": String,
  "containsWeight": String,
  "containsRep": String
}

CustomizedSport table
Number id(PK),
varchar/string sportName(UQ constraint),
boolean containsDisance, true
boolean containsWeight, true
boolean containsRep, true

Hey folks, I have updated the recent program logic. A debrief for the change is 1. we use a list to store ExerciseEvent in accordance with the logic of NoSQL. 2. For the PredefinedSport, we combined the suggestions from @VincentXiao997 and @RunpengNie which is designing a batch of JSON data stored in embedded Redis, thus we can maintain them by JSON configs instead of SQL script.

LGTM, since I am not an expert on DynamoDB, I think Vincent's ideas are essential to us, what do you think @VincentXiao997 ?

[VincentXiao997]

PredefinedSport could be more flexible if we store them in the db as we can modify/create/delete them without deployment. I agree with your idea that customized sport templates should be stored in local table. nit, should we change PredefinedSport and CustomizedSport to PredefinedSportTemplate and CustomizedSportTemplate for better readability?

[RunpengNie]

PredefinedSport could be more flexible if we store them in the db as we can modify/create/delete them without deployment. I agree with your idea that customized sport templates should be stored in local table. nit, should we change PredefinedSport and CustomizedSport to PredefinedSportTemplate and CustomizedSportTemplate for better readability?

Both tables will store actual types of sports rather than templates, so I think the existing table names are already accurate enough.