title: To Fragment or not to Fragment - Nested Fragments against Activities. Why should I use more than one Activity?
body: <p>There are a lot of discussions about whether you should use <code>Activities</code> or <code>Fragments</code>.
  For example:</p>
  
  <ul>
  <li><a href="http://andytsui.wordpress.com/2011/10/23/to-fragment-or-not-to-fragment/" rel="noreferrer">To-Fragment-or-not-to-Fragment</a></li>
  <li><a href="https://stackoverflow.com/questions/12154505/one-activity-and-all-other-fragments">One Activity and all other Fragments</a></li>
  <li><a href="https://stackoverflow.com/questions/12363790/how-many-activities-vs-fragments">How many Activities vs. Fragments</a></li>
  <li><a href="https://stackoverflow.com/questions/18885311/use-activity-or-fragment-in-android-application?rq=1">Use Activity or Fragment in Android Application</a></li>
  </ul>
  
  <p>Most of the discussions I found were released before Android 4.2.<br>
  With Android 4.2 Google invented <a href="http://developer.android.com/about/versions/android-4.2.html#NestedFragments" rel="noreferrer">nested Fragments</a>.</p>
  
  <p>Therefore I actually don't see any reason anymore to use more than one <code>Activity</code>.</p>
  
  <p>In the early stage of <code>Fragments</code> they were supposed to be used within Apps for supporting <strong>Tablets</strong> and <strong>Smartphones</strong> in a comfortable way at the same time. </p>
  
  <p>Thus for example you have a <code>ListView</code> which can open a detail <code>View</code> on click on an item. On a Smartphone we would replace the <code>ListView</code> and show the detailed <code>View</code> instead. Whereas a <strong>Tablet</strong> instead of replacing the List with the detail View can show both <code>Views</code> at the same time.</p>
  
  <hr>
  
  <p>Now with nested <code>Fragments</code> there are a lot of other possibilities. In case you want to use a single <code>Activity</code>, you could store general information in the <code>Activity</code> and every <code>Fragment</code> would have access to it. </p>
  
  <p>Besides this, <code>Fragments</code> who have nested <code>Fragments</code>, could also store information for their children <code>Fragments</code>. </p>
  
  <p>With <code>Fragments</code> I can easily reuse the <code>Views</code>, I can show more than one <code>Fragment</code> at the same time and I can easly form a dialog out of a <code>Fragment</code>. This all would take me probably not more than just some copy &amp; paste actions.</p>
  
  <p>If I use <code>Activities</code> instead I seriously have to change a lot to get this done. </p>
  
  <hr>
  
  <p>I recently implemented an <strong>Application</strong> where I easily could use two <code>Fragment-ViewPager</code> to get things really beautiful and dynamic (Some kind of: Today's Information - Yesterday's Information). 
  In my opinion <code>Fragments</code> make our life a way easier :) </p>
  
  <hr>
  
  <p><strong>Questions:</strong></p>
  
  <ul>
  <li><strong>Why should I use more than one <code>Activity</code>?</strong></li>
  </ul>
  
  <p>Could you provide any good example in which the usage of multiple <code>Activities</code> makes more sense instead of using <code>Fragments</code>?</p>
  
  <ul>
  <li><strong>Are there any good examples where you don't have any choice but to use <code>Activities</code>?</strong></li>
  </ul>
  
  <p>I think most of the bigger frameworks like <strong>Maps</strong>, <strong>YouTube</strong> and co already support <code>Fragments</code>. So we don't have to rely on <code>Activities</code>. 
  Also is it quite easy to deal with <code>NavigationBar</code>, <code>TabHosts</code>, <code>ViewPager</code>, <code>ActionBar</code> in case you use <code>Fragments</code>. </p>
  
  <hr>
  
  <p><strong>From Udacity:</strong> </p>
  
  <p>Why not always create one Activity with lots of Fragments?</p>
  
  <ol>
  <li>Increased Complexity</li>
  <li>Harder Intent handling</li>
  <li>Difficult to read, maintain and test</li>
  <li>Risk of tight coupling</li>
  <li>Security concerns</li>
  </ol>