Reputation: 748
Total beginner here.
As I understand, fragments should communicate with each other through their hosting activities as a way to stay independent and reusable in other situations.
I’ve read that should be done by declaring interfaces in the fragment and implementing them in the activity. Is that the best way to go about it “just” because you can make sure the activity is ready for that communication (it really has that method to deal with the communication)?
As I’m having a hard time wrapping my head around interfaces (and lots of others things in java/android, for that matter), could this be done without the interface? Could I get a reference to the hosting activity in the fragment and just call the activity’s method?
(fragment class)
Activity activity = getActivity();
activity.doThatThingToOtherFrag(String myString);
(activity class)
Fragment otherFragment = getSupportFragmentManager().findFragmentById(R.id.myOtherFrag);
public void doThatThingToOtherFrag(String string) {
//do something to myOtherFrag
}
Or is there something else about implementing an interface in this case that I’m not getting?
* EDIT *
Let’s say I reuse that fragment in another activity. As long as that activity also has a doThatThingToOtherFrag(String myString) method, I can get a reference to it through getActivity() and still call activity.doThatThingToOtherFrag(String myString) from my fragment, right? I wouldn’t have to change anything in my fragment code -- or am I’m missing something here?
I guess my question should be: is the interface there only to MAKE SURE the/any hosting activity implements a doThatThingToOtherFrag method? Or is there something else I don’t know about interfaces in this situation? Thanks for the help!
Upvotes: 2
Views: 1156
Reputation: 83537
"Program to the interface." is a common maxim of object oriented programming. You can certainly just communicate with the activity directly without using the interface. However, this create a tight coupling between the fragment and the activity.
Consider a situation where you want to reuse the same fragment in two different activities. Using interface allows the flexibility to do this.
Answer to edit:
As long as that activity also has a doThatThingToOtherFrag(String myString) method, I can get a reference to it through getActivity() and still call activity.doThatThingToOtherFrag(String myString) from my fragment, right?
I assume you mean something like this:
Activity activity = getActivity();
activity.doThatThingToOtherFrag(String myString);
This won't compile because Activity
doesn't have a method named doThatThingToOtherFrag()
. However, if you do
FragmentCommunicationInterface activity = (FragmentCommunicationInterface) getActivity();
activity.doThatThingToOtherFrag(String myString);
now it will compile. This has yet another problem: what if the fragment where this is called was added to an Activity
which doesn't implement FragmentCommunicationInterface
. Now you will get a run-time error when you do the case.
One possible solution to this is to take a FragmentCommunicationInterface
as an argument to the fragment's constructor:
public class MyFragment extends Fragment {
private FragmentCommunicationInterface communication;
public MyFragment(FragmentCommunicationInterface communication) {
this.communication = communication;
}
}
Now you create a fragment with
MyFragment frag = new MyFragment(this);
Another advantage to using an interface is that the interface can be implemented by any class not just classes which extend Activity
. This allows even more flexibility than I hinted above. It allows you to organize the code to communicate with the activity or other fragments in any way you want.
Upvotes: 4
Reputation: 7086
One good reason not to do the way you implemented as above is loose coupling. It is a program design pattern to create well-designed software. I am not gonna create a new discussion of it here since a lot of other discussions are available in StackOverflow.
What is "loose coupling?" Please provide examples
Please take time to understand this concept as this will save you a lot of time as a programmer.
Cheers!
Upvotes: 0
Reputation: 2005
This way you can make your fragment work with any activity that implements the interface. This completely adds to the independence and reusability you pointed out in your question.
If you would use the activity class's method to 'communicate' you would not be able to make it work (interface with) other activities because they are of a different class.
Upvotes: 2
Reputation: 6037
It's not really necessary, but it may be desirable.
In general, interfaces help code not depend on the class whose code you call. You don't really care which Fragment class you're invoking, what you really care is that whatever you're invoking, it needs to have the ability to doThisOrThat()
-- so that's what you put in your interface.
This decoupling is actually about helping to use polymorphism. Say your code may use two Fragment classes where you now use one, and both ca n doThisOrThat()
. In that case using an interface will help you write cleaner code, because you won't need to write duplicate code to invoke the same method, except for changing what you cast it to.
Anyway, in order to really decouple you classes, you might want to learn about EventBus (doesn't matter which implementation).
Upvotes: 2
Reputation: 2342
Interfaces are best for communicating two fragments, 2 activities or communicate with any class, because interface triggered at same time when other want to communicate.
Upvotes: -1