0
votes

I'm developing an Android App for managing tasks in a household like cleaning the kitchen, vacuum cleaning ...

I implemented a Json based API to retrieve and store data from a central database.

Every household can have one or more residents. It also can have any count of tasks.

The task handling is where my question is related to. The task's due dates should be equally distributed to each resident in a household and every resident should be able to view and complete their tasks.

In my current design, it has the following properties: Id(int), Label(String), Description(String), Start_date(date), Start_resident_id(int), household_id(int),week_interval(int), weekdays(int)

start_date: the date when the task was created (needed to calculate due dates)

week_interval: this task should be done very X week ( 1 weekly, 4 monthly, ... )

weekdays: the weekday the task should be done ( e.g. 14 means MON, THU, 1357 means MON, WED, FRI, SUN )

There is also a task_status model which is created as soon as a resident marks a task as completed.

task_status: id(Int), task_id(Int), status(int), resident_id(int), due_date(date), comment(string)

status: 1 = completed, 2 = skipped

resident_id = foreign key of the resident which has completed the task

  1. what is the best way to calculate the due dates for each task and resident ?

  2. is this a good design having these task_status entries to mark the tasks as completed ?

1

1 Answers

0
votes

The model seems basically right to me. You have a definition of a repeating task, and you have instances of this task, representing specific executions.

The due date is a bit unclear to me. What do you want to express with it? I can think of two ways a task can be due:

  1. The task has been started, not yet completed, and the next iteration of the task is about to start. But when should an execution be due? Exactly when the next iteration starts? Maybe you want to include that into the task definition, like a task must be finished x days after its scheduled start.
  2. Nobody has started the task for some time. So the task itself is due to be started once again. But maybe you are creating instances of the task automatically at each iteration, then this would be redundant.

You could also think of removing the due date from the stored data. Since you have the start dates and the intervals you can always dynamically compute the due date. Of course if you change the task definition, old execution instances could become meaningless.

So the first due date computation is for the task itself. Take the last (by date) completed execution of a task and calculate the time interval between then and now. If this is greater than the defined interval, the task is due to be started again. Second computation is for specific executions of a task. Take the uncompleted execution of a task and compare its start date and the current date to either a predefined amount of time one has to complete it or the predicted start date of the next execution. It really depends on how you create the instances and how you want to specify "due".

In case you want to have flexible scheduling of tasks it may become more complicated: What if a task was started before or behind the scheduled day? What if you completed cleaning the kitchen just the day before a new execution is scheduled? Does it make sense to clean the kitchen on two consecutive days?