0

I'm wondering if it is better to have a Module per Activity than a Module per Fragment? In one of my projects, I have an architecture to have a Module per Fragment because I use Activity just to hold and swap Fragments and nothing more. I only create Presenters and Interactors when I need them, i.e. when Fragment.onCreate() is being called.

But I can see guys are creating Module per Activity in their examples. While the idea to have an independent Module for Activity sounds perfectly reasonable as for me from a modularity perspective, but I still believe creating and keeping all objects (Presenters, Interactors) before you actually need them is not a best idea. You can't also release resources when you don't need them, which you could easily do for Module per Fragment when you just release a scoped graph in Fragment.onDestroy() event.

Eugene
  • 59,186
  • 91
  • 226
  • 333

1 Answers1

0

The examples assume you're working with several activities, each with their own clear purpose and scope. There exists a scope A for the application wide dependencies, and scopes B, C and D for each of the Activity dependencies.

You're basically adding an extra layer to the hierarchy: Application-Activity-Fragment. In that case, since you're working with a single Activity, scope A is roughly the scope for the application and activity dependencies, and B, C and D become Fragment scopes.

So yes, it makes sense to create a module for each Fragment.

nhaarman
  • 98,571
  • 55
  • 246
  • 278
  • My application also consists of several Activities with their clear scope and purpose. I just don't get the purpose of creation and keeping objects unless you really need them (how it goes if you have activity range module), or I'm overconcerned? Meaning, maybe keeping presenters and other objects isn't really a big deal in terms of memory footprint. – Eugene Feb 24 '15 at 20:34
  • I completely agree that you should introduce and instantiate dependencies at the lowest level as possible. – nhaarman Feb 24 '15 at 20:37