csc207-uoft / course-project-aarves Goto Github PK

So we have to decide how the architecture will work for the UI. I'm not too familiar with the Android framework, but it seems it is naturally (sort of) in line with the MVVM pattern. However, I'm pretty sure we are expect to make both Presenters and Controllers for this project. Making a Presenter in a way similar to the MVP pattern is straightforward, and it can be combined with ViewModels pretty easily. The problem is Controllers aren't as natural in Android, since Activities have both Controller-like and View-like properties. The solution might be to delegate inputs to Controller classes or something similar.

Any other thoughts?

What is the point of entities if we have data persistence? How will we distinguish entities from DTOs from data persistence (i.e. what can entities do which won't be stored in a database)? Are entities basically just in-memory data storage for convenience more than anything?

After removing a review from reviews, the size of the list shrinks.

Example:
So, say reviews has 5 items with reviewIDs 1, 2, 3, 4, 5.

If review with reviewID 3 is deleted from reviews, then the size would be 4.

Adding one more review will increase the size to 5, then now there are two reviews with ID 5.

It is called in Location's toString, so this may cause issues since there is no check for zero division either before the call or in the method get_avgrating.

We may want to give a Location with 0 reviews an average rating of -1, and in the toString, add a check for == -1, and if that is the case, say "This location has no reviews yet."

• Bookmarks will not be implemented for Phase 1
• Deleting a User does nothing to the User's Reviews
• AccountDataImpl uses ReviewRepositoryImpl, which is bad!
• Not very prepared for a "view other accounts" feature (due to password storage)
• Used AppDatabase on main thread - maybe look into async for Phase 2

Here are some of my thoughts regarding the current state of our data persistence system, and some Clean Architecture related issues.
First, here is an approximate diagram for the current implementation. Note that I put ReviewList in the use cases layer, since apparently Maps are use cases.

One apparent problem would be that the ReviewSerializer must be on the lowest level since it directly uses GSON to store data, which presents a problem since it depends on a use case. This might not necessarily be an issue because in reality Clean Architecture is never mentioned to be a strict layered architecture, though the course slides say so (so which should we follow?). The more pressing issue is that, according to the book:

The important thing is that isolated, simple data structures are passed across the boundaries. We don’t want to cheat and pass Entity objects or database rows.

What we are doing is basically passing a use case which contains entities across boundaries which is probably an even more severe form of 'cheating'. However, many data persistence frameworks do this, where entities are directly referred to for persistence purposes, at least for the newer frameworks I think. Even in the following picture from the book:

The DataAccessInterface depends on entities, which means its concretion in the outermost layer would probably need to as well? Some ideas are as follows: