Task breakdown:

Elaboration:
The first week of the group project!

This week our main aim was to get everyone to a good level of understanding about what we need to do and what we need to know to be able to achieve what we need to do.
So after the meeting we set about doing the GitLab practical for everyone who could attend (those who couldn’t were added afterwards).
I hosted the repository and Hannah was able to add to it, confirming everything works as intended, including merges.
Afterwards I also added the group meeting mins to the repository as we’ll be using it for project storage going forwards.

Most of the group favoured a google docs solution for their blogs but I’m using WordPress blog as I think it’s a bit of a more elegant solution, as it makes getting to new posts easier for Neal as well as providing good commenting functionality and organisation by recency.

Due to some issues with organisation, I ended up switching tasks for the most part with Edd, so I’m now looking at data storage.

Persisting data in java research:
The first part of the process is to break down the problem to find out what needs to be stored in the program as a whole, this will allow us to get a good idea of the various different possible techniques we could use.

From the requirements, a quick list of items that need to be stored could include: preconfigured exercise routines with associated data (total time, number of exercises, etc), available exercises (with metadata (time, category etc)), exercise guidance (mentioned separately as the medium is different to text potentially) and finally exercise completion records.

The specification states that the program will be a single user system and stored locally on a single device, we don’t have to take portability, access and multiple user data into account.

In theory we want to keep the number of dependencies to a minimum, so we want a solution that will work for as many of the requirements as possible, with as little bloat as possible.

The main two methods of persisting data that I can find is a RDBMS system like SQLite or a NoSQL system like GSON. While it’s most likely possible to make both systems work for our project, we can analyse the specific use case to try and figure out which is preferable.

Looking at the overall problem we’d have three main interlinked components, the exercises, the exercise routines and the exercise completion record.

Exercises can be quite rigid, the only potential variance issue is with different forms of guidance, but that can be avoided if a single method is decided upon for all of them.

As specified in FR5 and FR2, the pool of exercises in a set is not controlled by the user and can be standardized (if not then complications could arise if using a SQL based system).

In conclusion, as far as I can tell, the main concern is this: can the data format be standardized? If yes, then a SQL system is probably preferable, you can create a single database with 3/4 linked tables that control all of the stored data. If no, then a JSON based solution is the way to go, as it’s additional flexibility allows for things like pre-set customized exercise set pools without the headache doing it in SQL would cause.