steroid-team / app

Helping you organise your day with ease and privacy.
1 stars 2 forks source link

Keep a single source of truth for nested data #44

Closed YagoGG closed 3 years ago

YagoGG commented 3 years ago

Right now, objects in the device's memory are mutable and the modifications made to them (like adding a Task to a TodoList) will only be reflected in the database if we make the operation through the database (e.g. Database.putTask).

This is not good because it leads to having two sources of truth for the app's data (the one in memory, and the one in the database).

The original discussion about this started in #41, where you can find more information about this. More specifically, here's a more detailed explanation of the issue (source):

To give you an example of how can this go wrong:

Database database = new VolatileDatabase();
TodoList todoList = new TodoList("My list");
Task task = new Task("Do something");

database.putTodoList(todoList);
todoList.addTask(task);

assertEquals(task, todoList.getTask(0));
assertEquals(task, database.getTask(todoList.getId(), 0));  // This breaks

That is why I mentioned in this comment that using an observer for each TodoList might be a good idea: that way, every time the in-memory object is mutated, we let the database know so they stay in sync. And, most importantly: that way we only have one way of doing an operation (instead of the two ones I show above).

So I totally agree with this having some important issues regarding mutability, but I think that we should figure out first what the view is going to consume, and then adapt the Database/TodoList APIs accordingly, because otherwise we are at risk of using a design that is not compatible with the Android view.

I would vote for merging this (functional yet quirky) initial version, create an issue to track what we are discussing, and give it a high priority in the next sprint so we can iterate over it. What do you think?