compose for the
kotlin for writing the
kotlin-dsl for handeling the dependencies.
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
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.
𝚆𝚑𝚢 𝚌𝚕𝚎𝚊𝚗 𝚊𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎 𝚒𝚜 𝚗𝚎𝚎𝚍𝚎𝚍
𝚆𝚑𝚢 𝚖𝚞𝚕𝚝𝚒 𝚖𝚘𝚍𝚞𝚕𝚎 𝚒𝚜 𝚞𝚜𝚎𝚍 𝚒𝚗 𝚙𝚛𝚘𝚓𝚎𝚌𝚝
𝙲𝚘𝚖𝚖𝚞𝚗𝚒𝚌𝚊𝚝𝚒𝚘𝚗 𝚋𝚎𝚝𝚠𝚎𝚎𝚗 𝚝𝚑𝚎 𝚕𝚊𝚢𝚎𝚛𝚜
𝙸𝚖𝚙𝚕𝚎𝚖𝚎𝚗𝚝𝚊𝚝𝚒𝚘𝚗 𝚘𝚏 𝚂𝙾𝙻𝙸𝙳 𝚙𝚛𝚒𝚗𝚌𝚒𝚙𝚕𝚎𝚜
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
• Using this we can make parts of our app reusable
• Lot of initial code
• Not knowing what problem it will cause
𝙼𝚅𝚅𝙼 𝚜𝚝𝚛𝚞𝚌𝚝𝚞𝚛𝚎 𝚞𝚜𝚎𝚍 𝚒𝚗 𝚖𝚞𝚕𝚝𝚒-𝚖𝚘𝚍𝚞𝚕𝚎 𝚏𝚘𝚛 𝚌𝚕𝚎𝚊𝚗 𝚊𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎
𝚃𝚎𝚜𝚝𝚒𝚗𝚐 𝚝𝚑𝚎 𝚌𝚘𝚍𝚎
features of the code, Each of the
features contain three layers namely
core layer we can write tests for the
repository for each of modules.
Development in progress
𝙿𝚊𝚌𝚔𝚊𝚐𝚎 𝚂𝚝𝚛𝚞𝚌𝚝𝚞𝚛𝚎 𝚒𝚗 𝚝𝚑𝚎 𝚙𝚛𝚘𝚓𝚎𝚌𝚝
Project Folder # Root Package . ├── app # It is the starting point for the application │ ├── activity # Entire application has just one activity │ ├── view-model # This will be the view-model for the single activity | ├── navigation # It contains the navigation compose and the routes used in the application │ └── application # Singleton used at application level | ├── buildSrc # It contains all project dependencies & its version references that can be modified from one place | ├── core # Module with code that can be re-used in all the modules. This also helps us to manage them easily │ ├── res # String resources used in the project │ └── java │ ├── data # data layer of the core module │ │ ├── implementation # contains implementations of the features hosted in core module │ │ └── repository # contains repository for the features │ │ │ ├── di # Hilt dependency injection │ ├── domain # Domain layer for all the reusable third party features in project │ │ ├── features # Contains interface for all the reusable third party features in project │ │ └── models # data modules used thorught the project │ │ │ └── platform # Can old other miscellaneous things needed in project, some are listed below │ ├── base # Can hold base classes that are used in different features in project │ ├── extensions # kotlin extensions that can be kept in one place and handeled │ └── functional # Other util functional elements in teh project │ │ ├── core-ui # Module contains all the UI related things in the project │ ├── res │ │ ├── drawable # Contains all the drawables needed for the project │ │ └── font # Place we can store the font files in the project │ │ │ └── java │ ├── composables # Here we store the reusable composables used for the project │ └── theme # Contains the theme file used in project │ └── features # The module contains all the features used in project │ ├── common # sub-module that holds the logic that is re-used in multiple features │ │ │ │ │ ├── common_data # sub-module for data │ │ ├── di # di for current module │ │ ├── repository # repository used for injection │ │ └── service # service used in repository │ │ │ │ │ └── common_domain # sub-module for domain │ ├── di # di used for having use-case data object instance │ ├── repository # interface of the repository │ └── usecases # individual logic for domain data │ └── login # sub-module that contains one feature │ │ ├── login_data # sub-module for data │ ├── di # di used to build the module and create instances of service and repository of current module │ ├── repository # implementation of the repository │ └── service # service used in repository │ │ ├── login_domain # sub-module for domain │ ├── di # di used for having use-case data object instance │ ├── repository # interface of the repository │ └── usecases # individual logic for domain data │ │ └── login_presentation # sub-module for presentation ├── states # states of the data displayed and view-model ├── view-composable # composable representing a screen └── viewmodel # view model for the composable
Run Kt lint
// To check the list of errors ./gradlew ktlintCheck // Try to auto auto format errors ./gradlew ktlintFormat
𝙷𝚘𝚠 𝚝𝚘 𝚛𝚞𝚗 𝚝𝚑𝚎 𝚜𝚊𝚖𝚙𝚕𝚎 𝚊𝚙𝚙𝚕𝚒𝚌𝚊𝚝𝚒𝚘𝚗
||𝙲𝚘𝚛𝚘𝚞𝚝𝚒𝚗𝚎𝚜 + Flow|
𝙲𝚞𝚛𝚛𝚎𝚗𝚝𝚕𝚢 𝚏𝚎𝚊𝚝𝚞𝚛𝚎𝚜 𝚍𝚎𝚟𝚎𝚕𝚘𝚙𝚎𝚍
Demo contains three screen application namely
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
Read contribution guidelines for more information regarding contribution.
Feature requests are always welcome, File an issue here.
𝙵𝚒𝚗𝚍 𝚝𝚑𝚒𝚜 𝚙𝚛𝚘𝚓𝚎𝚌𝚝 𝚞𝚜𝚎𝚏𝚞𝚕 ?
Support it by clicking the
This project is licensed under the Apache License 2.0 - see the LICENSE file for details