When Resources.getLayout(int) is called to return a parser
for an embedded layout, this queries the current parser for
a custom parser (Eclipse will provide one on top of the current
XML model being edited)
Change-Id: Ia9e837358f67daed0a835e1b3f4f50c0516ceee9
When an include tag is parsed, the custom bridge
code never has access to both parsers at the same
time.
The child parser is created out of an in (representing
the layout id), and the code inflating the content of
the include layout doesn't see the parent parser either.
This changeset adds a parser stack in the BridgeContext
in order to allow access to the parent parser when setting
the viewkey. This is only used if the current parser depth
is 1 (top node), as we only want to set the include
node to the top node of the included layout.
Change-Id: I2ac3b72a0c84a269d9019f44f98cbc0b615ab959
This fixes the SlidingDrawer that failed to load.
For some reason, in case of the SlidingDrawer, when the constructor
uses android.R.styleable.SlidingDrawer it's the same values but not
the same instance as the array read from android.R through reflection.
So what works for all other widgets, and has worked since the very first
layoutlib isn't working anymore, and we'll now have to use a wrapper
similarly to what we use in ADT in the project callback.
We should probably provide a single int[] wrapper class in layoutlib
API for all to use.
Change-Id: I4d7d038540f8a24541a588696f1059a020b589e5
This is done by initializing the android.util.Finalizers that's
reponsible for calling out to the native bitmap destructor.
Also implemented the native bitmap destructor
Also fix Bridge by removing obsolete API methods, and removing
some unneeded synchronized blocks now that the whole rendering
(and scene creation) is protected by a synchronized on the bridge
object anyway.
Change-Id: Ie1792da6db354836542dfc11f457fe4a6d78ddfb
new Color(int) ignores the upper 8 bits - it creates a color without
an alpha channel. In order to pass in rgba we have to use a different
constructor, new Color(int,true).
(In the layout library API we should also specify that the custom
color, if specified, needs to include an alpha, or in particular add
in 0xFF<<24 if the color is opaque.)
Change-Id: I1c44caed8a5780e61b1c799f3b45bef3eb7bc97b
Since the new API prepare for stateful layoutlib, major
reorganization of the code.
New "android" sub-package for all extended android classes.
Also moved BridgeInflater in here so that all extended classes
are in this package. Only delegates and classes replacing
renamed classes are in their original android.* packages.
Also created full file for the empty implementations of
IWindow and IWindowSession.
New "impl" for the dirty work implementation.
Main package contains the basic implementation of the API.
Most of the code that was in Bridge is now in .impl.LayoutSceneImpl,
with the main init/inflate/render code split into the contrustrutor,
inflate() and render().
Change-Id: Ie15b15e5a1b2388cd6ef82e518345b1fc02ec981
This change does the following:
- Make the bridge context extend Activity instead of Context
so that it can act as a view factory. This is needed because
the Activity is used as factory for Fragment objects.
- Override the default Fragment.instantiate(...) method
through a delegate. This is done to load the Fragment
classes located in the project (similar to custom views).
Change-Id: If62e7c9ff2b7585677077ad825aa1c3591d1b5e0
While the difference is pretty minor since it's a small class,
the point is that the unit test will ensure that we detect
new methods added to FloatMath more easily.
Change-Id: Ia8bfee231cc4ae0cfeb18692be86d02649c187d5
Also fix native delegate generation to put "this" parameter even
for methods that don't have any parameters.
Change-Id: I5dd0c505871370ff7b4cda16de84a5b3ae438f73
This does not implement all the native methods of the
android.graphics.Bitmap class, only what's needed to draw an
ImageView object. The rest will be implemented after Canvas and
Paint have been moved to the native delegate.
Change-Id: Ia0c3b2cafa03871c298deaef5817a25ac1c35521
Instead this uses the actual output of layoutlib_create, which is
all the modified classes before the content of the bridge is added
to form layoutlib.
Change-Id: I22755f38800cd69206834ff9594a99cb0c1d2139
Instead of renaming the old Matrix class into _Original_Matrix
and have layoutlib provide a full new implementation of Matrix,
we keep the old one by only modifying it to implement the native
methods which calls out to a new Matrix_Delegate class.
The goal is to not have to maintain the java portion in
sync between the framework and the layoutlib version.
Change-Id: I3e1aefffbae45e91b75331c0c6ff2260323deacd
Framework resources loaded through Drawable.createFromXml could
be overriden by project resources if there were loaded through
a state list drawable where the final resource name was used
by a project resource (of the same type).
This ensures that the XML parser knows that it's a framework
resource being parsed and that the resource resolution uses
that information.
Change-Id: I39cf9eba755e55f1604b968637aeecff969a558d
DragEvent.getResult() returns 'true' if the drop was ultimately accepted;
false otherwise. The validity of this datum is only guaranteed when the
DragEvent's action verb is ACTION_DRAG_ENDED.
Also fixes the drag-start timeout handling (though the offending app is
not yet officially declared ANR).
Implements bug 3097807
Change-Id: I6908ac628c72ff7d6193d87060d769a559a78d0e
Merge commit '656d21656ad9b33f7d7e1e4960a2f03076a5fc7a' into gingerbread-plus-aosp
* commit '656d21656ad9b33f7d7e1e4960a2f03076a5fc7a':
Parser is optional in obtainStyledAttributes.
A View initiates a drag-and-drop operation (hereafter just called a "drag")
by calling its startDrag(ClipData) method. Within the processing of that
call, two callbacks are made into the originating View. The first is to
onMeasureDragThumbnail(). Similarly to the core onMeasure() method, this
callback must respond by calling setDragThumbnailDimension(width, height) to
declare the size of the drag thumbnail image that should be used. Following
this, the View's onDrawDragThumbnail(canvas) method will be invoked to
actually produce the bits of the thumbnail image.
If all goes well, startDrag() will return 'true', and the drag is off and
running. (The other arguments to startDrag() provide reconciliation between
the current finger position and where the thumbnail should be placed on
the screen relative to it.)
Potential receipients of the ClipData behind the drag are notified by a
new dispatch mechanism, roughly parallel to motion event dispatch. The core
routine is the View's onDragEvent(event) callback, with the mechanics of
dispatch itself being routed through dispatchDragEvent(event) -- as in
the case of motion events, the dispatch logic is in ViewGroup, with leaf
View objects not needing to consider the dispatch flow.
Several different event 'actions' are delivered through this dispatch
mechanism:
ACTION_DRAG_STARTED: this event is propagated to every View in every window
(including windows created during the course of a drag). It serves as a
global notification that a drag has started with a payload whose matching
ClipDescription is supplied with the event. A View that is prepared to
consume the data described in this event should return 'true' from their
onDragEvent() method, and ideally will also make some visible on-screen
indication that they are a potential target of the drop.
ACTION_DRAG_ENTERED: this event is sent once when the drag point
enters the View's bounds. It is an opportunity for the View to set up
feedback that they are the one who will see the drop if the finger goes
up now.
ACTION_DRAG_LOCATION: when the drag point is over a given View, that
View will receive a stream of DRAG_LOCATION events, providing an
opportunity for the View to show visual feedback tied to the drag point.
ACTION_DRAG_EXITED: like DRAG_ENTERED, but called when the drag point
leaves the View's bounds. The View should undo any visuals meant to
emphasize their being the hovered-over target.
ACTION_DROP: when the drag ends at a given point, the View under that
point is sent this event, with the full ClipData of the payload.
ACTION_DRAG_ENDED: paralleling the DRAG_STARTED action, this is the global
broadcast that the drag has ended and all Views should return to their
normal visual state. This happens after the DROP event.
Change-Id: Ia8d0fb1516bce8c735d87ffd101af0976d7e84b6
- Some new parameters are added to CreateInfo with the list of methods
or classes to override with delegates.
- DelegateClassAdapter and DelegateMethodAdapter do the work... see javadoc.
Change-Id: I0657cd929837181d81c65db7051d8ccbdc59c741
Merge commit '292c246b27319bc2195e2b3dbc3c3adea22db672' into gingerbread-plus-aosp
* commit '292c246b27319bc2195e2b3dbc3c3adea22db672':
Call functions to calculate deps and classes.jar
