title: ViewModel for Fragment instead accessing Activity ViewModel?
body: <p>The problem is quite straightforward. The question is in context of using ViewModels, LiveData and other related <a href="https://developer.android.com/reference/android/arch/lifecycle/package-summary.html" rel="noreferrer">Lifecycle</a> aware arch approaches.
  <br/>I have an Activity with NavDrawer, which switches fragments inside. <br>And also I have a case when two fragments are present at the same time on the screen - this will be the main pain.
  One Fragment has a ViewPager with nested <code>Fragments</code>(<strong>don't ask why</strong>).
  The other fragment is just obtaining info from first one when user performs some actions. This is achieved just by sharing activity viewmodel. But the app itself has a lot of business logic and as it goes further the viewmodel goes bigger and bigger.
  <br/> What I want to ask - not a receipt or rules how to fix this, or maybe how to overcome this by fixing the entire structure of the project. I want to ask for suggestions how can I apply the MVVM approach within android.arch.lifecycle style to mine use-case.
  <br> I haven't seen something more complicated then just sharing the Activity ViewModel between Fragments. But common, that's not a cure.
  <a href="https://i.stack.imgur.com/kASaU.jpg" rel="noreferrer"><img src="https://i.stack.imgur.com/kASaU.jpg" alt="enter image description here"></a></p>
  
  <p>What you can see here - a mess actually. The point is that all are sharing the <code>ActivityViewModel</code>. Connections(aggregation) from FirstFragment mean that <code>ViewPager</code> inside <code>FirstFragment</code> is initiating <code>ChildFragments</code> and they are also working with the same <code>ActivityViewModel</code>(kill me). So as result everyone is working with one shared ViewModel. 
  <br> My proposal is to add a ViewModel for each Layer. So that Activity/Fragments/ChildFragments have their own ViewModels.
  But what appears here - <strong><em>how we should communicate then</em></strong>?
  <br> Possible solutions :</p>
  
  <ul>
  <li>Having two ViewModels per one component. One ViewModel will handle/delegate the business logic and another will make the communication. <strong>Two viewmodels per component - not so good, yeah?</strong></li>
  <li>Having old manner interface(<strong>please no!</strong>)</li>
  <li><p>Other workarounds - like DB/SharedPrefs/Realm change listeners and Event Buses(<strong>I'm too old for this :(</strong> ).</p></li>
  <li><p><strong>Your solution here!</strong></p></li>
  </ul>
  
  <p>I'll say that all of the above are breaking a lot of design principles, so what should I do?
  How should I come out of this mess? Is there any <code>Uncle Bob</code> or another <code>superhero</code> here to help?</p>
  
  <p><strong>P.S.</strong> - Well, creating UMLs or other charts isn't mine forte. Sorry for that. 
  <br><strong>P.P.S.</strong> - I'm aware of <a href="https://github.com/googlesamples/android-architecture-components" rel="noreferrer">google</a> <a href="https://github.com/googlesamples/android-architecture" rel="noreferrer">samples</a>.</p>