droid-pure-kotlin-application GitHub Details, Stars and Alternatives | OpenRepoFinder
devrath / repository
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
A transparent discovery signal based on current public GitHub metadata.
Recent activity35% weight
30
Community adoption25% weight
23
Maintenance state20% weight
100
License clarity10% weight
100
Project information10% weight
75
This score does not audit code, security, maintainers, documentation quality, or suitability. Verify the repository and its current documentation before adoption.
README preview
droid-pure-kotlin-application 🧞
ALGORITHMICALLY RELATED
Similar Open-Source Projects
Selected from shared topics, language and repository description—not editorial ratings.
: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.
: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.
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
• 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 d
