Why :feature :core as a modules ?

[shashi-appgolive]

Some question,

• why do we have to create :feature :core as a modules is it to just hold the modules with related responsibilities or does it have any advantage creating as modules?

• alias(libs.plugins.nowinandroid.android.feature) 
  

nowinandroid-android-feature = { id = "nowinandroid.android.feature" }
nowinandroid-android-library = { id = "nowinandroid.android.library" }

alias is added in all the feature modules what is the purpose of adding custom plugin ?

• :features has respective feature module which has UI and ViewModels, will that be a good practice to bundle the UI+View along with core modules for the respective feature ?

• In the project seems like no feature module is talking other module or launching other composable example : BookMarksScreen -> TopicScreen. Which is avoiding a circular dependency. If we have to Navigate to as such One module Screen to other module Screen what is the best way? Giving callBack function to NavPath or is there any better approach?

• If providing callback is the approach if we have activities to navigate internally, how to do we tackle Example : If we have to launch TopicScreenActivity ?

• 

This is dependency graph created for the project, what is the center point could be which all are connected to ?

[dturner]

why do we have to create :feature :core as a modules is it to just hold the modules with related responsibilities or does it have any advantage creating as modules?

There are many benefits to modularization, as explained here: https://github.com/android/nowinandroid/blob/main/docs/ModularizationLearningJourney.md

alias is added in all the feature modules what is the purpose of adding custom plugin ?

For type safety (original PR is here, and I also had the same question as you)

:features has respective feature module which has UI and ViewModels, will that be a good practice to bundle the UI+View along with core modules for the respective feature ?

I'm not sure what you mean by "bundle". The :app module pulls in all the feature modules required to create the app, and sets up navigation between them. You can see that in NiaNavHost. The feature modules depend on the core modules.

In the project seems like no feature module is talking other module or launching other composable example : BookMarksScreen -> TopicScreen. Which is avoiding a circular dependency. If we have to Navigate to as such One module Screen to other module Screen what is the best way? Giving callBack function to NavPath or is there any better approach?

I think this is answered above.

If providing callback is the approach if we have activities to navigate internally, how to do we tackle Example : If we have to launch TopicScreenActivity ?

You can use Intents for this. Store the destination data within the intent, then have a handler in the app or the default/home feature module that handles the navigation. In Now in Android we do this for notifications using deep links inside an intent. This is handled by the :feature:foryou module (example code).

This is dependency graph created for the project, what is the center point could be which all are connected to ?

Your dependency graph is pretty confusing, how did you generate it? We have dependency graphs already generated for each module. Here's the one for the :app module.

[shashi-appgolive]

Thanks @dturner