0

I am planning on a View Hierarchy like this:

enter image description here

Basically the Main Fragment will be able to trigger navigations inside the Bottom Sheet Navigation Controller , Bottom Sheet Fragment will also be able to trigger navigations inside the Bottom Sheet Navigation Controller and send Events/Data to the Main Fragment.

For example, lets suppose Main Fragment has a grid of items while the Bottom Sheet Fragment shows the last clicked item details. The user might click a button inside the details in the Bottom Sheet Fragment, let's say a "Order Now" Button and now this Event will have to be carried out to the Main Fragment. Please do not hold yourself to this particular use case, this is just an example I am making to illustrate the need.

My question is how can I overcome the separation provided by the Navigation Controllers in Android Jetpack? There are lots of documentations about how to use a common Activity and etc. to manage communications between Fragments that share the same screen, but now there's the new Navigation Controller that brings new abstractions de decouples the Fragment handling so I am not so sure on how to proceed.

I thought about maybe using a Singleton to pass Events/Data around, maybe with LiveData inside it, but I think there might be some more elegant solutions out there.

Michel Feinstein
  • 13,416
  • 16
  • 91
  • 173

1 Answers1

0

Solution with LiveData and ViewModel it is a very good solution, MainFragment and BottomSheetFragment will be attached to the same ViewModel instance. MainFragment will observe some LiveData object in ViewModel, and when user will click a button inside the details in the Bottom Sheet Fragment, LiveData object in ViewModel will be changed and MainFragment will be notified.

Alex
  • 9,102
  • 3
  • 31
  • 35
  • That's the solution proposed in the Viewmodel document, and I thought about using it at first, the problem I have with it is that I belive this "global" Viewmodel" will be a very complex class. Since the Bottom Sheet has a Navigator inside it, there will be several Fragments in the Bottom Sheet, being replaced, all of those will use the same ViewModel. So this ViewModel will have the logic of the Main Fragment, and all the Fragments navigated by the Bottom Sheet. It will have to have some sort state machine or conditionals to understand where it is at the Navigation of the Bottom Sheet.... – Michel Feinstein Sep 02 '18 at 09:54
  • ..... I am afraid it can get too messy and huge and difficult to read, maintain and test. – Michel Feinstein Sep 02 '18 at 09:54
  • In a nutshell: the Master-Detail (2 Fragments) solution using 1 ViewModel presented at the docs is fine, but in my case I can have some 6 Navigation Destinations (Fragments) in the Bottom Sheet + the Main Fragment, with a total of 7 Fragments for this Main ViewModel to manage, and I am afraid that can be just too much for one ViewModel, don't you think? – Michel Feinstein Sep 02 '18 at 10:44
  • You can use multiple Viewmodel classes for different use-cases, and some of them can be "global", and this way it won't be one big class but multiple small classes. – Alex Sep 02 '18 at 11:51
  • Yes, I just wanted to sometimes have the inner ViewModel exchange information with the other ViewModel, and not have to choose between having one or the other – Michel Feinstein Sep 02 '18 at 12:57