Welcome new Android components and architecture

[davigonz]

Android is getting more mature and modern and it would be great to start using some of the next technologies to make the ownCloud Android app more robust, testable and future-proof:

• Android architecture components
• Kotlin

Besides, we will modularize the app in different layers

You can find all the sections below more widely describe in:

• Re-Architecting the ownCloud App for Android blogpost => https://owncloud.org/news/re-architecting-the-owncloud-app-for-android/
• oC Conference talk, from 4:49:10 => https://www.youtube.com/watch?v=iCWvFj94zAI&t=17817s

From MVC to MVVM + Android arch components

Modularization with layers approach

• 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.

• Key points:

  • Domain should not depend on data layer directly, use repository interfaces created in domain layer.

• I/0 '19 talk: https://youtu.be/PZBg5DIzNww

New error and data handling

• RemoteOperationResult object will not longer appear above data layer, the remote datasources will retrieve data or throw new exceptions to upper layers.
• These new exceptions will be encapsulated in a UseCaseResult object in domain layer.
• Datasources should retrieve domain model objects, transforming them from data model objects. Example: Data layer working with ShareEntity and transforming it to Share before pushing it to upper layers.
• ViewModels will handle UseCaseResult objects and transform the information contained there in new UIResult objects.

Dependency graph

I've found an open source tool called Apk dependency graph that could help us to follow the decoupling process.

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.

Initial tasks

• Update Gradle + support for Android Studio 3.2.1: Android Studio 3.2.1 + Gradle update  #2327

• Remove Eclipse structure: General project structure #2044

• Architecture research:

  • SOLID https://stackify.com/solid-design-principles/
  • Read documentation and try some basic examples with new android components and Kotlin integration.

• Clean up + refactors, keep working on Cleanup project #2750 or even Possible Code refactorings #2153

• Define lint policies and coding convention and publish them for community https://kotlinlang.org/docs/reference/coding-conventions.html

  • Codestyle App PR: Code style #2447
  • CodeStyle Library PR: Codestyle android-library#224
  • Kotlin code style
  • Automating code review tasks: https://blog.bitrise.io/automating-code-review-tasks-for-multi-module-android-projects

• Start implementation, defining different use cases, diagrams and using tests (unit, integration, UI). Have a look at USE CASES section.

• Consider using paging to show lots of files.

• Use current RemoteOperationResult objects or opt for a new exceptions mechanism.

CC / @jesmrec @michaelstingl

Issues to have a look at

#1447

Code enhancements

• Use DownloadManager to perform downloads: https://developer.android.com/reference/android/app/DownloadManager
• Use Android KTX to ease SharedPreferences handling: https://developer.android.com/kotlin/ktx.html
• Use WorkManager to deal with background tasks in an easier way: https://developer.android.com/topic/libraries/architecture/workmanager
• Avoid getting context from MainApp.Companion
• Use GSON or Moshi in library