DEV Community: Madalin Valceleanu

📚 Android Components Architecture in a Modular Word

Madalin Valceleanu — Sun, 08 Dec 2019 16:51:23 +0000

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 Kotlin as an official Android programming language impulse via a series of community-led events like Kotlin/Everywhere and programmers Udacity courses Kotlin Bootcamp. 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.

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 Android Jetpack 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 Modern Android Development.

Android Architecture Components 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.

Modular Android App Architecture presented from Yigit Boyar and Florina Muntenescu in Google I/O'19, is a software design technique to separate functionality into independent, interchangeable modules so that each contains everything necessary to execute a specific functionality.
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.

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 Navigation component to manage fragment operations.
Android architecture components, part of Android Jetpack forgive 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.

The project presents a modern, 2019 approach to Android application development using Kotlin and latest 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:

:app depends on :core and indirectly depends on :features by dynamic-features.
:features modules depend on :commons, :core, :app and some specific utils:library that will use.
:core and :commons only depends on possible utils on :libraries.
:libraries don't have any dependency.

App module

The :app module is a com.android.application, which is needed to create the App Bundle. It is also responsible for initiating the dependency graph, play core and other project global libraries, differentiating especially between different app environments.

Core module

The :core module is a com.android.library for serving network requests or accessing to the DDBB. Providing the data source for the many features that require it.

Features modules

The :features module are a com.android.dynamic-feature 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.

Commons modules

The :commons modules are a com.android.library 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.

Libraries modules

The :libraries modules are a com.android.library, basically contains different utilities that can be used by the different modules.

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:

The following android-dynamic-feature.gradle.kts is applied to every feature module with the following line:

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 doesn't support multiple back-stack for the moment. Exist different workarounds but not officially solution to this. (issue)
Robolectric isn't compatible with dynamic-features modules for the moment. Test on dynamic-feature throws the following exception. The same test but under android-library , works correctly. (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

MockK with LiveData dependency throws an exception when trying to obtain value. (issue). The workaround is to use mockito for the moment.

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:

iosched (by google) - official Android application from google IO 2019.
plaid (by android) - app which provides design news & inspiration, being an example of implementing material design.
sunflower (by android) - a gardening app illustrating Android development best practices with Android Jetpack.
architecture-components-samples (by android) - collection of samples for Android Architecture Components.
architecture-sample (by android) - collection of samples to discuss and showcase different architectural tools and patterns for Android apps.
android-clean-architecture-boilerplate (by bufferapp) - an android boilerplate project using clean architecture
android-kotlin-clean-architecture (by sanogueralorenzo) - android sample Clean Architecture app written in Kotlin.
modularization-example (by JeroenMols) - easy to understand real-life example of a modularized Android app.
lego-catalog (by Eli-Fox) - app illustrating current Android Architecture state using Android development best practices.
tivi (by chrisbanes) - an app which attempts to use the latest cutting edge libraries and tools.
android-showcase (by igorwojda) - app following best practices: Kotlin, coroutines, Clean Architecture, feature modules, tests, MVVM, static analysis.

Articles

A collection of very interesting articles related last android community tendencies and recommendations for start to take in consideration for your current/next project:

Libraries

The open-source community create and maintains tons of awesome libraries making your job more easy, giving the opportunity to use them in your developments. Here are a very important collection of them:

awesome-android-ui - collection list of awesome Android UI/UX libraries.
awesome-android-libraries - collection of awesome Kotlin related stuff.
android-arsenal - android developer portal with tools, libraries, and apps.

Best practices

Avoid reinventing the wheel by following these guidelines:

Codelabs

Google Developers Codelabs provide a guided, tutorial, hands-on coding experience. Most codelabs will step you through the process of building a small application, or adding a new feature to an existing application. They cover a wide range of android concepts to learn and practice:

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 Clean improves testability and eases future refactoring in case it needs to be shared between multiple user-facing features.

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 modularization 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

Sample Android Components Architecture

Madalin Valceleanu — Tue, 19 Nov 2019 10:05:15 +0000

Sample Project that presents modern, 2019 approach to Android application development using Kotlin, MVVM architecture, single Activity pattern, latest tech-stack: androidx, gradle-dsl, dynamic-features, retrofit, coroutines, live data, room, paging, dagger and more..

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

Tech-stack

This project takes advantage of many popular libraries, plugins and tools of the Android ecosystem. Most of the libraries are in the stable version, unless there is a good reason to use non-stable dependency.

Dependencies

