StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Generally applications are split into Activities because each represents a specific "thing" that a user can do. For example, in an email application a defined set of actions could be:</p> <ol> <li>Viewing a list of messages</li> <li>Viewing a message's detail</li> <li>Composing a reply to an email.</li> </ol> <p>Each action could be its own Activity that shows a single (or set) of Fragments. However, if you had the screen real-estate it would make sense to combine the viewing of a message list AND the message detail into a single Activity that can show/hide the "detail view" Fragment. Essentially, Fragments allow you to show the user multiple 'activities' at one time.</p> <p> Things to consider when making your decision:</p> <ol> <li>Fragments specified in xml cannot be supplied arguments</li> <li>If your decision is based on screen orientation you can always use resource qualifiers to point to another layout with more/less Fragments (ex. layout-land-large)</li> <li>Fragments cannot be maintained Activities</li> <li>Are the Fragments working together to provide the user a streamlined experience?</li> <li>Is there a time where one of your Fragments will be gone for good? If so, maybe it's time for a new Activity</li> <li>Go with your gut. If its "natural" for you application to swap-out fragments, go for it. Just remember that if you find yourself doing it a lot, maybe a separate Activity is a more appropriate solution</li> </ol> <p>I've usually employed the "multiple Fragment approach" for tablet versions of applications and a "one Fragment per Activity" for phones, which sounds in-line with your <strong>first approach listed</strong>. Not that the second doesn't have a time and place, but I could see the implementation getting messy quick!</p> <p>Sorry for the wordy reply! Perhaps you could tell more about your specific use case? Hope this helps!<br> <br/><br/></p> <h1><strong>Response to Question Edit One</strong></h1> <hr> <p>Here's how I imagine your application project could be setup:</p> <p><strong>Source files:</strong></p> <p>yourapp.package.phone: NewsActivity1, NewsActivity2, NewsActivity3</p> <p>yourapp.package.tablet: NewsMultipaneActivity</p> <p><strong>Resources</strong></p> <p>layout/</p> <pre><code>activity_news.xml- phone version, only includes Fragment1 activity_news_detail.xml- phone version, only includes Fragment2 activity_news_<something>.xml- phone version, only includes Fragment3 </code></pre> <p>layout-large/</p> <pre><code>activity_news.xml- 7" tablet version, includes Fragment2 and an empty fragment container. Split vertically </code></pre> <p>layout-large-land/</p> <pre><code>activity_news.xml- same as layout-large, but with the split being horizontally </code></pre> <p>layout-xlarge-land/</p> <pre><code>activity_news.xml- 10"+ tablet version, contains all three fragments split horizontally </code></pre> <p>So what happens here? </p> <ul> <li>If your app is running on a phone, start NewsActivity1 </li> <li>If you app is runnin on a tablet, start NewsMultipaneActivity</li> </ul> <p>Android will swap layouts for you, based on screen size and orientation as long as the file names are the same. Because Fragment2 will always be displayed, you can 'hard code' it into your tablet layouts. Then you can use FragmentTransactions to switch between Fragment1 and Fragment3 in the container as necessary</p> <p>Be sure to check out <a href="http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources" rel="noreferrer">http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources</a> to see how you can take advantage of resource qualifiers to mitigate some of the headaches of different screens and orientations </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload