Marvel kotlin sample application using android components architecture in a modular project Over years Android architecture evolved to support production-quality apps on any scale focused on helping developers to design robust, testable, and maintainable apps. For that Google has promoted in the last years as an official Android programming language impulse via a series of community-led events like and programmers Udacity courses . And it is not for less since the advantages are endless with respect to Java offering modern statically typed programming language that will boost your productivity and increase your developer happiness. Kotlin Kotlin/Everywhere Kotlin Bootcamp But first of all, if you want to check directly the project before continuing reading the introduction, you can do by accessing the following link: https://github.com/VMadalin/kotlin-sample-app The programming paradigm in android has seen a drastic turn with the introduction of a suite of libraries, tools, and guidance to help developers write high-quality apps easier. These components help you to follow best practices, free you from writing boilerplate code, and simplify complex tasks. That has ended up giving rise to what is known today as . Android Jetpack Modern Android Development are part of Jetpack and are a collection of libraries that help you design robust, testable, and maintainable apps. Start with classes for managing your UI component lifecycle and handling data persistence. Android Architecture Components presented from and in , is a software design technique to so that each contains everything necessary to execute a specific functionality. Modular Android App Architecture Yigit Boyar Florina Muntenescu Google I/O’19 separate functionality into independent, interchangeable modules The below diagram demonstrates how would an application that uses this software design technique, although if you want to see more, I recommend the following . link Modularized app with multiple independent features what share or not the same libraries. Yet when it comes to combining all architecture puzzles together into simple client application it is difficult to find open-sourced app sample to follow. For this reason, I decided to build one based, apply and strictly complies with each of the following 5 points: A single-activity architecture, using the to manage fragment operations. Navigation component , part of Android Jetpack forgive to project a robust design, testable and maintainable. Android architecture components Pattern (MVVM) facilitating of development of the graphical user interface. Model-View-ViewModel separation design principles intended to make software designs more understandable, flexible and maintainable. S.O.L.I.D allows being developed features in isolation, independently from other features.App interaction Modular app architecture The project presents a modern, 2019 approach to application development using and latest . Android Kotlin tech-stack The goal of the project is to demonstrate best practices, provide a set of guidelines, modular application, scalable, maintainable and testable. This application may look simple, but it has all of these small details that will set the rock-solid foundation of the larger app suitable for bigger teams and long application lifecycle management. Application structure One of the key benefits of modularization architecture is supposed to be clear navigation throughout the app and source code. Looking at the root folder of the project, the following structure becomes clear: Interaction between modules Between the modules is established a dependency relationship that allows us to make an API request, access to DDBB or use a certain initialized library. Reusing the code in this way and avoiding duplicating. The below graph shows the app dependency between modules: depends on and indirectly depends on by . :app :core :features dynamic-features modules depend on , and some specific utils that will use. :features :commons :core, :app :library and only depends on possible utils on . :core :commons :libraries don’t have any dependency. :libraries App module The module is a , which is needed to create the . It is also responsible for initiating the , and other project global libraries, differentiating especially between different app environments. :app com.android.application App Bundle dependency graph play core Core module The module is a for serving network requests or accessing to the DDBB. Providing the data source for the many features that require it. :core com.android.library Features modules The module are a is essentially a gradle module which can be downloaded independently from the base application module. It can hold code and resources and include dependencies, just like any other gradle module. :features com.android.dynamic-feature Commons modules The modules are a only contains code and resources which are shared between feature modules. Reusing this way layouts, views, and other components in the different features modules, without the need to duplicate code. :commons com.android.library Libraries modules The modules are a , basically contains different utilities that can be used by the different modules. :libraries com.android.library Architecture components Ideally, ViewModels shouldn’t know anything about Android. This improves testability, leak safety and modularity. ViewModels have different scopes than activities or fragments. While a ViewModel is alive and running, an activity can be in any of its lifecycle states. Activities and fragments can be destroyed and created again while the ViewModel is unaware. Passing a reference of the View (activity or fragment) to the ViewModel is a serious risk. Let's assume the ViewModel requests data from the network and the data comes back sometime later. At that moment, the View reference might be destroyed or might be an old activity that is no longer visible, generating a memory leak and, possibly, a crash. The communication between the different layers follows the above diagram using the reactive paradigm, observing changes on components without the need of callbacks avoiding leaks and edge cases related to them. Configuration files With App Modularization we want to gain fine-grained dependency control but we also need to make sure we don’t end up maintaining multiple configuration files. For that we have the following common configuration files: commons/android-dynamic-feature.gradle.kts commons/android-library.gradle.kts commons/kotlin-library.gradle.kts The following is applied to every feature module with the following line: android-dynamic-feature.gradle.kts plugins {
    id( )
} "commons.android-dynamic-feature" Things to consider Of course, nothing is perfect, especially if it has recently come out. Here are some issues what I found during development: Navigation component don’t support multiple back-stack for the moment. Exist different but not officially solution to this. ( ) workarounds issue Robolectric isn’t compatible with modules for the moment. Test on throws the following exception. The same test but under , works correctly. ( ) dynamic-features dynamic-feature android-library issue java.lang.RuntimeException:java.lang.UnsupportedOperationException: libraries not supported yet Roboelectric throw the following exception on testing apps with data-binding in module. ( ) issue java.lang.NoClassDefFoundError:androidx/databinding/DataBinderMapperImpl with LiveData dependency throws exception when try to obtain value. ( ). The workaround is to use mockito for the moment. MockK issue java.lang.ClassCastException:java.lang.Object cannot be cast to java.lang.String Additional Resources - Projects This is project is a sample, to inspire you and should handle most of the common cases, but obviously not all. If you need to take a look at additional resources to find solutions for your project, visit these interesting projects: (by ) — official Android application from google IO 2019. iosched google (by ) — app which provides design news & inspiration, being an example of implementing material design. plaid android (by ) — a gardening app illustrating Android development best practices with Android Jetpack. sunflower android (by ) — collection of samples for Android Architecture Components. architecture-components-samples android (by ) — collection of samples to discuss and showcase different architectural tools and patterns for Android apps. architecture-sample android (by ) — an android boilerplate project using clean architecture android-clean-architecture-boilerplate bufferapp (by ) — android sample Clean Architecture app written in Kotlin. android-kotlin-clean-architecture sanogueralorenzo (by ) — easy to understand real-life example of a modularized Android app. modularization-example JeroenMols (by ) — app illustrating current Android Architecture state using Android development best practices. lego-catalog Eli-Fox (by ) — an app which attempts to use the latest cutting edge libraries and tools. tivi chrisbanes (by ) — app following best practices: Kotlin, coroutines, Clean Architecture, feature modules, tests, MVVM, static analysis. android-showcase igorwojda - Articles A collection of very interesting articles related to last android community tendencies and recommendations for starting to take in consideration for your current/next project: Transform monolith to modularization application Using the Navigation Component in a Modular World Dependency injection in a multi module project ViewModels and LiveData: Patterns + AntiPatterns Dynamic feature and regular modules using Dagger2 Android Architecture starring Kotlin Coroutines, Jetpack (MVVM, Room, Paging), Retrofit and Dagger 2 Gradle dependency management with Kotlin (buildSrc) Best coding practices, tips and more for Android - Libraries The open-source community create and maintains tons of awesome libraries making your job easier, giving the opportunity to use them in your developments. Here is a very important collection of them: — collection list of awesome Android UI/UX libraries. awesome-android-ui — a collection of awesome Kotlin related stuff. awesome-android-libraries — android developer portal with tools, libraries, and apps.- Best practices android-arsenal Avoid reinventing the wheel by following these guidelines: Google best practices Android development best practices - Summary There are certain benefits in writing or migrating to Modular App and using Architecture Components with them. Faster build times. Fine-grained dependency control. Improve reusability across other apps.Improves the ownership & the quality of the codebase. Stricter boundaries when compared to packages. Encourages Open Source of the newly created libraries. Makes Instant Apps & Dynamic Features possible (improving discoverability). Remember, keeping modules improves testability and eases future refactoring in case it needs to be shared between multiple user-facing features. Clean The aim of this article was to provide a brief overview of how to combining all architecture puzzles together into your current/next project.  If you have any questions, improvements, recommendations about modularisation and architecture components please add your response 🙂. The full open-source code can be found on GitHub: https://github.com/VMadalin/kotlin-sample-app Thanks for your time and reading. V.Madalin

Too Long; Didn't Read

Making security fun one episode at a time

📚 Android Components Architecture in a Modular Word

Too Long; Didn't Read

Madalin Valceleanu

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

📚 Android Components Architecture in a Modular Word

Too Long; Didn't Read

Madalin Valceleanu

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES