Fragment Inner Class Should Be Static

What is the design logic behind Fragments as static inner classes vs standalone public classes?

This brings me back to square one and I have the question that, well, if the Fragment design has been adopted in order to decouple the code, then why are we marrying the Fragment to the Activity by putting it inside the activity class and not putting them as standalone public classes? Isn't that totally contradicting to the very existence of Fragments?

The main driver for fragments isn't decoupling but rather composition: reusable pieces of user interface that can be easily composed together in different configurations. From composability follows modularity and from it decoupling so yes, decoupling is there but it's not the primary concern.

Read on about fragment design philosophy.

The modularity coin has another side: if two things belong together such as an activity and a fragment that is only used with that activity, they are best kept together and not spread out all over the codebase so they are easier to evolve together. A project structure like in your question where activities and fragments are in separate packages would not really follow this principle.

One commonly seen way to keep fragments in separate classes but close to related activities and such is to use a naming prefix so they sort together in alphabetical lists within the same package: e.g. FooActivity with FooDetailsFragment.

For simple fragments where there isn't that much code and the fragment is only used in one activity, it's perfectly fine to have them as static inner classes in that activity.

Just try to be consistent so other people reading the code can easily find their way around in the codebase and the WTFs/minute code metric is kept low.

Do we still suffer from the memory leak issue mentioned above?

No, the leak applies only to non-static inner classes that hold a reference to the outer class. Package-level classes do not have any outer class to held a reference to.

Since fragments share the hosting activity's lifecycle, leaking the outer object is not really the concern with fragments. It's just that the framework needs to be able to instantiate the fragments without any outer class objects, and static is a requirement for that.

Is there a way where the Fragments stay as an inner class and still be used elsewhere? I might be missing something here as well... so do inform me.

You can refer to public inner classes with the dot notation Outer.Inner in code or Outer$Inner with reflection (e.g. XML files).

While this is technically possible, doing so says you're relying on the internals of a class and that's a design smell. I'd really refer to inner classes in the outer class code itself.

Error: This fragment inner class should be static [ValidFragment]

Thats lint error, you are probably building with gradle, to disable aborting on errors, add:

lintOptions {
    abortOnError false
}

to build.gradle, or better fix problem in code. For more on this particular error read here: Fragment inner class should be static

Is there anything wrong with static field initialised with anonymous inner class?

Best explanation is here:
https://stackoverflow.com/a/27739694/5868421

Anonymous class in static context don't hold a reference to outer object.

---

Related Topics