Storing multiple workout types, durations and dates to the same user

I’m creating a workout/wellness app.

A user can add workouts or wellness activities, add a duration for each, and a date for each (assumed “today” by default). There can also be multiple workout or wellness activities per day. Currently the user rows are a glide table with a column for Exercise, Exercise Date, Exercise Minutes, and the same for wellness. Each is storing Text, Date, and Number values respectively.

The problem become pretty obvious right away. Each column is only storing one value for each cell, which means the calendar view is only ever showing 1 date as “complete”. How can I store these multiple workout values (that are still related to each other in name, date, minutes) per user without creating a huge amount of columns?

What do you mean? What experience do you want to create in the Layout Editor?

Overall you seem to be doing well:

  1. One Workout-Wellness table with the following columns: RowID, Exercise, ExerciseDate, ExerciseMinutes, ExerciseType (either ‘Workout’ or ‘Wellness’). Every time a user logs a new exercises, a new row will be added.
  2. One ExerciseType table with a RowID and a Type column with two rows (Workout and Wellness) that will be the data source for a choice component.
1 Like

@nathanaelb This would be over 2 different screens in the Layout Editor.

  • Screen 1 will have two dropdown fields, one for exercise and one for wellness. If one is selected, conditional fields appear underneath, asking for date and minutes. Ideally, this would also trigger a second button saying to “add another exercise/wellness” depending on which dropdown was triggered. Then there’s a save button that is expected to save this data to the table.
  • Screen 2 will have a calendar view, and you will be able to see which day(s) have had an activity done on them. These will be accumulated into team counts for wellness challenges as well, but that is a future issue for now.

Does that clear it up a little more? If I were to have an entire table for exercises, would these essentially turn into Relations?

EDIT: Screenshot added for clarity

You do have a table that will house one workout and one wellness session per row, right?

@nathanaelb I didn’t before, but I do now. This is my first Glideapps project, so I’m not sure how to relate two tables of data to each other in this way, yet. I’m aware of something called “Relations”, but assumed it would be better to have some sort of large array or object in one cell, for each user?

There are many way of doing things.

You could:

  • Have an Activities table where you will house your activities (workouts and wellness sessions), with one session per row.
  • In the Activities table, you could have a basic text column called ‘Activity Type’ which would indicate if each row is either a ‘Workout’ or ‘Wellness’.
  • You could have a ‘Choices’ table where in one column one row will be Workout and another Wellness. This table and column would be used in a choice component when you need to write a new row in the Activities table.
  • Use the Users table for user-related information only (for now).

For now, you could use the Show Add Screen and Form Container as forms to submit data to the Activities table.

This could be done differently of course.

1 Like

Interesting, I have been making all columns user-specific, assuming that that’s how you would want to store the data. Otherwise, wouldn’t the calendar view show all workouts entered by all users, rather than just the logged in user?

Every time you would write a new activity to the Activities table, you would also write the email address of the owner of that activity. You would then either filter the collection in the Layout Editor to only display activities that have the same email address as the email address of the signed-in user, or better you could apply row ownership to the Owner column in the Activities table and only one own’s activities would be downloaded to a user’s device.

3 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.