Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.
Awesome Lists | Featured Topics | Projects
https://github.com/devrath/droid-pure-kotlin-application

☎️ This is a complete Kotlin application built to demonstrate the use of Modern development tools with best practices implementation using multi-module architecture developed using SOLID principles
https://github.com/devrath/droid-pure-kotlin-application
android android-app android-architecture android-development clean-architecture clean-code compose compose-navigation hilt-android jetpack-android kotlin kotlin-android kotlin-coroutines kotlin-dsl modular-architecture mvvm-android mvvm-architecture solid-principles stateflow-android unittesting
Last synced: about 1 month ago
JSON representation
Host: GitHub
URL: https://github.com/devrath/droid-pure-kotlin-application
Owner: devrath
License: apache-2.0
Created: 2022-06-26T07:53:50.000Z (over 2 years ago)
Default Branch: main
Last Pushed: 2023-01-07T08:21:10.000Z (almost 2 years ago)
Last Synced: 2024-08-01T19:51:48.225Z (5 months ago)
Topics: android, android-app, android-architecture, android-development, clean-architecture, clean-code, compose, compose-navigation, hilt-android, jetpack-android, kotlin, kotlin-android, kotlin-coroutines, kotlin-dsl, modular-architecture, mvvm-android, mvvm-architecture, solid-principles, stateflow-android, unittesting
Language: Kotlin
Homepage:
Size: 3.14 MB
Stars: 18
Watchers: 1
Forks: 4
Open Issues: 0
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
- Code of conduct: CODE_OF_CONDUCT.md
Awesome Lists containing this project

awesome-list - devrath/droid-pure-kotlin-application - ☎️ This is a complete Kotlin application built to demonstrate the use of Modern development tools with best practices implementation using multi-module architecture developed using SOLID principles (Kotlin)
README

        

# droid-pure-kotlin-application 🧞‍

