| e50549f54810c29bffc681e39d33158ab2a8f26e |
|
10-Jan-2012 |
Raphael <raphael@google.com> |
ADT: Change LayoutEditor to use new editor delegates.
Change-Id: I5624d8f5c393a74a808d98e465f0ebc6db91d741
|
| 0757ce4af2764e4dd564acc0b1a013e910abc8da |
|
18-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
More refactoring work: Convert hierarchy, and change type
A lot of work on the "Change Layout" refactoring to improve conversion
to a Relative Layout. First, add a "Flatten Hierarchy" option which
can take an entire hierarchy of layout widgets and flatten it down to
a single top level RelativeLayout where the constraints attempt to
reflect the original layout. (This isn't always possible, since some
layout managers offer features not possible to express in
RelativeLayout, such as a LinearLayout with multiple different
weights) but it often works or is at least a good start. (This work
is ongoing, but since my changeset is getting large I want to check in
this snapshot since the functionality is better than what is in the
trunk.)
This changeset also adds a new refactoring: Change Widget Type. This
can be applied to a selection of elements, and it will convert the
widget type to the new target widget type. It will also remove any
attributes that are not valid for the new layout.
It also improves the wizards which display the possible target types.
For Change Widget Type, it will first offer "related" widgets, so for
an AnalogClock it will first offer Digital Clock, for a checkbox it
will offer a checked text view and a radio button, etc.
In addition, it will list Views and Layouts that it finds in any
library jars (except for the builtin Android ones), and any custom
view classes in the project.
There is also now some preliminary support for refactoring unit
tests. These tests must be run as Eclipse plugin tests, since they
utilize the XML model (and the XML model cannot be mocked). The test
infrastructure reads source XML files, applies the refactoring change
list to them, and diffs the output with the known expected output
(also stored as result XML files in the test project).
Finally, there are a number of fixes and improvements to the shared
refactoring code.
Change-Id: I0974653e530dfb4feb625e0eef8257c29d50614b
|
| 8dc4366bbaad39d56e1c2ded4046c86a95a17666 |
|
14-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Refactoring: Wrap in Container, Change Layout Type, Extract
This changeset adds refactoring support for 3 visual refactoring
operations:
(1) Wrap in Container. This can be invoked on one or more sibling
views (or the root view) to add a new layout container into the
hierarchy which "wraps" the views. The refactoring can also update
the layout attributes (such as RelativeLayout attachments) such
that they refer to the new container instead. If invoked on the
root element, the namespace declarations are migrated from the old
root to the new root.
(2) Change Layout. This can be invoked on a layout view to change the
type of layout. In addition to editing the XML type declaration,
it also removes layout parameters that no longer apply, and
depending on which layout you are converting from and converting
to, it may attempt to perform some translation to preserve the
layout characteristics. In particular, if you convert from a
LinearLayout to a RelativeLayout, then it will use RelativeLayout
params to emulate the old LinearLayout by attaching items below
(for vertical layouts) or to the right of (for horizontal layout)
the previous sibling, and if the baseline property was set on the
LinearLayout it will also add baseline constraints on the
RelativeLayout. (It also adds default ids on any elements that
need it.)
There is a LOT more we can do to support layout transformations;
this is just a beginning.
(3) Extract as Include. We already had this feature, but it performed
its own XML document manipulation. This code has been rewritten
to use the Eclipse refactoring support (which the other two
refactorings are implemented to use as well), which among other
things means that you get Preview support - you can press Preview
from the refactoring dialog to see the edits before they are
made. This rewrite is also necessary to support an upcoming
feature: the ability to replace occurrences in other
configuration-variations of this layout; for that we need to
ability to do multi-file changes which the refactoring support is
ideal for.
Change-Id: I50b142645f14c29c798fc02df6df69bad5b9426c
|