Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Android App Modularization

Android App Modularization

How hard can It be modularize the application . I will show basic concept of modularization of your team architecture for your team

ThawZinToe

April 04, 2024
Tweet

More Decks by ThawZinToe

Other Decks in Technology

Transcript

  1. 1 Android App Modularization How hard can It be modularize

    the application Created on 24 May 2023 by Thaw Zin Toe ( Ptut)
  2. 2 Problem 01 Large Code Base Management 02 Longer Build

    Times monolithic codebase harder to navigate and manage 03 Limited Code Reusability Higher code duplication 05 Inefficient Testing Test entire application for small change 06 Difficult in Scaling Complex and riskier Time-consuming for larger codebase 04 Team Collaboration Challenges Lead to merge conflicts and slow down the development process 07 Complicated Dependency Management Managing dependencies is hard
  3. 3 What is Modularization • organizing codebase that separate into

    smaller module • Independent & Clean Purpose • Simplifies project management, improves scalability, and allows for easy addition or removal of features. Android App Modularization • Customizable delivery to users
  4. Pros of Modularization 5 leads to a more efficient, manageable,

    and scalable app development process. It also results in a better user experience, as the app can be smaller, faster, and more stable. Clear Separation Faster Gradle Build Support for Instant App & Dynamic Feature Make parts of your App reusable
  5. Cons of Modularization 6 Be careful planning and effective use

    of tools and practices. Inter-module communication is complex Learning Curve is high A lots of initial setup involved Not Knowing what you’re doing will strongly backfire
  6. 8 Layer - Based Modularization • 3 modules Presentation ,

    Domain and Data. Choosing right modularization architecture • Module are not reusable • Hard for developers to work in isolated environments • Big Module → Slow Build
  7. 9 Feature - Based Modularization • One module per feature

    Choosing right modularization architecture • Size is limited • Developers can work better in isolation • Reusable modules • No clear separation of concerns
  8. 10 Layered - Feature Modularization • Modularization by feature with

    layer sub modules Choosing right modularization architecture • Combines advantages of Layer and feature-based modularization • Developers can work better in isolation • Reusable modules • clear separation of concerns
  9. 14 Data Module • Encapsulate all Data and Business logic

    of a certain domain Type of modules • Expose the repository and datasource as an external API • Hide all implementation details and data source from the outside
  10. 15 Feature Module • Feature-Specific Code and Resources Type of

    Modules • Associated User Interface • Feature Specific Business Logic
  11. 17 App Module • Entry-Point of Application Type of modules

    • target multiple device types, such as Auto, Wear or TV • separate platform specific dependencies
  12. 19 Common & Core Module Type of modules We can

    add third party integration libraries into common module. Eg. for imageLoading , we can use any third-party library Glide, Picasso and Coil etc... If something problem we want to change image library, wechange only in this module.
  13. Avoid Module to Module Communication Avoid 01 Clear Boundaries &

    Plan for Future Define 02 Creating so many small modules & over modularize Avoid 03 Project Document and Communicate Define 04 What we need to care in modularization
  14. Gradle Incremental Build 22 api : dependencies which is exposed

    to other modules that consume your module. implementation: dependencies which is used internally between modules. “