Menu
I have an Activity A hosting two main Fragment F1 and F2. Both F1 and F2 have nested Fragment, each with its own Listener interface for exchanging data.
From what I understood from the answer to this question, the activity A:
needs to know every single interface declared by the fragments hosted by F1 and F2
needs to route the events generated by the fragments in F1 and F2 to the correct main fragment, F1 or F2.
If I understood correctly, there is no modularity in this approach: the activity needs to know everything about both the fragments it hosts (F1 and F2) and the fragments that are nested in F1 and F2.
Am I correct? For sure, I am very confused ...
715
To properly react to user events, or to share state information, you often need to have channels of communication between an activity and its fragments or between two or more fragments. To keep fragments self-contained, you should not have fragments communicate directly with other fragments or with its host activity.
To allow a Fragment to communicate up to its Activity, you can define an interface in the Fragment class and implement it within the Activity. The Fragment captures the interface implementation during its onAttach() lifecycle method and can then call the Interface methods to communicate with the Activity.
There are two ways of doing so. To have a sharing of data between Fragments, either you can use a shared ViewModel that is shared between all the Fragments or you can make an Interface and then use this interface to communicate between fragments.
Fragments introduce modularity and reusability into your activity's UI by allowing you to divide the UI into discrete chunks. Activities are an ideal place to put global elements around your app's user interface, such as a navigation drawer.
If you look at the Communicating with Other Fragments tutorial, it says that:
All Fragment-to-Fragment communication is done through the associated Activity. Two Fragments should never communicate directly.
The reason for this is that Fragments are fluid & dynamic UI components that may fade in and out of view. Only the hosting Activity is capable of determining if a Fragment is added to the UI or has been detached from it.
If I understood correctly, there is no modularity in this approach: the activity needs to know everything about both the fragments it hosts (
F1andF2) and the fragments that are nested inF1andF2.
The Fragments are "modular" in the sense that they are totally independent & reusable UI blocks. Also, they are "modular" because their interfaces are well defined and explicitly implemented by the hosting Activity. Anywhere you drop that Fragment in, if the Activity implements the callback interface defined in the Fragment, then the Activity "chooses" what to do depending on whether the Fragment is added / attached to the UI or not.
If we loosely apply the MVC way of thinking here, the hosting Activity acts as a controller of sorts between two views which are the Fragments. Of course this is just a loose analogy, but hopefully you get the picture.
Further considerations:
There is an alternative to this approach: a method called getParentFragment() that a nested Fragment can use to get a reference to the "outside" Fragment.
References:
1. Why direct communication between fragments is not recommended?.
2. Communicating with other fragments or to activity.
3. Fragment question: inter-fragment communication?.
135
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
