Android - Why is using an Interface considered the best practice of communicating between Activity and Fragment?

Question

In this documentation "Communicating with Other Fragments", Google tells us that the best practice for communicating Activity and Fragment is to implement an interface. This interface then can be called by Fragment and to execute necessary behaviour in Activity.

But there's also a hack way to do this. Directly get the Activity by the method "getActivity()" and then we can use all "public method" under it.

This confuse me quite a lot. Cause I couldn't really think of any critical disadvantage of using the hack way to do this.

What the advantage of first approach came up in my head are:

1. I can confine the "resource accessibility" under my Activity. But since the Fragment is able to call "getActivity()", then it can actually access all the "public" method in it. So this can't really convince me.
2. More readable and story-telling in the code. With the first approach, the code tells us that "this Activity only open these specific accessible area for the Fragment". We can know "What inside the Fragment may interfere the Activity" directly by just looking the code in Activity. Or else, we will need to open up the code under Fragment to see what it did.

All right, after I summarise these out, I was a little bit convinced by myself. But frankly, I really want some other solid and must reason for doing this. Any idea or documentation would be really appreciated!!

Answer 1

Above all, the main advantage is modularity of your code. When you directly call your "parent" class from the "child" class, you create a cyclic dependency. This effectively means you cannot replace one, without changing the other. This approach frequently results in spaghetti-code that is difficult to maintain, even harder to extend and nearly impossible to replace without big refactoring efforts.

As for your example: if you call the public methods of your Activity directly from the Fragment, you will not be able to re-use your Fragment in other Activities without implementing hacky solutions (like if(getActivity() instanceof A) {...} else {...}), nor can you swap out your Activity for e.g. a controller-class, or whatever other solution you come up with.

If you have difficulty comprehending this subject, I highly recommend you to read the book Effective Java.

Answer 2

There is no inherent "advantage" in this approach, other than that

• it is a recognizable idiom. Using interfaces is the common way in which two classes communicate between each other in Java.
• the same code can be reused in many different Fragments & Activitys.
• it follows the general principles of modularity & abstraction, wherein the Fragment "tells" the Activity that it has reached a certain state, and the Activity determines its own behavior in relation to this state.

Answer 3

I think the majority advantage of interface based approach is because of its well-known and readable modularity and enough high level of abstraction as software engineering point of view.

Suppose you are at a team work and each team mate is responsible for one of these components, for example, it is supposed that you should implement that fragment and I should implement that activity. So because we are too far from each other we should agree on a shared interface as a standard between us and then we should implement our components that complies that standard, in this case our agreed interface. Also in software engineering considerations an component based software system consists of a number of components that act independently from each other and their interactions is only done by standard shared interfaces and materials inside each components is transparent to others

Therefore in your case, Activity and Fragment should be considered as two separate components and each of which does not know details about the other one. And here is the Java interface comes up.