Transient state is temporary bookkeeping that Views need to perform
that the app should not need to be aware of. Examples include text
selection regions and animation state.
Transient state is a problem for AdapterViews like ListView that do
view recycling. Unless the app takes responsibility for tracking and
restoring transient state as if it were a part of the adapter's data
set, it cannot correctly recycle views. Selections disappear when an
EditText is scrolled out of sight and animations seem to play on the
wrong views.
Views can now flag themselves as having transient state. (As the name
implies, this should be a temporary condition.) If a ViewGroup
contains a child with transient state, that ViewGroup also has
transient state.
AbsListView's recycler now tracks views with transient state
separately. Views with transient state will be retained, and until a
data set change occurs the same view will be reused for that position
instead of calling the adapter's getView() method.
The API to set and check transient state is currently hidden.
Change-Id: Idfd8eaac2c548337686d8d9f98fda4c64be5b8a0
This optimization allows us to quickly skip operations that lie
entirely outside of the known bounds of a display list. Because
of ViewGroup.setClipChildren, we must keep the operations recorded
in the display list. setClipChildren(false) is however a very
uncommon operation and we will therefore often benefit from this
new optimization.
Change-Id: I0942c864e55298e6dccd9977d15adefbce3ba3ad
LEFT alignment in an RTL environment had the wrong 'gravity'.
This was due to a modelling error in GridLayout which is fixed in this CL.
Also apply some very minor simplifications and refactorings following the
addition of RTL support.
Change-Id: I153bc06d3c22dcb9954e4cbdfa89625823239b89
This change makes it much easier to make sense of the messages that
get posted to the ViewRootImpl's handler by encapsulating their point
of dispatch within the ViewRootImpl itself.
As part of this change, the View.AttachInfo now carries a reference
to the ViewRootImpl itself, which simplifies some code that used
to try to find the ViewRootImpl by getting the root view's parent.
In principle, it might have been nice to hide the ViewRootImpl from
the View hierarchy but in practice the two were coupled in many ways.
Change-Id: I51ebccdf5f8c8c505cd6f17cdf594174d041dc54
Bug #5553515
The People app is forcing ACTV to show the IME which had the side effect
of showing the drop down popup. ACTV was unfortunately not ready to show
the drop down if the filtering resulted in no results. Doing so was putting
ACTV in a weird state that in turn caused a window to be leaked and really
bad behavior to occur in the lower graphics levels.
Change-Id: I2ff146d5ae4e4a28edf6ea17039c9f8fdb710e4f
This change allows layouts to be notified of changes to LayoutParameters that have occurred
between layout operations.
If an assignment is made to the fields of LayoutParams instances that are already in use,
cachced data may become inconsistent with the new values. For complex layouts, like
GridLayout, in which the layout parameters define the structure of the layout, caching
could have caused ArrayOutOfBoundsException to be raised without this change. This case is
rare in normal code as initialisation is typically performed once. Its nevertheless possible
and much more likely in environments like design tools where layout parametrs may be being
edited on the fly.
Prevent errors as follows (belt and braces):
1. Change javadoc to request that changes to the fields of LayoutParams be accompanied with
a call to View.setLayoutParams(). (This calls requestLayout() which was what the previous
javadoc advised.) Provide a (for now, private) hook for layouts with caches to receive notification
of such calls so they can invalidate any relevant internal state.
2. For GridLayout, we cannot clone layout parameters as traditional Java grids do without retaining
two complete copies because of the public getLayoutParameters() method on View. Retaining two
copies is wasteful on constrainted devices. Instead, we keep just one copy and compute a hashCode
for the critical fields of a GridLayout's layoutParams. The hashChode is checked it prior to all
layout operations; clearing the cache and logging a warning when changes are detected, so that
developers can fix their code to provide the call to setLayoutParams() as above.
Change-Id: I819ea65ec0ab82202e2f94fd5cd3ae2723c1a9a0
- update also DEBUG mode for taking care about RTL
- one minor issue remaining: left alignment is not properly honored in RTL
Change-Id: I9a4c8413cb1189a032649472016994642418637b
Bug 5887530, Bug 5945886, Bug 5904371
Added more invalidation when other properties of the text are changed.
Change-Id: I618dbaae9da64bf72dd29e444215b7de1c644573
Some apps have managed to hit this edge case in monkey runs. In
layoutChildren an attempt to findFocus() fails when items are
focusable. When ListView attempts to restore focus to this view,
bad things happen.
Change-Id: Ie8bb1bab847898e342c16fbe3ff1a6153d6f69df
These markers will be used to group the GL commands by View in the
OpenGL ES debugging tool. This will help correlate individual GL
calls to higher level components like Views.
Change-Id: I73607ba2e7224a80ac32527968261ee008f049c6
When a view is becoming VISIBLE or INVISIBLE in a container with a
LayoutTransition, animations run to fade the view in and out and also
to run 'changing' animations on the view's other siblings. This logic
also cancels any running 'changin' animations to account for new ones
running.
However, in the specific case of INVISIBLE changes, there will be no
layout changes in the container - layout has already accounted for that
view (unlike in the case of GONE views); the visibility is just a matter of
drawing the view (or not). Therefore, we're canceling 'changing' animations
that should continue running and not replacing them with any other animations,
since new animations would only be started on layout chnages which are not
forthcoming.
One artifact seen from this bug is that the navigation bar buttons sometimes
disappear when changing orientation. This is because the menu button may
toggle between VISIBLE and INVISIBLE, causing animations on the other
buttons to get canceled, which leaves those views in a completely wrong
state.
The right thing to do is to avoid canceling in-process 'changing' animations
and to skip the logic of setting up new 'changing' animations which won't fire
anyway.
There is some minor API work in here because we did not previously have the
necessary information in LayoutTransition to know whether a view was being
hidden or shown to/from the INVISIBLE state.
Issue #5911213: LayoutTransitions ending in an odd state
Change-Id: I5c60c8583c8ea08965727b4ef17b550c40a3882c
Bug 5556478
Launcher pre-populates its all apps and widget pages with their
content, which includes text. The layout calls some onMeasure methods
that trigger TextView's registerForPreDraw(), which in turns adds a
listener in the ViewTreeObserver.
However, some of these pages may never be actually displayed, leaving
the listeners in the list since onDraw() is never called.
As a result, every frame displayed by launcher is slowned down by this
array copy of 6-18 listeners.
The problem is not Launcher specific since other applications may use
a similar caching mechanism.
The solution is to unsubscribe the listener in onPreDraw.
The drawback is that several successive calls to registerForPreDraw() will
add/remove the some listener object. However, these calls are rare and are
relatively cheap since we're just adding the object in and out of an
ArrayList which should not need to change its size.
Change-Id: Ifb65655a27e302d31a2ad622d18f839aec99689e
This new test is required since the suggestion popup is now triggered by a
Runnable. We have to make sure there is still at least one SuggestionSpan
at that position.
Change-Id: I5c84ba0ca412f51a0201bee5c2e63b5bd3717338
Bug 5916225
Duplicates were removed when received from SpellChecker, in a way
that could move the top candidates lower in the list.
Moved that code to the part that creates the actual suggestion list,
to make it more generic. The order of the first SuggestionSpan is
guaranteed to be respected.
Also mentionned non null suggestions and fixed a problem in SuggestionSpan
constructor.
Change-Id: Iaa3b1b84ae512451e439e5c5e63448c2a19145b5
is reset.
As per platform guidelines, when launching a sharing activity the Intent
flag FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET should be used.
Change-Id: I30bd3d20eb75aee7943b681dc2d9c7f44a04e919
1. The selector wheel was throwing an exception if a client requires that it
wraps its selector wheel if the number of values is less that the number
of values shown in the wheel. While wrapping makes no sense if the all
possible values are already shown, we should not throw an exception,
rather to ignore the request.
bug:5911190
Change-Id: Icd90cd39f66d9f39939801752bf1eb1eef8fe757
