:books: Android Sample App using modular, clean, s...

# feed

[Madalin Valceleanu]

📚 Android Sample App using modular, clean, scalable, testable Architecture written in Kotlin that presents modern 2019 approach to Android application development, latest tech-stack and best practices.

Application is based, apply and strictly complies with each of the following 5 points:

• A single-activity architecture, using the Navigation component to manage fragment operations.
• Android architecture components, part of Android Jetpack give to project a robust design, testable and maintainable.
• Pattern Model-View-ViewModel (MVVM) facilitating separation of development of the graphical user interface.
• S.O.L.I.D design principles intended to make software designs more understandable, flexible and maintainable.
• Modular app architecture allows being developed features in isolation, independently from other features. For more technical details please check the project readme.

Project link: https://github.com/VMadalin/kotlin-sample-app

[Michal Harakal]

Really nice, may I ask you, how did you made diagrams (subjecting they are hand painted)?

[Madalin Valceleanu]

Thank you, Michael. I made them with draw.io, using a comic option on elements

[Michal Harakal]

I have also 2 other questions. 1. Did you thought about having "java/kotlin" modules without dependecy to Android? 2. Did you evaluated or made your thougts about Kotlin/multiplatform sharable modules ?

[Madalin Valceleanu]

1. Of course, you can check the buildSrc/commons/kotlin-library.gradle.kts is a base to create such modules. But for the moment isn’t being used.

[Madalin Valceleanu]

2. I’m not sure if you refer about share/reuse modules, and please correct me. But the idea is that the :commons module have reusable logic and share it with the every feature with the reason of not duplicating code and making the project more maintainable.

[Michal Harakal]

Exactly its about code sharing, to avoid code duplication, but not only between apps but also between platforms. I have to study your repo more deeper.

[Michal Harakal]

FYI, I have run gradle script by Jake from his SdkSearch project <https://github.com/JakeWharton/SdkSearch/blob/master/gradle/projectDependencyGraph.gradle> and result is quite interesting

[Michal Harakal]

Im not sure if arrows in both direction are right for feature module. I've expected them to go only in one direction.

[Madalin Valceleanu]

Wow @Michal Harakal that was a very nice graph, I appreciate your dedicated time on make this and encourage you to post a PR to add it on the readme of project 🙂 (if you want). Basically the relationship between app -> features is established indirectly by dynamicfeature. And is necessary for have access to navigation graph. In the other hand, the features -> app relationship is used for these reasons: 

1). Have access to coreComponent initialised on application. This happens because the AppComponent depends on CoreComponent.
2). The app defines the styles, this way you could easily have 2 applications with different styles.

[Madalin Valceleanu]

But of course is not the only approach, and is possible to study different one looking pro and cons

[Madalin Valceleanu]

The cyclic dependencies cannot exist, that is why the relationship that establishes dynamic-features is different allowing you to have this graph

[Michal Harakal]

I am not sure if it is what you have expected, but at least we can start work with https://github.com/VMadalin/kotlin-sample-app/pull/1