| 12d4581faa6438941e65a9dc83213be34c6ca970 |
|
13-Sep-2012 |
Tor Norbye <tnorbye@google.com> |
Constants refactoring.
This changeset moves most constants into the SdkConstants
class, and gets rid of AndroidConstants and LintConstants.
It also migrates all non-ADT specific constants from
AdtConstants into SdkConstants. It furthermore moves various
other constants (such as those in XmlUtils and ValuesDescriptors)
into the constants class. It also fixes the modifier order
to be the canonical modifier order (JLS 8.x).
Finally, it removes redundancy and combines various constant
aliases such that we don't have both NAME_ATTR and ATTR_NAME
pointing to "name", etc.
Change-Id: Ifd1755016f62ce2dd80e5c76130d6de4b0e32161
|
| 85e4a1a9dd133abb879ec211ce8dd385004edf22 |
|
08-Aug-2012 |
Xavier Ducrohet <xav@android.com> |
Refactor common.jar
Move resources and com.android.util.Pair into layoutlib_api
where they belong since layoutlib depends on them and we need
to control the API.
Made a copy of Pair to stay in common.jar but moved it to
com.android.utils.Pair (the one in com.android.util.Pair is
marked as deprecated to prevent usage where applicable).
Also moved XmlUtil and PositionXmlParser to com.android.utils
to match Pair.
Change-Id: I21d7057d3f2ce604f86a3bb1fa3c130948c93b89
|
| e50549f54810c29bffc681e39d33158ab2a8f26e |
|
10-Jan-2012 |
Raphael <raphael@google.com> |
ADT: Change LayoutEditor to use new editor delegates.
Change-Id: I5624d8f5c393a74a808d98e465f0ebc6db91d741
|
| ab36f4e7488358dea4ab6b54ee2b7bef3da0232b |
|
21-Dec-2011 |
Tor Norbye <tnorbye@google.com> |
Update SDK codebase to JDK 6
This changeset makes the SDK codebase compile with source=1.6 (which
means it also requires JDK 6). This means that methods implementing an
interface requires @Override's. It also means we can start using APIs
like the ArrayDeque class and methods like String#isEmpty().
This changeset looks big but the change is trivial: it's basically
adding @Override in all the places that need it, along with some other
automatic Eclipse cleanup in certain files (such as reordering imports
where they were incorrectly ordered (because older versions of Eclipse
didn't always handle inner classes right)), as well as cleaning up
trailing whitespace and removing some $NON-NLS-1$ markers on lines
where there aren't any string literals anymore.
This changeset also sets the source and target JDK level to 6 in the
Eclipse compiler .settings file, and synchronizes this file to all the
other Eclipse SDK projects.
Change-Id: I6a9585aa44c3dee9a5c00739ab22fbdbcb9f8275
|
| 42b2f34604a3f8e8ac191831d8f01a0498760d38 |
|
09-Jun-2011 |
Tor Norbye <tnorbye@google.com> |
Fix various warnings
I ran the latest version of findbugs on our codebase and fixed some
(not all!) of the warnings.
I also ran with Eclipse 3.7 RC3 and updated our compiler warning
settings for the new warnings that are available.
I also fixed some DOS line endings in some files (formatted with CRLF
instead of LF).
Change-Id: I9a9d34a9b60f2cb609245793815d96a4587007b0
|
| 4563c4e2f168df1d6c97206a4ac6444dfa2264ba |
|
17-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
Add custom views and third party views to the palette
This changeset adds a new category to the palette, "Custom & Third
Party Views", which is populated with android.view.View subclasses
found in the current project (or any of its libraries), and in any
jars included by the project. They can be dragged directly to the
canvas, and control clicking on the palette entries will jump to the
source.
There are a bunch of adjustments in various places to make working
with custom views better - from ensuring that we don't use fully
qualified class names in default ids, to showing the Java class icon
for custom views in outline and elsewhere, to making zero-sized view
highlight and expand when selected like we do for laoyuts - since with
custom views it's quite easy to end up with an "invisible" view that
you can't see after dropping it.
There are also some fixes to the code which looks up third party and
custom views (which was already used by the Wrap In refactoring) - to
handle inner classes, to filter out non public or abstract classes,
and most importantly to only include views reachable from the current
project (since the view search necessarily is workspace wide.)
Change-Id: If1d8c7e5c7dd907a68d8d0962e85c5144e911503
|
| 9e6db060854d0e890190919a27a1846f50f69d1a |
|
07-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
Extract as Include support for configuration variations
First, add support for the "Extract as Include" refactoring to update
all identical code fragments in configuration variations of the same
file. For example, if you have a particular subtree of XML elements
in a file that you have then duplicated into say a landscape mode,
then applying the Extract as Include refactoring will locate the same
code fragment in both files, and replace *both* code fragments with an
include (and this is optional with a checkbox in the wizard
dialog). This only happens when the extracted code fragment is
"identical" in both files. The code fragments can vary in terms of XML
formatting and attribute order (and namespace prefix choice), but the
element hierarchy order, names, attributes defined and attribute
values must be identical.
Second, make fixes to the Change Layout and Change Widget Type
refactorings such that when the id of the converted element is
changed, then references to that id are updated as well.
Third, ensure that the refactorings are enabled even when there is no
text selection; in that case the refactoring will apply to the element
containing the caret.
Some test infrastructure improvements.
Change-Id: Idb4ba40f4217dba2b13881b3d06e269c80ba4b97
|
| adee9788a5ac646a39b516abe4cdd1022911a3f5 |
|
09-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
Add drop-support for include tags
Add the include tag back into the palette, and add special drop
support for it such that when it is drop, a resource chooser pops up
and asks you which layout to include. A new validator prevents any
layouts from being chosen that would result in a cyclic
dependency.
This requires some infrastructure changes: First, drop handlers must
distinguish between a view getting created as part of a previewing
operation and getting created interactively. Second, in order to
support cancel removing an inserted include if the user decides not to
set an include, the node wrappers need to support removing an element.
Also, use the metadata originally intended for the preview icon
factory to also bypass palette drag previews for widgets that don't
have UI.
Change-Id: I1bdd1766ca4cfa2fdbca25b77c50c74e9c332cbd
|
| 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
|
| e5fa05d3e4a7d9c002dff713d88456fd9e5a7965 |
|
23-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Tweak resource name validator, move code around
Incorporate some feedback from
https://review.source.android.com//#change,21341
Disallow uppercase chars in file-based resource names
Change-Id: I078b30be64e1aeb984f26d5c8b2976aa0083fcf4
|
| 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
|