Jetpack:
- Android KTX - provide concise, idiomatic Kotlin to Jetpack and Android platform APIs.
- AndroidX - major improvement to the original Android Support Library, which is no longer maintained.
- Benchmark - handles warmup, measures your code performance, and outputs benchmarking results to the Android Studio console.
- Data Binding - allows you to bind UI components in your layouts to data sources in your app using a declarative format rather than programmatically.
- Lifecycle - perform actions in response to a change in the lifecycle status of another component, such as activities and fragments.
- LiveData - lifecycle-aware, meaning it respects the lifecycle of other app components, such as activities, fragments, or services.
- Navigation - helps you implement navigation, from simple button clicks to more complex patterns, such as app bars and the navigation drawer.
- Paging - helps you load and display small chunks of data at a time. Loading partial data on demand reduces usage of network bandwidth and system resources.
- Room - persistence library provides an abstraction layer over SQLite to allow for more robust database access while harnessing the full power of SQLite.
- ViewModel - designed to store and manage UI-related data in a lifecycle conscious way. The ViewModel class allows data to survive configuration changes such as screen rotations.
Coroutines - managing background threads with simplified code and reducing needs for callbacks.
Dagger2 - dependency injector for replacement all FactoryFactory classes.
Retrofit - type-safe HTTP client.
Glide - image loading and caching library for Android focused on smooth scrolling.
Moshi - makes it easy to parse JSON into Kotlin objects.
Timber - a logger with a small, extensible API which provides utility on top of Android's normal Log class.
Stetho - debug bridge for applications via Chrome Developer Tools.
and more...

Test Dependencies

UIAutomator - a UI testing framework suitable for cross-app functional UI testing across system and installed apps.
Espresso - to write concise, beautiful, and reliable Android UI tests
Robolectric - industry-standard unit testing framework for Android.
JUnit - a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks.
Mockito - most popular Mocking framework for unit tests written in Java.
AndroidX - the androidx test library provides an extensive framework for testing Android apps.
and more...

Plugins

Ktlint - an anti-bikeshedding Kotlin linter with built-in formatter.
Detekt - a static code analysis tool for the Kotlin programming language.
Spotless - a code formatter can do more than just find formatting errors.
Versions - make easy to determine which dependencies have updates.
SafeArgs - generates simple object and builder classes for type-safe navigation and access to any associated arguments.
Jacoco - code coverage library
and more...

Building my smart home

Madalin Valceleanu — Fri, 04 Oct 2019 10:26:58 +0000

In this article that is focused on the entire public, I will explain experiences, anecdotes about a personal project of how I turned my home into smart and how can I also control the different electronic devices, enter in home by phone with a simple gesture or open the building door using a Siri voice command.

Basically the idea was started with an Arduino kit that I had purchased and I had started to fiddle with the different modules joysticks, relays, motors, displays, etc .. So I decided to turn my home into a smart and control it from the phone. Although it could also be integrated with GoogleHome / HomePod, but for the moment I postponed it for another phase.

These have been the objectives of the project that I set before starting:

Power on/off, control the intensity and program the house lights as well the plugs.
Measure the indoor and outdoor temperature to regulate it.
Opening the building door with voice commands via Siri.
Opening the home door via fingerprint and detect its closure. In addition add a button to facilitate opening from inside.
Notification system and historical records of all door activity
Installation of several security measures, to guarantee the integrity of the home.

The advantage of opening the home door from the mobile device apart from providing access and control of who enters and leaves, increases security since many families don’t usually lock the door, just close it using the latch. So it makes the work of thieves more easy and we don’t want that.

To do this, I used the Rasberry Pi a small single-board computer where you would end up connecting and controlling all the devices in the home that you would like to add through the Domoticz automation system.

In the market there are several options when we talk about smart devices of many brands and for all pockets. From a light bulb to cameras, thermostats, refrigerators, etc. At the end anything no matter how small, that can be connected to WiFi/bluetooth is called an IoT device.

However, apart from acquiring some and installing them, they can also be created by oneself depending on the needs we have. In my case I used the ESP8266 chips together with the relay module powered at 5V for example to turn on/off the electrical circuit of a mini water fountain.

Moreover for all the control home temperature, the Node MCU chip has been used for taking measurements every X time interval updating data to Domoticz, which would be able to start up the heating system if is necessary. Also I decided to add a display to visualize temperature and time.

Dashboar

Once all the devices are configured, this would be the Domoticz interface, also accessible from the mobile. Basically from here we can control all connected devices, add, delete and much more. Accessing of course, only from the local network.

In addition we can program each device and add additional logic, for example when it should turn on, off, with specific intensity. Depends on our case we may be interested in one state or another.

In my case as you can see, I have relevant information about the Raspberry Pi, the temperature outside and inside the house. Also some plugs, lights from different rooms or areas of the house.

Also the possibility of enabling/disabling the door mechanism, and some other options.

3D Modeling and Printing

To open the home door, a signal that arrives is not enough. That signal has to launch an action, in this case turn the key, an action that we perform daily. Although I saw some “smart lock” mechanisms, but none fitted with the type of my door.

Moreover who wants a battery-based system? We wouldn’t like him to run out of battery with us outside the home. So the system should be directly connected to the power and only in case of emergency be powered by an electric accumulator.

For do this, it was necessary to begin to take measures and build something from scratch that made it possible to turn the key, taking into account that it is a reinforced door.

