face742d31a7a72a4bdced5594e00e51ecee6c84 |
|
16-Apr-2013 |
Chet Haase <chet@google.com> |
Avoid repositioning unattached overlay views Adding a view to an overlay usually entails removing the view from its current parent, if it has one. ViewOverlay.add() will do this automatically. At the same time, it will check to see whether the parent view is in a different global location than the overlay's host view, and will adjust the added view accordingly. This enables the caller to simply toss a view into an overlay and have it end up at the same global position on the screen. the problem is that the current code doesn't bother to check whether the old parent is attached. If that parent has been removed from the view hierarchy before this overlay operation, then it will show up as being at (0,0) in the window, not its old location. This results in the view being mis-positioned in the overaly. Fix is simple: if the view's old parent is not attached, simply remove it from that parent before adding it to the overlay; don't try to compensate for its position which is based on wrong information. Issue #8620319 Overlay should only use relative window locations for onscreen parents Change-Id: I414038a6c355dfd58f9766b007ac44d535ef1889
/frameworks/base/core/java/android/view/ViewGroupOverlay.java
|
edf6f4b49f6e77c349f5055372ce381b74f12efb |
|
26-Mar-2013 |
Chet Haase <chet@google.com> |
Make adding views specific to a ViewGroup's overlay Adding views to views (possible with the new Overlay API) is weird. This change moves the view-management facilities of Overlay to a subclass that is specific to the overlay returned from ViewGroup.getOverlay(). So now you can add drawables to all view overlays, but only add/remove views to/from the overlay returned from ViewGroup.getOverlay(). Also, the previous approach of using an interface for Overlay was changed to classes for both ViewOverlay and ViewGroupOverlay. Finally, this change makes not handling touch correctly the proper, and documented, behavior of overlay views. There are various tricky issues to sort out with input in overlays (including click handling as well as focus) and we don't want developers starting to use overlays as some kind of general container hierarchy, so we're purposely constraining overlays to have visual-only behavior. Issue #8459085 Overlay needs to handle touch correctly Change-Id: I207b8dbf528f87c92369d270d8b0a6556826d207
/frameworks/base/core/java/android/view/ViewGroupOverlay.java
|