Creates adapter for to-do lists with the database.

[YagoGG]

Hey @theo-damiani!

So after our meeting today and the concerns that you pointed out about the multiple adapters, I have been giving it a thought and I have come up with this proposal:

• The Database interface should be an abstract API for storing the objects that our app knows (e.g. Task instances).
  This means that the interface should have methods like:
  • putTask(Task task)
  • getTask(int taskId)
  • ...
• The specific database implementations should take care of the logic underneath the object storage. This means that, for example, the VolatileDatabase can serialize the objects and store them in a HashMap. The FirebaseDatabase that I'm working on will do something else. But the key here is that all of them share the same API (the one defined by Database), and each implementation takes care of the details (just like if they were "drivers" for using a specific database backend).

The main upside that I see here is that we no longer need adapters, and every time we create a new kind of object (like TODO lists, notes...) we only have to define the new methods in the Database interface and their corresponding implementations.

I would love to know your thoughts on this, what do you think?

[theo-damiani]

Hey @theo-damiani!

So after our meeting today and the concerns that you pointed out about the multiple adapters, I have been giving it a thought and I have come up with this proposal:

* The `Database` interface should be an abstract API for storing the objects that our app knows (e.g. `Task` instances).
  This means that the interface should have methods like:

  * `putTask(Task task)`
  * `getTask(int taskId)`
  * ...

* The specific database implementations should take care of the logic underneath the object storage. This means that, for example, the `VolatileDatabase` can serialize the objects and store them in a `HashMap`. The `FirebaseDatabase` that I'm working on will do something else. But the key here is that all of them share the same API (the one defined by `Database`), and each implementation takes care of the details (just like if they were "drivers" for using a specific database backend).

The main upside that I see here is that we no longer need adapters, and every time we create a new kind of object (like TODO lists, notes...) we only have to define the new methods in the Database interface and their corresponding implementations.

I would love to know your thoughts on this, what do you think?

Thanks for your thoughts @YagoGG !

I think it will be great to keep one "main" adapter so we can split the database implementation to the task/todo/.... And so maybe in the future if we add a cached database or whatever you want, related to the database we only have to add a "layer". So we have a Decorator pattern. And if we want to add voice notes we just need to create the class and add methods in the main adapter.

Personally, I will go for this. I think it's more modular and we can work independently. Tell me if you think it's good. But it's what you said. We just keep one big adapter.

here a small drawing to maybe better understand:

[YagoGG]

Thanks for the drawing and the detailed explanation, @theo-damiani! :)

So if I understood correctly, the MainAdapter's job would be to serialize & deserialize the objects, and then store them in the corresponding database?

The issue that I see in that case is that each database has a different implementation, and not all of them require serialization. To give you an example:

• The VolatileDatabase can store the objects directly without serialization, e.g. HashMap<Integer taskId, Task task>.
• The FirebaseDatabase will serialize the objects indeed, but using its own format (probably JSON).
• If for instance we were to switch to a MySQL database, serializing the objects would be no good (because we could store each attribute in a different column of the table).

That's why I think that the actual logic to convert the object to whatever accepts the database should depend on the Database implementation itself, instead of using serialization and assuming that allDatabases will store serialized objects in key-value pairs. Makes sense?

[theo-damiani]

Ok! I see, I missed the point on serialization and the fact that it might be different. You write I will follow your first explanation: one database interface with methods (putTodo, put....) and no adapters.

I will change and commit today the Database Interface so you can work on your own firebase implementation.

[YagoGG]

There's no rush at all, this is not blocking me for now as I am now working on some tests. Take all the time you need. :)

Cheers!