Architecture

Architecture matters.

https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Dependencies should be in the direction of increasing abstraction.

"Top/Inner" in this case == more abstract; business logic should not depend on a database implementation.

Business logic shouldn't even know about the implementation.

"Conforming to these simple rules is not hard, and will save you a lot of headaches going forward. By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss."

Activities and Fragments

---

ViewModel per Activity

---

UseCase class per application use-case to pass data (in one or the other direction)

---

Repository is defined as Interface so UseCases can use it as output port

https://martinfowler.com/eaaCatalog/repository.html

Data layer(s) with Interface (EntryDao Interface for Room/SQL Database)

https://five.agency/android-architecture-part-2-clean-architecture/ https://five.agency/android-architecture-part-3-applying-clean-architecture-android/