Github Search

An Android application to search for Github users. The application allows user to search for Github users. The application consumes data from the Github API

Minimum Api Level : 21 compileSdkVersion : 30

Build System : Gradle

Table of Contents

• Architecture
• Libraries
• Solution
• Testing
• Organisation

Architecture

Since the application is expected to scale with multiple developers working on it, I used the Clean architectural principles to build the application. I choose this architecture because it fosters better separation of concerns and testability.

The Application is split into a three layer architecture:

• Data
• Domain
• Presentation

Data

The data layer handles the business logic and provides data from the Github API. This layer uses the Repository pattern to fetch data from various data sources which in this case is the Github API.

Domain

The domain layer contains the application specifics logic. It contains interactors/use cases that expose the actions that can be performed in the application.

The UseCases use a BaseUseCase interface that defines the parameters its taking in and output and also handles running the UseCases in a background thread leveraging Kotlin Coroutines.

Presentation

I used the MVVM pattern for the presentation layer. The Model essentially exposes the various states the view can be in. The ViewModel handles the UI logic and provides data via Android architectural component LiveData to the view. The ViewModel talks to the domain layer with the individual use cases. Jetpack's Data binding is used to bind the data declaratively to the views.

Libraries

Libraries used in the application are:

• Jetpack
  • Viewmodel - Manage UI related data in a lifecycle conscious way and act as a channel between use cases and UI.
  • Data Binding - support library that allows binding of UI components in layouts to data sources, binds character details and search results to UI.
  • LiveData - Provides an observable data holder class.
• Retrofit - type safe http client and supports coroutines out of the box.
• Shimmer - Shimmer provides an easy way to add a shimmer effect to views in the application.
• Moshi - JSON Parser, used to parse requests on the data layer for Entities and understands Kotlin non-nullable and default parameters.
• okhttp-logging-interceptor - logs HTTP request and response data.
• kotlinx.coroutines - Library Support for coroutines. I used this for asynchronous programming in order to obtain data from the network as well as the database.
• Coil - This was used for loading user avatars in the adapter.
• JUnit - This was used for unit testing the repository, the use cases and the ViewModels.
• Mockk This is a mocking library for Kotlin. I used it to provide test doubles during testing.
• Truth - Assertions Library, provides readability as far as assertions are concerned.
• Hilt - Dependency injection plays a central role in the architectural pattern used. For this reason I have chosen Hilt which is built on top of the battle tested DI framework - Dagger 2.

Solution

In general, any particular flow can be said to follow the steps below:

• The view sends an action to the ViewModel
• The ViewModel reaches out to the UseCase/Interactor
• The UseCase via an abstraction layer reaches out to the repository
• The repository decides where to get the data from and returns (mapped to domain representation) either a success or a failure via a Sealed Either class.
• The UseCase gets the returned value and hand it over to the ViewModel
• The ViewModel maps the returned value to the presentation object.
• Finally, the ViewModel creates a view to model the state of the view and hand it over the view leveraging DataBinding.

Testing

The different layer has various test cases.

The data layer has tests for the repository. To test the repository, test doubles were provided for the API service.

The UseCases were also tested by ensuring the UseCases called the right repository methods.

The presentation layer also has unit tests for the viewmodels.

Organisation

I decided to organize my code based on features. Since many developers are expected to work on the project, developers can easily spot the folder to work on based on feature. This can also potentially reduce merge conflicts. It also makes it easy for new developers to come on board and if we want, we can easily have developers dedicated to different features of the application.