nuhkoca / vivy-challenge

A doctor finder for you!

Vivy

Vivy is a sample app that allows to view list of available doctors for your healthy. This app presents modern approach to Android application development using Kotlin and latest tech-stack.

This project is a hiring task by Vivy. The goal of the project is to demonstrate best practices, provide a set of guidelines, and present modern Android application architecture that is modular, 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.

Table of Contents

• Development
• Design
• Architecture
• Tech-stack
• Author
• License

Development

Environment setup

First off, you require the latest Android Studio 3.6.0 (or newer) to be able to build the app.

Moreover, to sign your app for release, please refer to keystore.properties to find required fields.

# Signing Config
signing.store.password=<look>
signing.key.password=<look>
signing.key.alias=<look>
signing.store.file=<look>

To install the latest release version please respectively;

• cd scripts on the main project
• sh install-release.sh

This will produce a production-ready apk on your device. Please note, this is recommended for the best experience.

Please specify jvm-target as 1.8 following Preferences->Other Settings->Kotlin Compiler->Target JVM Version->1.8, otherwise IDE might behave oddly.

Code style

To maintain the style and quality of the code, are used the bellow static analysis tools. All of them use properly configuration and you find them in the project root directory .{toolName}.

Tools	Config file	Check command	Fix command
detekt	default-detekt-config	./gradlew detekt	-
ktlint	-	./gradlew ktlintCheck	./gradlew ktlintFormat
spotless	/spotless	./gradlew spotlessCheck	./gradlew spotlessApply
lint	/.lint	./gradlew lint	-

All these tools are integrated in pre-commit git hook, in order ensure that all static analysis and tests passes before you can commit your changes. To skip them for specific commit add this option at your git command:

git commit --no-verify

The pre-commit git hooks have exactly the same checks as Github Actions and are defined in this script. This step ensures that all commits comply with the established rules. However the continuous integration will ultimately be validated that the changes are correct.

Design

App support different screen sizes and the content has been adapted to fit for mobile devices and tablets. To do that, it has been created a flexible layout using one or more of the following concepts:

• Use constraintLayout
• Avoid hard-coded layout sizes
• Create alternative layouts
• Use the smallest width qualifier
• Use the available width qualifier
• Add orientation qualifiers

In terms of design has been followed recommendations android material design comprehensive guide for visual, motion, and interaction design across platforms and devices. Granting the project in this way a great user experience (UX) and user interface (UI). For more info about UX best practices visit link.

Moreover, has been implemented support for dark theme with the following benefits:

• Can reduce power usage by a significant amount (depending on the device’s screen technology).
• Improves visibility for users with low vision and those who are sensitive to bright light.
• Makes it easier for anyone to use a device in a low-light environment.

Page	Light Mode	Dark Mode
List
Detail
Search

Architecture

The architecture of the 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 for give to project a robust design, testable and maintainable.
• Pattern Model-View-ViewModel (MVVM) facilitating a 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 to be developed features in isolation, independently from other features.

Modules

Modules are collection of source files and build settings that allow you to divide a project into discrete units of functionality. In this case apart from dividing by functionality/responsibility, existing the following dependence between them:

The above graph shows the app modularisation:

• :app depends on :rules.
• :rules depends on nothing.

App module

The :app module is an com.android.application, which is needed to create the app bundle. It is also responsible for initiating the dependency graph and another project global libraries, differentiating especially between different app environments.

Rules modules

The :rules module is an com.android.library, basically contains lint checks for the entire project.

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. Lets assume the ViewModel requests data from the network and the data comes back some time 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 follow the above diagram using the reactive paradigm, observing changes on components without need of callbacks avoiding leaks, edge cases related with them and single source of truth. Single source of truth provides a crucial opportunity to easily implement some functionalities such as search, filter, etc.

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.
  • Data Binding - allows you to bind UI components in your layouts to data sources in your app using a declarative format rather than programmatically.
  • ViewBinding - allows you to more easily write code that interacts with views.
  • 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.
  • 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.
• Coil - image loading library for Android backed by Kotlin Coroutines.
• Kotlinx Serialization - consists of a compiler plugin, that generates visitor code for serializable classes, runtime library with core serialization API and JSON format, and support libraries with ProtoBuf, CBOR and properties formats.
• Timber - a logger with a small, extensible API which provides utility on top of Android's normal Log class.
• and more...

Test dependencies

• Orchestrator - allows you to run each of your app's tests within its own invocation of Instrumentation.
• Espresso - to write concise, beautiful, and reliable Android UI tests
• JUnit - a simple framework to write repeatable tests. It is an instance of the xUnit architecture for unit testing frameworks.
• JUnit5 - a Gradle plugin that allows for the execution of JUnit 5 tests in Android environments using Android Gradle Plugin 3.5.0 or later.
• Mockk - provides DSL to mock behavior. Built from zero to fit Kotlin language.
• AndroidX - the androidx test library provides an extensive framework for testing Android apps.
• and more...

Plugins

• Ktlint - a pluging that creates convenient tasks in your Gradle project that run ktlint checks or do code auto format.
• 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.
• JUnit5 - a Gradle plugin that allows for the execution of JUnit5 tests in Android environments using Android Gradle Plugin 3.5.0 or later.
• and more...

Author

Nuh Koca

License

• The preview images were created using 'Previewed' at Previewed
• The application icon is a trademark of Vivy

Copyright 2020 Nuh Koca

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.