Background:
mlebeau said: "Cole had complained that the vertical alignment of the
text fields in search_dropdown_item_icons_2line.xml was a little
off. Specifically, when both lines are visible he wanted to see line1
pushed down 2-4 pixels (while keeping line2 in the same position as
now), and when only line1 is visible, he said it needed to be pushed
up 2-4 pixels from current."
Here's how the layout worked before (note that text2 and text1
are in this order in the layout file):
- If text2 is present, it is put at the bottom, with height set by
layout_height (currently 29dip) . - The line2 text is put at the top
of text2 (gravity=top).
- I think the paddingBottom=4dip in text2 has no effect, since the
text is top-aligned anyway.
- text1 is put at the top of the list item. If text2 is present, it
will have height 29dip (58 dip - 29 dip height of text2). It's a bit
weird, layout_height of text1 is completely ignored, but it has to be
set to something. If text2 is missing, it will fill the entire list
item height (58 dip).
- The line1 text is placed 4dip below the vertical center of text1
(4dip because of paddingTop).
Now, instead, text1 has height=wrap_content, and is placed right above
text2, if that's present. If text2 is absent, text1 is centered
vertically in the list item. This should have the desired effect.
If we want to tweak the positioning further in the case where text2
is visible, we can adjust the padding of text1.
* changes:
Add a new API to ListView: setGestures(int). This allows developers to enable gestures to jump inside the list or filter it. This change also introduces a new XML attribute to control this API. It also adds the ability to theme the GestureOverlayView from the gestures library. Finally, this adds a new VERSION header to the binary format used to store the letters for the recognizer.
Merge commit 'cfcc0df2658d0ce7dc753511bb44ab8ae7a636f7'
* commit 'cfcc0df2658d0ce7dc753511bb44ab8ae7a636f7':
Move the Gestures API to the framework in android.gesture.
Merge commit 'c4d5d02667af6989a3121072871f6a4b1e68b594'
* commit 'c4d5d02667af6989a3121072871f6a4b1e68b594':
Add new window manager type for a hacking second-level media surface.
This adds a new window type that is a surface that sits between the
current media type and the application window, in theory allowing you
to have two surface views in your hierarchy and control their
Z-ordering. There is also another hidden API on SurfaceView to set
the type of your window.
All a big hack, but for the good of the commonwealth!
Use Integer.valueOf() instead of new Integer()
Eliminate unused fields in InvokeListBox
Make FocusNode, HitTestRequest, and ExtendedZoomControls
static inner classes.
Merge commit 'b6d99b7d17fd1bb1326a70744bd01be5d1586487'
* commit 'b6d99b7d17fd1bb1326a70744bd01be5d1586487':
Modify how GestureLibrary stores its data. The XML format is now replaced by a more efficient binary format which should speed up saving/loading. The format is very similar to the one used by the letters recognizer. The format is documented in GestureLibrary.java.
SQLLite limit is not only used to limit the returned number of data.
It can be used to do an offset query.
For example, "SELECT * FROM table LIMIT 100, 10", will return the
data of index in the range of [100, 100 + 10).
This change set enable this kind of useage.
This is also more efficient than use "cursor.moveToPosition()".
In my experiment, I query 1000 items in batch mode, i.e.,
get 20 items out of 1000 each time.
Time of using LIMIT clause: 626ms
Time of useing "cursor.moveToPosition()": 2062ms
Merge commit 'd1874747c281e3277980fe7318f9007643a25f60'
* commit 'd1874747c281e3277980fe7318f9007643a25f60':
Fixes external http://code.google.com/p/android/issues/detail?id=2732. ExpandableListView is wrongly assuming that the saved state if of the correct type. A similar bug fix was made in TextView.onRestoreInstanceState() a while ago. This fix simply ensures that the state received is of the right type.
* changes:
Fixes external http://code.google.com/p/android/issues/detail?id=2732. ExpandableListView is wrongly assuming that the saved state if of the correct type. A similar bug fix was made in TextView.onRestoreInstanceState() a while ago. This fix simply ensures that the state received is of the right type.
