Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As others have already said in comments, you need to clearly define what you want to do first before making a concrete decision on which type of layout to use. However, I can certainly understand the confusion that arises from trying to decide over which type of layout class to use, because there are often several to choose from to achieve the same objective. For example, to create a vertically-scrolling list of items, you might at first choose a vertical <code>LinearLayout</code>, which you'd then place inside a <code>ScrollView</code>. But on the other hand, to achieve a similar end result, you could use a <code>ListView</code> together with a suitable <code>Adapter</code>. </p> <p>Similarly, to show a grid of items that can scroll vertically, you might use a <code>TableLayout</code> inside a <code>ScrollView</code>. Or, a similar result could be achieved from using a <code>GridView</code>, again by supplying data through a suitable <code>Adapter</code>. </p> <p>Now, the first key difference is this: Classes like <code>LinearLayout</code> and <code>TableLayout</code> require you to supply the child elements either in XML layouts or alternatively programmatically in code. Classes like <code>ListView</code> and <code>GridView</code> (and several others) are very different because they are subclasses of <code>android.widget.AdapterView</code>. The special thing about <code>AdapterView</code> classes is that an <code>Adapter</code> is used to bind data to them. So, going back to the example of a vertical list of items, if you were showing a group of child list items inside a <code>LinearLayout</code> based upon some array data, you would have to programmatically create and add child <code>View</code>s into that <code>LinearLayout</code> based upon the array data. With <code>ListView</code> on the other hand, the individual <code>View</code>s that represent the child items are supplied from a suitable <code>Adapter</code>. So, rather than you programmatically filling the layout with all child items (as would be the case with <code>LinearLayout</code> or <code>TableLayout</code> for instance), an <code>Adapter</code>-based layout instead calls the <code>Adapter</code> to obtain the child <code>View</code>s as and when it needs them.</p> <p>That last point is the next key difference I believe you should understand about <code>Adapter</code> based layouts: They are much more efficient at showing large amounts of data, in situations where much of the data is scrolled out of view. For example, a <code>ListView</code> is much more efficient to use for displaying a large scrolling list of items than would be if you simply populated a <code>LinearLayout</code> with all the items and put it inside a <code>ScrollView</code>. The reason for this efficiency is that <code>AdapterView</code>-based layouts do not generally contain all child <code>View</code>s all at once. Instead, as the user scrolls through the list, existing child views are "recycled" or "converted" by the <code>Adapter</code> to show the next child elements. To illustrate this with an example: You want a scrolling vertical list of 100 items. The screen may only be large enough to display 7 at once, however. Imagine you use a <code>LinearLayout</code> inside a <code>ScrollView</code> to show 100 list items. That means the <code>LinearLayout</code> container has 100 child <code>Views</code>. Those children are always present in the layout and need to be processed by the system during scroll events, even if only seven can be in view on the screen at one time. This takes extra CPU time, a considerable amount of RAM, and scrolling may be sluggish. Now, with a <code>ListView</code>, the layout will only probably contain just 7 or 8 child <code>View</code>s. As the user scrolls, those child <code>View</code>s are dynamically converted or re-instantiated by the <code>Adapter</code> through which you bind your data. The user will experience a faster, smoother scrolling operation. From a programming point of view, it is usually far more elegant to bind lists of data through an <code>Adapter</code>. When you're dealing with scrolling lists or grids of <code>Bitmap</code>s, the memory constraints of an <code>Android</code> device also mean the use of an <code>AdapterView</code> is pretty much essential. </p> <p>Bear in mind that when answering this, I've made the assumption that you're trying to show a vertical or tabular list of items that is scrollable, perhaps including <code>Bitmap</code>s, and I'm concentrating on the type of layout that you'd use for achieving the layout and scrolling of that data. Layout classes like <code>LinearLayout</code>, <code>TableLayout</code>, etc. however are important classes that you will use all the time to form individual layout building blocks for your applications. If your entire list is guaranteed to fit into the screen and won't be scrollable, then the additional complexity of using an <code>Adapter</code> (not that it <em>is</em> really that complicated) may be pointless and you might then just want to use a <code>TableLayout</code> or whatever.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

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