in Android is responsible for making network requests, handling responses from a remote data
source, and supplying data to other modules.
## Types of modules in Now in Android
![Diagram showing types of modules and their dependencies in Now in Android](images/modularization-graph.png "Diagram showing types of modules and their dependencies in Now in Android")
**Top tip**: A module graph (shown above) can be useful during modularization planning for
visualizing dependencies between modules.
The Now in Android app contains the following types of modules:
* The `app` module - contains app level and scaffolding classes that bind the rest of the codebase,
such as `MainActivity`, `NiaApp` and app-level controlled navigation. A good example of this is
the navigation setup through `NiaNavHost` and the bottom navigation bar setup
through `NiaTopLevelNavigation`. The `app` module depends on all `feature` modules and
<td>Functionality associated with a specific feature or user journey. Typically contains UI components and ViewModels which read data from other modules.<br>
<li><ahref="https://github.com/android/nowinandroid/tree/main/feature/author"><code>feature:author</code></a> displays information about an author on the AuthorScreen.</li>
<li><ahref="https://github.com/android/nowinandroid/tree/main/feature/foryou"><code>feature:foryou</code></a> which displays the user's news feed, and onboarding during first run, on the For You screen.</li>
<td>Navigation dependencies and shared navigation classes.
</td>
<td><code>NiaNavigationDestination</code>
</td>
</tr>
</table>
## Modularization in Now in Android
Our modularization approach was defined taking into account the “Now in Android” project roadmap, upcoming work and new features. Additionally, our aim this time around was to find the right balance between overmodularizing a relatively small app and using this opportunity to showcase a modularization pattern fit for a much larger codebase, closer to real world apps in production environments.
This approach was discussed with the Android community, and evolved taking their feedback into account. With modularization however, there isn’t one right answer that makes all others wrong. Ultimately, there are many ways and approaches to modularizing an app and rarely does one approach fit all purposes, codebases and team preferences. This is why planning beforehand and taking into account all goals, problems you’re trying to solve, future work and predicting potential stepping stones are all crucial steps for defining the best fit structure under your own, unique circumstances. Developers can benefit from a brainstorming session to draw out a graph of modules and dependencies to visualize and plan this better.
Our approach is such an example - we don’t expect it to be an unchangeable structure applicable to all cases, and in fact, it could evolve and change in the future. It’s a general guideline we found to be the best fit for our project and offer it as one example you can further modify, expand and build on top of. One way of doing this would be to increase the granularity of the codebase even more. Granularity is the extent to which your codebase is composed of modules. If your data layer is small, it’s fine to keep it in a single module. But once the number of repositories and data sources starts to grow, it might be worth considering splitting them into separate modules.
We are also always open to your constructive feedback - learning from the community and exchanging ideas is one of the key elements to improving our guidance.