[![Android Best practices](https://img.shields.io/badge/Android-best--practices-red)](https://www.android.com/intl/en_in/what-is-android/) [![Kotlin](https://img.shields.io/badge/Kotlin-1.6.10-brightgreen)](https://kotlinlang.org/) [![Coroutines](https://img.shields.io/badge/Coroutines-1.6.0-red)](https://kotlinlang.org/docs/reference/coroutines-overview.html) [![DaggerHilt](https://img.shields.io/badge/DaggerHilt-2.40-blue)](https://developer.android.com/training/dependency-injection/hilt-android) [![Moshi](https://img.shields.io/badge/Moshi-1.13.0-orange)](https://github.com/square/moshi) [![Firebase](https://img.shields.io/badge/Firebase-30.2.0-blueviolet)](https://firebase.google.com/) [![Datastore](https://img.shields.io/badge/Datastore-1.0.0-brightgreen)](https://developer.android.com/topic/libraries/architecture/datastore) [![Timber](https://img.shields.io/badge/Timber-5.0.1-blue)](https://github.com/JakeWharton/timber) [![Orhanobut](https://img.shields.io/badge/orhanobut-2.2.0-lightgrey)](https://github.com/orhanobut/logger) [![Jetpack compose](https://img.shields.io/badge/Jetpack%20Compose-1.1.1-ff69b4)](https://developer.android.com/jetpack/compose/documentation) [![Coil](https://img.shields.io/badge/Coil-1.3.2-008080)](https://github.com/coil-kt/coil) [![Google Material](https://img.shields.io/badge/Google%20Material-1.4.0-3D3635)](https://material.io/develop/android/docs/getting-started) [![Compose Navigation](https://img.shields.io/badge/Compose%20Navigation-2.5.0-7D0541)](https://developer.android.com/guide/navigation/navigation-getting-started) [![Hilt navigation compose](https://img.shields.io/badge/Hilt%20navigation%20compose-1.0.0-DB7093)](https://androidx.tech/artifacts/hilt/hilt-navigation-compose/) [![Activity compose](https://img.shields.io/badge/Activity%20compose-1.5.0-5453A6)](https://androidx.tech/artifacts/activity/activity-compose/) [![Ui tooling preview](https://img.shields.io/badge/Ui%20tooling%20preview-1.1.1-C32148)](https://androidx.tech/artifacts/compose.ui/ui-tooling-preview/) [![Compose ui](https://img.shields.io/badge/Compose%20ui-1.1.1-F6BE00)](https://androidx.tech/artifacts/compose.ui/ui-tooling/) [![Kt lint](https://img.shields.io/badge/Kt%20lint-10.3.0-00FA9A)](https://github.com/pinterest/ktlint) [![Crashlytics](https://img.shields.io/badge/Crashlytics-2.9.1-3B9C9C)](https://firebase.google.com/docs/crashlytics)  

## **`𝙸𝚗𝚝𝚛𝚘𝚍𝚞𝚌𝚝𝚒𝚘𝚗`** 💡

:label: This repository serves as template and demo for building android applications for scale. It is suited for large teams where individuals can work independently on feature wise and layer wise reducing the dependency on each other. It is built with pure kotlin in the project namely `compose` for the `presentation-layer`, `kotlin` for writing the `business-logic`, `kotlin-dsl` for handeling the dependencies. 

:label: `Single activity` architecture where `compose-navigation` is used for navigating between the screens. Also care is taken so that dependencies used in `presentation layer` is not available for `domain layer` and `data layer`. Multimodule architecture used with `reusability` by adhering `SOLID-principles`, also `unit-testing`, `integration-testing` in mind. `Coding for abstraction rather than implementation` is followed in the project that enables `testing` and so that `fakes` can be easily provided for abstractions for testing individual components.

:bricks::bricks: Application is under constant improvement :bricks::bricks:

---

### **`𝙿𝚞𝚛𝚎 𝚔𝚘𝚝𝚕𝚒𝚗`** :card_index_dividers:



:label: Programming language: :heavy_minus_sign: By migrating away from Java and towards kotlin, we can leverage the features like better readability, null saftey, less code, benifits of improved syntax and others. 

:label: Kotlin DSL: :heavy_minus_sign: Earlier we used to use gradle for organizing dependencies. Gradle is written in a groovy programming language. Using the kotlin-DSL, we can organize the dependencies in our project cleaner and in an efficient way. Type safety. This allows better autocompletion which was missing from grovey till now. Code navigation between files becomes easy in Kotlin DSL. Refactoring is much easier. 

:label: Compose: :heavy_minus_sign: Earlier we had xml for building the UI and thus there was one more language hooked to android project. But with the addition of jetpack compose, Even the UI will be built in kotlin language.

---

### **`𝚆𝚑𝚢 𝚌𝚕𝚎𝚊𝚗 𝚊𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎 𝚒𝚜 𝚗𝚎𝚎𝚍𝚎𝚍`** :card_index_dividers:



:label: Scalability: :heavy_minus_sign: When new features are added, using the clean architecture we can easily add the new features and maintain old existing features without breaking them. 

:label: Testability: :heavy_minus_sign: For the new features, its essential we write a code that can be tested for all possible inputs so that once in production we can forecast all possible scenarios and handle them. 

:label: Understandable: :heavy_minus_sign:  Scaling a product with keeping the code testable is good but its also should be in such a way that everyone should understand it and also should easily be modify it.

---

### **`𝚆𝚑𝚢 𝚖𝚞𝚕𝚝𝚒 𝚖𝚘𝚍𝚞𝚕𝚎 𝚒𝚜 𝚞𝚜𝚎𝚍 𝚒𝚗 𝚙𝚛𝚘𝚓𝚎𝚌𝚝`** :card_index_dividers:

:label: A multi module project helps us to segrigate between the layers of code in the project and enforcing strict seperation of concerns. 

:label: When working on a large project this will keep the team to work in layer wise and also feature wise. 

:label: A change in one feature will not affect other features in the project. 

---

### **`𝙳𝚎𝚙𝚎𝚗𝚍𝚎𝚗𝚌𝚢 𝙸𝚗𝚓𝚎𝚌𝚝𝚒𝚘𝚗`** :card_index_dividers:



:label: A Depencency Injection results in a loosely coupled programs. It helps to achieve inversion of control. Inversion of control means a object or function recieves another object or function as a dependency. 

:label: We use hilt that is built on top of dagger tool that generates code on behalf of user and helps to attain the inversion control easily. This is very essential because all the extra code that we need to generate, hilt will do it for us. 

:label: The inversion control becomes even more crucial part of the structure in case of multi module project. 

:label: This also helps in unit testing thte code because, since object is not created and instead provided to a function, we can easily mock it during unit testing. 

---

### **`𝙲𝚘𝚖𝚖𝚞𝚗𝚒𝚌𝚊𝚝𝚒𝚘𝚗 𝚋𝚎𝚝𝚠𝚎𝚎𝚗 𝚝𝚑𝚎 𝚕𝚊𝚢𝚎𝚛𝚜`** :card_index_dividers:



:label: Presentation Layer: :heavy_minus_sign: This layer is the UI layer of the application, It contains composables and view-models. The presentation layer communicates with the domain layer, But the presentation layer is not aware of the data layer.  

:label: Domain Layer: :heavy_minus_sign: This layer contains use cases that contain business logic that perform one functionality each. It also contains the interfaces that communicates with repository which is present in the data layer. 

:label: Data Layer: :heavy_minus_sign: The data layer contains the repositries, The repository can be a preference repository, remote API, local-filesystem etc. The data layer communicates back with the domain layer after fetching the data. 

---

### **`𝙸𝚖𝚙𝚕𝚎𝚖𝚎𝚗𝚝𝚊𝚝𝚒𝚘𝚗 𝚘𝚏 𝚂𝙾𝙻𝙸𝙳 𝚙𝚛𝚒𝚗𝚌𝚒𝚙𝚕𝚎𝚜`** :card_index_dividers:

*This applicaion is developed keeping in mind of clean architecture principles*

| SINGLE RESPONSIBILITY | OPEN CLOSED PRINCIPLE | LISKOV SUBSTITUTION PRINCIPLE | INTERFACE SEGREGATION PRINCIPLE | DEPENDENCY INVERSION PRINCIPLE |

| --------------------- | --------------------- | ----------------------------- | ------------------------------- | ------------------------------ |

| Each class having one responsibility. If there is a change in it, it must be because of only one reason only. If there are two reasons for a class to change, then it violates single responsibility principle. | This indicates that the class is open for extension but closed for modification | When we have a class that is inheriting the parent, the parent class functionality must be replaceable using the child class without modifying the functionality of parent class | Here we should not force a class to do something that it does not want to do, Say a class is implementing interface then it overrides all the functions in it. Now if we don’t want a function of interface to be implemented then we give the default behaviour for the interface and so that it will not force the child class to override that method | This indicates that, a class must depend on abstraction instead of concrete implementation. Say we want a implementation to be used for a class thence need to inject a abstraction for it instead of concrete implementation so that if its implementation changes in future , it must not affect where the abstract version of it is implemented |

---

### **`𝙰𝚍𝚟𝚊𝚗𝚝𝚊𝚐𝚎𝚜 𝚊𝚗𝚍 𝙳𝚒𝚜𝚊𝚍𝚟𝚊𝚗𝚝𝚊𝚐𝚎𝚜 𝚘𝚏 𝚖𝚞𝚕𝚝𝚒 𝚖𝚘𝚍𝚞𝚕𝚎 𝚊𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎`** :card_index_dividers:

#### **`𝙰𝚍𝚟𝚊𝚗𝚝𝚊𝚐𝚎𝚜`**

| `Clear separation` | `Faster build time` |

| ------------ | -------------- |

| • Each of the modules is a library and it can depend on each other 
 • If there is a scenario where one library is not dependent on another, Then they can't access each other 
 • Thus, instead of adding terms of separate packages in the app module, we can enforce strict modularity by modularising it 
 • In a large project and big team we can enforce, who works on which project. Thus one person working on one won't affect other modules| • Using the multi-module we can decrease the build time. When in multi-module each module will use separate threads so build time will decrease since all modules will build independently 
 • Since Gradle needs to build the module that has been changed, it doesn't need to make the modules that have not been changed 
 • Point to note here is that, say there is a root module with few child modules, if the root module changes, all the child modules also need to rebuild 
 • Support for `instant apps` and `dynamic feature module` 
 • Using this we can make parts of our app reusable |

#### **`𝙳𝚒𝚜𝚊𝚍𝚟𝚊𝚗𝚝𝚊𝚐𝚎𝚜`**

 • Lot of initial code 


 • Not knowing what problem it will cause

 

 ---

 

#### **`𝙼𝚅𝚅𝙼 𝚜𝚝𝚛𝚞𝚌𝚝𝚞𝚛𝚎 𝚞𝚜𝚎𝚍 𝚒𝚗 𝚖𝚞𝚕𝚝𝚒-𝚖𝚘𝚍𝚞𝚕𝚎 𝚏𝚘𝚛 𝚌𝚕𝚎𝚊𝚗 𝚊𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎`**
























 

 :label: Implementations of repositories sits in the data layer.


 :label: The Data layer has reference to domain layer, So it can access all the classes from the data layer.


 :label: Presentation layer has reference to the domain layer, so it can access all the classes from the domain layer and not data layer.


 :label: We alwaays inject abstractions to any class instead of concrete implementation.


 :label: Data flows from presentation layer to data layer if data is saved locally or sent to server. In other case the data is retrieved from data layer to presentation layer in case when data is retrieved from server to UI displayed or from data saved locally to UI displayed
 

 

 

### **`𝙿𝚊𝚝𝚝𝚎𝚛𝚗𝚜`** 

- [𝚁𝚎𝚙𝚘𝚜𝚒𝚝𝚘𝚛𝚢 𝙿𝚊𝚝𝚝𝚎𝚛𝚗](https://developer.android.com/jetpack/docs/guide) -

The Repository Pattern is one of the most popular patterns to create an enterprise level application. It restricts us to work directly with the data in the application and creates new layers for database operations, business logic, and the application's UI.

- [𝙾𝚋𝚜𝚎𝚛𝚟𝚎𝚛 𝙿𝚊𝚝𝚝𝚎𝚛𝚗](https://code.tutsplus.com/tutorials/android-design-patterns-the-observer-pattern--cms-28963) - The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.

- [𝚄𝚜𝚎𝙲𝚊𝚜𝚎 𝙿𝚊𝚝𝚝𝚎𝚛𝚗](https://caminao.blog/how-to-implement-symbolic-representations/patterns/functional-patterns/use-case-patterns/) - This pattern means to convert and pass user actions to inner layers of the application.

- [𝚃𝙳𝙳](https://technologyconversations.com/2013/12/20/test-driven-development-tdd-example-walkthrough/) - Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved so that the tests pass.

 

 ---

 

 ## **`𝚃𝚎𝚜𝚝𝚒𝚗𝚐 𝚝𝚑𝚎 𝚌𝚘𝚍𝚎`** :test_tube:

 

 :label: We test the `features` of the code, Each of the `features` contain three layers namely `data`, `domain`, `presentation`. 


 :label: In the `core` layer we can write tests for the `implementation` and `repository` for each of modules.  


 :label: UI tests - `Development in progress`

 

 ## **`𝙿𝚊𝚌𝚔𝚊𝚐𝚎 𝚂𝚝𝚛𝚞𝚌𝚝𝚞𝚛𝚎 𝚒𝚗 𝚝𝚑𝚎 𝚙𝚛𝚘𝚓𝚎𝚌𝚝`** :package:

Project Folder 
    . 
    ├── app 
    │   ├── activity 
    │   ├── view-model 
    |   ├── navigation 
    │   └── application 
    | 
    ├── buildSrc 
    | 
    ├── core 
    │   ├── res 
    │   └── java 
    │       ├── data 
    │       │ 
    │       │    └── repository 
    │       │ 
    │       ├── di 
    │       ├── domain 
    │       │   ├── features 
    │       │   └── models 
    │       │ 
    │       └── platform 
    │           ├── base 
    │           ├── extensions 
    │           └── functional 
    │ 
    │ 
    ├── core-ui 
    │   ├── res 
    │   │   ├── drawable 
    │   │   └── font 
    │   │ 
    │   └── java 
    │       ├── composables 
    │       └── theme 
    │ 
    └── features 
        │ 
        ├── common 
        │   │ 
        │   │ 
        │   ├── common_data 
        │   │   ├── di 
        │   │   ├── repository 
        │   │   └── service 
        │   │ 
        │   │ 
        │   └── common_domain 
        │       ├── di 
        │       ├── repository 
        │       └── usecases 
        │ 
        └── login 
            │ 
            │ 
            ├── login_data 
            │   ├── di 
            │   ├── repository 
            │   └── service 
            │ 
            │ 
            ├── login_domain 
            │   ├── di 
            │   ├── repository 
            │   └── usecases 
            │ 
            │ 
            └── login_presentation 
                ├── states 
                ├── view-composable 
                └── viewmodel

# Root Package # It is the starting point for the application # Entire application has just one activity # This will be the view-model for the single activity # It contains the navigation compose and the routes used in the application # Singleton used at application level # It contains all project dependencies & its version references that can be modified from one place # Module with code that can be re-used in all the modules. This also helps us to manage them easily # String resources used in the project # data layer of the core module ├── implementation                   # contains implementations of the features hosted in core module # contains repository for the features # Hilt dependency injection # Domain layer for all the reusable third party features in project # Contains interface for all the reusable third party features in project # data modules used thorught the project # Can old other miscellaneous things needed in project, some are listed below # Can hold base classes that are used in different features in project # kotlin extensions that can be kept in one place and handeled # Other util functional elements in teh project # Module contains all the UI related things in the project

# Contains all the drawables needed for the project # Place we can store the font files in the project # Here we store the reusable composables used for the project # Contains the theme file used in project # The module contains all the features used in project # sub-module that holds the logic that is re-used in multiple features # sub-module for data # di for current module # repository used for injection # service used in repository # sub-module for domain # di used for having use-case data object instance # interface of the repository # individual logic for domain data # sub-module that contains one feature # sub-module for data # di used to build the module and create instances of service and repository of current module # implementation of the repository # service used in repository # sub-module for domain # di used for having use-case data object instance # interface of the repository # individual logic for domain data # sub-module for presentation # states of the data displayed and view-model # composable representing a screen # view model for the composable

 

## **`𝙲𝚘𝚍𝚎 𝚚𝚞𝚊𝚕𝚒𝚝𝚢`** 📺

  

##### **`Run Kt lint`** 🔧

:label: It is static code analysis tool that is used to analyze the Kotlin code for you. It will check if you have written the code by following the Kotlin code guidelines or not.

```gradle

// To check the list of errors

./gradlew ktlintCheck  

// Try to auto auto format errors

./gradlew ktlintFormat

```

 

 ---

 

## **`𝙷𝚘𝚠 𝚝𝚘 𝚛𝚞𝚗 𝚝𝚑𝚎 𝚜𝚊𝚖𝚙𝚕𝚎 𝚊𝚙𝚙𝚕𝚒𝚌𝚊𝚝𝚒𝚘𝚗`** 👣

:label: Basically You just follow steps to create a firebase account and eanable authentication module, I have summarized some steps below.


:one: Before running the sample application, Please create a account in firebase console.


:two: Now enable the authentication in settings for firebase(This is used during the authentication of login).


:three: Add the google-services.json in the app level of the project that is obtained when creating a project in firebase.
 

:four: Last but not least add your application SHA in your firebase settings.


## **`𝚃𝚎𝚌𝚑 𝚜𝚝𝚊𝚌𝚔`** 🏗️️ 

| What            | How                        |

|----------------	|------------------------------	|

| 🎭 𝚄𝚜𝚎𝚛 𝙸𝚗𝚝𝚎𝚛𝚏𝚊𝚌𝚎 (𝙰𝚗𝚍𝚛𝚘𝚒𝚍)   | [𝙹𝚎𝚝𝚙𝚊𝚌𝚔 𝙲𝚘𝚖𝚙𝚘𝚜𝚎](https://developer.android.com/jetpack/compose)                |

| 🏗 𝙰𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎    | [𝙲𝚕𝚎𝚊𝚗 𝙰𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)                            |

| 💉 𝙳𝙸 (𝙰𝚗𝚍𝚛𝚘𝚒𝚍)                | [𝙷𝚒𝚕𝚝](https://developer.android.com/training/dependency-injection/hilt-android)                        |

| 🌊 𝙰𝚜𝚢𝚗𝚌            | [𝙲𝚘𝚛𝚘𝚞𝚝𝚒𝚗𝚎𝚜](https://kotlinlang.org/docs/coroutines-overview.html) + [Flow](https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-flow/)                |

| 🌐 𝙽𝚎𝚝𝚠𝚘𝚛𝚔𝚒𝚗𝚐        | [𝙵𝚒𝚛𝚎𝚋𝚊𝚜𝚎](https://firebase.google.com/)                        |

## **`𝙲𝚞𝚛𝚛𝚎𝚗𝚝𝚕𝚢 𝚏𝚎𝚊𝚝𝚞𝚛𝚎𝚜 𝚍𝚎𝚟𝚎𝚕𝚘𝚙𝚎𝚍`** 🧰

Demo contains three screen application namely `registration`, `login`, `forgot-password` and external service used here is `firebase`. User can create an account using `registration`. User can login and once login is successful the user details is saved in `data-store` 



 

`Login` | `Registration` | `Forgot Password` |

--- | --- | --- |

 |  | |

 



## **`𝙼𝙰𝙳 𝚂𝚌𝚘𝚛𝚎`** 🎈

![Banner](https://github.com/devrath/droid-pure-kotlin-application/blob/main/assets/MadScore/mad_banner.png)

## **`𝚂𝚞𝚙𝚙𝚘𝚛𝚝`** ☕

If you feel like support me a coffee for my efforts, I would greatly appreciate it.



## **`𝙲𝚘𝚗𝚝𝚛𝚒𝚋𝚞𝚝𝚎`** 🙋‍♂️

Read [contribution guidelines](CONTRIBUTING.md) for more information regarding contribution.

## **`𝙵𝚎𝚎𝚍𝚋𝚊𝚌𝚔`** ✍️ 

Feature requests are always welcome, [File an issue here](https://github.com/devrath/droid-pure-kotlin-application/issues/new).

## **`𝙵𝚒𝚗𝚍 𝚝𝚑𝚒𝚜 𝚙𝚛𝚘𝚓𝚎𝚌𝚝 𝚞𝚜𝚎𝚏𝚞𝚕`** ? ❤️

Support it by clicking the ⭐ button on the upper right of this page. ✌️

## **`𝙻𝚒𝚌𝚎𝚗𝚜𝚎`** ![Licence](https://img.shields.io/github/license/google/docsy) :credit_card:

This project is licensed under the Apache License 2.0 - see the [LICENSE](https://github.com/devrath/droid-pure-kotlin-application/blob/main/LICENSE) file for details