After making the plastic structure and the handlebar, I began to design the sustenance of the servo motor. My main intention was to split the key in 2 parts to make all the support more compact, but when I couldn’t do it, I decided to leave the idea. There was also the possibility of making a gear system but taking into account the durability that this required and the turning force I decided to opt for something more simple. I started to design the 3D pieces and then print them and after some readjusting this is the final result.

These components are accessible and can be downloaded from the website thingiverse.com (website dedicated to the sharing of user-created digital design files).

Assemble

The assemble may take a long time but we don’t want to see the cables hanging because apart from being unsightly can cause greater consequences such as short circuits. To ensure that doesn’t happen, we have to use a property cable holding.

This would be the result in my case, trying to make the cables barely notice even though they travel through the door frame until they reach the lock.

At the same time, a button can be seen halfway up the door, it is the DashButton he has the responsibility to open the door from inside in a very simple way.

Electrical Circuit

Once seen the assemble part I will explain the components that form it, as well as the connection with the Raspberry Pi. To be able to build it, I perform different proof of concept on a small scale, testing different configurations before making the final assembly.

This circuit could be perfectly soldered instead of a breadboard, although it can always be done at another step.

These are the different components used for its construction:

1x Servo Motor: Whose function is to turn the key to open and close the door.
1x Power supply: 9V DC current supplied to the servo motor for proper operation.
1x Magnetic Switch: Detects when the door closes and send the command to the servo to turn the key.
2x Relays: One responsible for closing the intercom button and the other to power the servo only when it required.
2x Transistors NPN: Solving common Raspberry Pi problem of stepping up
3.3 GPIO to 5V for power the relay.

This sketch is accessible and can be downloaded from the website fritzing.com (open-source hardware initiative that makes electronics accessible as a creative material for anyone).

Mobile Application

To maximize the security for all entire engine, I decided to create an application where all the information passed through my own server, in order to register and control all the traffic, as well the access, instead of using Domoticz for this critical part. I used React-Native framework for this development.

The application is not public and is completely for internal use, consisting of the following functionalities:

Fingerprint scanner when trying to launch an action
Add Siri shortcut command only available for the building door
Notifications and alerts system

Demo

The door opening engine has gone through several phases throughout the development from alpha versions, to the current one, paying special attention to security and giving stability to work properly. Since we don’t want the engine to stop responding or fail. So today and with all the members of the family using daily the engine has been functioning correctly for more than a month.

Here is the demo of how it works:

Basically the intercom system keeps the building door opened for a few seconds after receiving the action sended from Siri command, enough to be able to enter from the outside. This action is received by the Raspberry Pi that closes the intercom system button circuit through the relay, executing the same logic as if we had pressed it.

On the other hand, the action of opening the reinforced door can only be released by fingerprint and the door will remain open until the magnetic switch detects the closure of the door, as can be seen.

Technologies and libraries

In terms of technologies used in the project, the server and the Raspberry Pi running in nodeJS. Using SSE (Server Send Events) for such communication, together with AWS Lambdas for the execution of different actions.

Without forgetting the PM2 (Process Manager2) production runtime and process manager to allow to keep applications alive forever, to reload them without downtime and facilitate common DevOps tasks.

To control the GPIO (General Purpose Input Output) have used node library pigpio, a wrapper for the pigpio C library. Although other alternatives like johnny-five used for IoT and Robotics programming.

The mobile application use a specific npm libraries for the following features:

Fingerprint scanner feature: https://www.npmjs.com/package/react-native-fingerprint-scanner
Siri commands feature: https://www.npmjs.com/package/react-native-siri-shortcut

The driver control of the different microchips used for ESP8266 and Node MCU in the assembly, as well as the different device modules connected to them, such as the temperature and humidity sensor (DTH11), 4-digit display (TM1637), relay module and others, have used with specific libraries recommended by the manufacturer that some of them can be found here.

Software

To build the different parts of the project such as the system of monitoring and devices controller, 3D modeling and printing, the design and programming the circuit, I have been used different third-party software like:

Automation System: Domoticz
Electronic prototyping: Arduino, Fritzing
3D Printing: Ultimaker Cura, Simplify3D
3D Modeling: Fusion360, SketchUp

Summary

Nowadays more and more people talking about smart home, companies are involve their efforts to conquer a growing market and makes people life easier. For this purpose they design and sell many kinds of devices and kits like sensors, controllers, lights, switches and more .. So everyone could make their own smart home and control it by their phone, voice and gestures.

Think about having the possibility of scheduling the temperature before arriving at home, being able to monitor your home through an installed security camera, controlling the different electronic devices by voice commands, lifting the blinds at the morning automatically and why not, enter in your home without keys only from mobile phone.

Although the possibilities are endless as one wants. The technology is available to be used to facilitate our lives.

Support me:

Thanks for your time and reading.

V.Madalin

Building my smart home

Madalin Valceleanu — Fri, 04 Oct 2019 06:55:28 +0000

I explain experiences, anecdotes about a personal project of how I turned my home into smart and how can I also control the different electronic devices, enter in home by phone with a simple gesture or open the building door using a Siri voice command.

https://medium.com/hackernoon/my-smart-home-2bfc9da635c1