Fragments and Activities are the points with which our users directly interact. As the navigation between Activities is very expensive and cause performance problems, using single activity and many fragments in it for a work-flow/user-flow has become very popular way of developing Android App nowadays.
Exceed the Android Speed Limit!
When it comes to goals or benchmarks for app performance, there is really only one. Does your app consistently draw the…
So communicating Fragment with other Fragments and Activity is one of important topics which we should take it seriously in order to develop maintainable Android application.
Communicating Fragment with Activity
Let’s firstly take a look at what Google recommends for the communication between Fragment and 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.
Communicate with other fragments | Android Developers
To reuse the Fragment UI components, you should build each as a completely self-contained, modular component that…
We basically define the interface(which is the contract of the Fragment) in the Fragment and we implement this interface in the Activity. We glue them by using onAttachFragment of Activity or onAttach method of Fragment. That’s it.
This is not directly recommended by Google but we can overuse shared ViewModel between Fragment and Activity to glue them.
We basically create an extra ViewModel with its LiveData variables for the Fragment to share its state with the Activity.
TLDR; as its observer is Activity, please don’t forget to use activity life cycle when you create ViewModel in the Fragment. That’s why activityViewModels() builder function in this example is used.
Listener over Shared ViewModel
- ) Listener has less code than Shared View Model.
- ) Listener forces its contract to the Activity, so Activity cannot skip any point otherwise we see unimplemented methods.
- ) Fragment may not live without its Listener(if it is forced)
Shared ViewModel over Listener
- ) Shared ViewModel is testable. We can easily write unit tests for them.
- ) Shared ViewModel can have filtering the notification logic in it.
- ) Activity does not need to observe all of events of the Fragment.
Both of them have pros and cons, we should decide one of them according to our system requirements. Both of them have no major advantages against each other in the Fragment/Activity communication perspective.
For example: if this ViewModel is used by many Fragments for Navigation purpose. They can both use same
interface Listener or
Shared ViewModel .
Communicating Fragment with Fragment
Again let’s firstly take a look at what Google recommends:
The recommended way to communicate between fragments is to create a shared
ViewModel. Both fragments can access the ViewModel through their containing Activity. The Fragments can update data within the ViewModel and if the data is exposed using
LiveData, the new state will be pushed to the other fragment as long as it is observing the
ViewModel. To see how to implement this kind of communication, read the 'Share data between Fragments' section in the ViewModel guide.
The fragments share the data or the state between each other ViewModel living under the lifecycle of Activity.
I would like to mention other ways for Fragment/Fragment communication like EventBus etc. However, I find these other ways event can’t help as sharedViewModel but also can cause many boiler plate/ lifecycle issues and code complexities.