Android Why is using an interface considered to be the best communication practice between Activity and Fragment?

Question

In this documentation , Communicating with Other Fragments, Google tells us that the best practice for conveying activity and fragment is to implement an interface . This interface can then be called by the Fragment and perform the necessary behavior in the Activity.

But there is also a way to hack this. Get the Activity directly using the "getActivity ()" method, and then we can use all the "public method" .

I'm pretty confused. The reason I could not think of any critical drawback of using the hacking method for this.

What is the advantage of the first approach in my head:

• I can limit the "availability of resources" to my activity. But since Fragment can call "getActivity ()", then it can actually access the entire "public" method in it. So it cannot convince me.
• More readable and narrative in code. At the first approach, the code tells us that "this action only opens this particular accessible area for the fragment." We can know that “within a fragment can affect activity” directly by simply looking at the code in Activity . Or else, we will need to open the code under the Snippet to see what it did.

Well, after I generalized them, I was a little convinced myself. But to be honest, I really want another solid and I have to talk about it. Any idea or documentation would be really appreciated!

Answer 1

First of all, the main advantage is the modularity of your code. When you call your "parent" class from a "child" class, you create a circular dependency . This means that you cannot replace it without changing another. This approach often leads to spaghetti code that is difficult to maintain, even harder to expand, and almost impossible to replace without much refactoring efforts.

As for your example: if you call the public methods of your Activity directly from Fragment , you cannot reuse your fragment in other actions without implementing hacker solutions (for example, if(getActivity() instanceof A) {...} else {...} ), and you cannot change your activities, for example, the controller class or any other solution that you encounter.

If you find it difficult to understand this topic, I highly recommend that you read Effective Java .

Answer 2

There is no inherent “advantage” in this approach, other than this

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

Answer 3

I think that the advantage of most interface-based approaches lies in its well-known and readable modularity and a fairly high level of abstraction as a point of view of software development.

Suppose you are working in a team and each team member is responsible for one of these components, for example, it is assumed that you must implement this fragment, and I must implement this activity. Therefore, since we are too far apart, we must agree on a common interface as a standard between us, and then we must implement our components that comply with this standard, in this case, our agreed interface. Also, for software development considerations, a component software system consists of several components that act independently of each other, and their interaction is carried out only by standard common interfaces, and the materials inside each component are transparent to others.

Therefore, in your case, Activity and Fragment should be considered as two separate components, and each of them does not know the details of the other. And here the Java interface appeared.