Table of Contents

• Pokémon V2
  • Requirements
• App Architecture
  • Model/Entities
  • Data layer
  • Usecases/Interactors
  • Presentation layer
• Getting Started
  • Checkout the Code
  • Major Libraries / Tools
• Setting up Prerequisites
  • Fastlane Setup
• Running Quality Gates and Deployment Commands
  • Linting
  • Testing
    • Local unit tests
    • Instrumented tests
    • Running the Unit Tests
  • Test Coverage
• CI-CD - Github actions

Pokémon V2

Pokémon V2 is simple app to hit the Pokeapi and show a list of pokemons, that shows details when items on the list are tapped (a typical master/detail app).

We'll be using the most viewed section of this API.

Two APIs to consider here:

1- Api to fetch pokemons list https://pokeapi.co/api/v2/pokemon?limit={limit}&offset={offset}

2- API to fetch pokemon details https://pokeapi.co/api/v2/pokemon/{pokemonID}

This is a full RESTful API linked to an extensive database detailing everything about the Pokémon main game series. For more information about this APIs you can check this documentation.

Requirements

• Android Studio
• Java 8 - Ensure JAVA_HOME environment variable is set

App Architecture

This sample follows the clean architecture by Robert C. Martin along with MVVM design pattern.

Model/Entities

The model is the domain object. It represents the actual data and/or information we are dealing with. An example of a model might be a contact (containing name, phone number, address, etc) or the characteristics of a live streaming publishing point.

The key to remember with the model is that it holds the information, but not behaviors or services that manipulate the information. It is not responsible for formatting text to look pretty on the screen, or fetching a list of items from a remote server (in fact, in that list, each item would most likely be a model of its own). Business logic is typically kept separate from the model, and encapsulated in other classes that act on the model.

Data layer

Provides all required data to the repository in form of models/entities.

Remote data source

Manage all server/external API calls.

Local data source

Manage all local data storage: example SQLite implementation, Room, Realm...

Volatile data source

Manage temporary storage.

Repository

The decision maker class when it comes to manage data CRUD operations. Operations can be done in this layer is caching mechanism, manage consecutive api calls etc...

Usecases/Interactors

Represents concepts of the business, information about the current situation and business rules.

Presentation layer

###ViewModel ViewModel responsible for presentation logic. ###View Views can be an android Activities, Fragments or any custom views. This layer does not contain any business logic which is the responsibility of usecase neither UI logic which is the responsibility of ViewModel.

Getting Started

This repository implements the following quality gates:

Build Pipeline

• Static code checks: running lint to check the code for any issues.
• Unit testing: running the unit tests
• UI unit testing: running the AndroidTest along with mockito
• Code coverage: generating code coverage reports using the JaCoCo gradle plugin

These steps can be run manually or using a Continous Integration tool such as Jenkins. This project use Github actions for CI/CD, you can check this documentation for more information.

Checkout the Code

Checkout and run the code

git clone https://github.com/oudaykhaled/Pokemonv2.git
cd pokemonv2

Major Libraries / Tools

Category	Library/Tool	Link
Development	Android - Java	https://developer.android.com/guide/
Build & Dependencies Management	Gradle	https://developer.android.com/studio/build/
Unit Testing	JUnit	https://developer.android.com/training/testing
Code Coverage	JaCoCo	https://docs.gradle.org/current/userguide/jacoco_plugin.html
Static Code Check	Gradle Lint	https://developer.android.com/studio/write/lint
Functional Testing	Espresso	https://developer.android.com/training/testing/espresso
Dependency injection	Hilt	https://developer.android.com/training/dependency-injection/hilt-android
Continous Integration	Github actions	https://docs.github.com/en

Setting up Prerequisites

Fastlane Setup

To setup Fastlane please read the README.md file inside the ./fastlane folder

Running Quality Gates and Deployment Commands

Linting

./gradlew lint

or using Fastlane:

fastlane lint

Linting results are available at pokemonv2/app/build/reports/lint-results.html

Testing

Tests in Android are separated into 2 types:

Local unit tests

Located at pokemonv2/app/src/test/java/ - These are tests that run on your machine’s local Java Virtual Machine (JVM). Use these tests to minimize execution time when your tests have no Android framework dependencies or when you can mock the Android framework dependencies.

Instrumented tests

Located at pokemonv2/app/src/androidTest/java/ - These are tests that run on a hardware device or emulator. These tests have access to Instrumentation APIs, give you access to information such as the Context of the app you are testing, and let you control the app under test from your test code. Use these tests when writing integration and functional UI tests to automate user interaction, or when your tests have Android dependencies that mock objects cannot satisfy.

Running the Unit Tests

Unit testing for Android applications is fully explained in the Android documentation. In this repository, jUnit test case has been written for Presenter

From the commandline run:

./gradlew clean test

or using Fastlane:

fastlane tests

Unit tests results are available at

pokemonv2/app/build/reports/tests/testDebugUnitTest/index.html

From Android Studio

• Right Clicking on the Class and select "Run
• To see the coverage we have t the select "Run with Coverage"

Test Coverage

The test coverage uses the JaCoCo library

From the commandline

./gradlew clean jacocoTestReport

Test coverage results are available at

pokemonv2/app/build/reports/jacoco/jacocoTestReport/html/index.html

• Run the following command from the project root folder

./gradlew --info sonarqube

CI-CD - Github actions

This repo contains a workflows file , which is used to define a declarative pipeline for CI-CD to build the code, run the quality gates, code coverage.

Here is an example structure of the Jenkinsfile declarative pipeline:

name: CI

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Permission
        run: chmod +x gradlew

      - name: Test
        run: ./gradlew test
       
      - name: Lint
        run: ./gradlew lint
       
      - name: Build
        run: ./gradlew build

Below is an illustration of the pipeline that Github actions will execute

Apache License, Version 2.0 http://www.apache.org/licenses/LICENSE-2.0