[New arch] App modularization and decoupling

[davigonz]

The status of the app and its code is a recurrent topic that's been discussed several times. A couple of months ago we started to work on a new architecture that is transforming the app to be more testable, robust and future proof.

Thanks to this new architecture, we should manage to have an app with much less dependencies but sometimes it's not easy to know and control, even less in an app as huge as ownCloud for Android.

So let's go through several solutions to modularize and decouple the app

Modularization with layers approach

• Diagram
  

• Advantages:

  • Scalability: several developers working independently in different modules.
  • Maintainability: gradle can build modules faster since the classes and resources are separated in different modules. CI builds will be accelerated too.
  • Less tests to run when there's a new change: we need to run the tests in the module affected by that change and anything else that depends on it. We do not need to run all the tests if other modules are not impacted by the changes.
  • Reduce dependencies => less coupled code.
  • SWITCH MODULES: if in the future we want an app with a different UI and a different way to handle the information to show, we would just need to replace the :ownCloudApp module. And the same for the rest of modules, if one day we want to handle data differently to the current implementation, replacing the :ownCloudData module should be enough.

• Video: https://youtu.be/PZBg5DIzNww

---

OTHER TOOLS

I've found an open source tool called Apk dependency graph that could help us a lot on this matter.

This is how the dependency graph for the ownCloud Android app looks like, based on New arch - capabilities branch (I put it live in https://davigonz.github.io/oCAndroidDependencyGraph/ so everyone can play with it) :

Above we can notice some parts of new architecture (OCShareRepository, OCShareViewModel, OCCapabilityRepository, OCCapabilityViewModel...) along with old code.

And below there's an example of a good architecture with low class coupling:

Taking into account this diagram while working on the new architecture would be great and will allow us to have a higher level vision and complete the whole app transformation process.

So we could use this issue as an epic and create possible changes that come to our mind after having a look at the diagram.

Note: the diagram is currently hosted as a webpage in https://davigonz.github.io/oCAndroidDependencyGraph/ and it uses this repo but we could move it with the rest of ownCloud repositories and even update the diagram via some kind of script included in bitrise (not sure if is possible, need to be checked) and have it updated with new arch changes.

CC / @michaelstingl @jesmrec @abelgardep @hosy

@owncloud/ios-core-developers you have something similar for iOS as well => https://github.com/PaulTaykalo/objc-dependency-visualizer

[michaelstingl]

@davigonz branch with first steps in new architecture isn't merged yet. What does the top image show? Last stable release build? Current master branch? Or the branch with the new architecture?

[davigonz]

branch with first steps in new architecture isn't merged yet. What does the top image show? Last stable release build? Current master branch? Or the branch with the new architecture?

I generated the graph from new arch - capabilities branch to start seeing how the dependencies of the new architecture look like there, along with old code.

Let me update the first comment with this info

[davigonz]

In order to not duplicate information and have the generic architecture details in only one issue, I've just moved what I wrote here to the epic architecture issue. I will close this, please follow up the epic in #2351

The modularization related to shares will be addressed via #2607