This app solves the Glovo Android Challenge.

• Setup and run the server
• Checkout this project and edit the server url address in the following line of the app module's build.gradle file: buildConfigField "String", "SERVER_BASE_URL", "\"http://10.0.2.2:3000/\""
• Run the app

This project was organized using the principles of the app modularization by features. Although this approach is not necessary for an app as small as this challenge, it is useful to demonstrate how to structure a project that aims to build a robust and scalable application. This is a very common and good practice to keep different teams working on isolated and decoupled features. This application was divided in two "product features":

• User City: This feature is the responsible for getting the code of the city where the user is located, using two strategies: the current user device location, and the available city picker screen which is displayed to the user when the application starts and cannot be able to fetch the device location.
• Working Area: The main screen of the app, which loads the map of available zones and the details of the city focused on the map.

In addition to these modules, the project contains the following additional ones:

• app: This is the main application module which contains the application class and the navigation logic. The NavigationActivity is the responsible for driving the user through the flow composed by all the product features, and for loading the different features activities.
• base: This is a base module which contains architecture base classes and helpers, which are used by the different product modules.
• networkdatasource: This module contains the network communication logic between each product modules and the server, bringing a common data source class with api call capabilities.

In order to maintain this code decoupled, testable and robust, the architecture of this app was designed using clean architecture. Each Product Feature contains the following layers represented as packages in the src module folder:

• Domain Layer: Contains the business logic of each module, totally independent of the device, the networking data or the ui. Each business logic task is represented as an Use Case.
• Data Layer: Represented by Repositories which have the responsibility to access and get data from the different sources (Device, Cache and Networking).
• Presentation Layer: Layer responsible for displaying the information provided by the business logic layer, using the UI interface. This layer use the Google's architecture components approach to manipulate data between the activities/fragment and the presentation classes (represented by ViewModels).

The communication and transformation of data between different layers was represented by Mapper classes. Each user flow which implements these three layers was developed using async, event-based and reactive programming with RxJava.

All the app component dependencies are injected using Koin, which provides a lightweight and pure Kotlin dependency injection mechanism with glorious support for Android architecture classes such as ViewModels. Each module has an extra package called module who contains the injections of all the dependencies used by this module.

Each module contains a set of unit test classes that intends to test every component of the architecture. These test classes were designed to check the output of the class being tested, using Mockito as a mocking mechanism of their inputs and dependencies.

As specified in the challenge statement, this app represents the available zones of the Glovo service using polygons displayed in the main Google Map screen. In order to avoid overlapped polygons when each city is represented, and also to avoid overlapped polygons between cities (such as Rio de Janeiro Center and North Rio de Janeiro), a polygon combination algorithm was developed using the JTS library. A unit test class with a valid example of this combination can be found here.