| ec7301a7433cf89c399fa3c507afe8a147adbcba |
|
28-Sep-2012 |
Tor Norbye <tnorbye@google.com> |
Multi-Configuration Layout Editing
This changeset adds support for previewing other
configurations (as well as including contexts)
for a layout, with live updates.
Change-Id: Iff3523d6f5749b3287716e563330fb18c8576611
|
| 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
|
| 81cefe2a26dd6db8a878e30874d12cdcbff0e83b |
|
11-Aug-2012 |
Xavier Ducrohet <xav@android.com> |
More refactoring.
Move stuff out of sdklib into common and ide_common.
Remove androidprefs and move the one class into common.
Change-Id: I71d126a13cf2ba413692e29616f4968a37d7b33a
|
| 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
|
| 6feca9ac5f8add768fef2bc2dc1382a68c158d42 |
|
18-Aug-2011 |
Tor Norbye <tnorbye@google.com> |
Use Eclipse XML parser instead of JDK parser when formatting
This changeset adds a utility method which parses an XML string using
the Eclipse structured model instead of the JDK parser. The resulting
document has some extra metadata which the XML formatter can use. In
particular, it distinguishes between empty tags and tags without
children.
Now that this is fixed the formatting on project creation code
includes manifest files, which I excluded previously because it made
the <uses-sdk> element look ugly.
Change-Id: I7069fa43df33d874303435b3625f1c7b20f5b3d3
|
| 9bd5e125506d94855fa7f8dff917f20e1b4edb0b |
|
17-Mar-2011 |
Tor Norbye <tnorbye@google.com> |
Pick layout themes from manifest registrations and target SDK
This changeset changes the way the layout editor picks themes when a
layout is opened. It used to just pick the first available theme in
the theme chooser.
Now it performs the following checks, in order:
* Does this layout have a persisted theme setting from a previous run
of the tool? If yes, use it.
* Can the activity for this layout be determined? If so, look at the
manifest registration for the corresponding activity, and if it
specifies a theme, use it.
* If not, does the manifest specify a default theme for the project?
If so, use it.
* If not, is the target SDK version (or the minimum SDK version, if
the target is not specified) at least API level 11 or higher? If so,
the default theme is "Theme.Holo"
* If not, the default theme is "Theme".
* If the file to be opened is included from some other layout, use
the no-decorations versions of the default layouts, e.g.
Theme.NoTitleBar or Theme.Holo.NoActionBar.
* At the end of this resolution, the computed theme is stored as the
persisted theme setting for this layout, so the above algorithm will
only be computed once. We might want to tweak this such that it
distinguishes between a default computation of a theme and a manual
user choice of a theme.
* If the file is opened as "Show Included In" (e.g. rendered within an
outer file) then the theme chosen is the one for the outer file.
During startup, this information will be asked for each and every
layout being reopened, so there is now a "ManifestInfo" class attached
to the project which keeps manifest information around. It checks the
timestamp of the AndroidManifest.xml file and refreshes its
information lazily if necessary.
All themes mentioned in the manifest are listed in a special section
at the top of the theme chooser (below the entry for the default
computed described above).
The code to look up the associated Activity of a layout is using a
simple heuristic: it looks for usages of the corresponding R.layout
field, and prefers references from methods called onCreate or in
classes whose superclass name ends with Activity. I tried a different
approach where I searched for usages of Activity.setContentView(int)
but this failed to identify a number of cases where the activity was
doing some simple logic and didn't pass the layout id directly as a
parameter in setContentView, so I went back to the basic approach.
Change-Id: Ibd3c0f089fefe38e6e6c607d65524990699c86d3
|
| 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
|
| 026ba97e98e0527d910e15c4e1512893a777a8d2 |
|
18-Mar-2011 |
Xavier Ducrohet <xav@android.com> |
Move classes to ide-common
ResourceFolder/File and children classes (single/multi file)
ResourceItem and children classes
ResourceRepository (base and framework, project stays in ADT for now)
All the ResourceQualifiers and FolderConfiguration
Change-Id: I5adc9bdc4886a8fa0ab44860763d594cf7af4bd5
|
| 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
|
| da02c18ad5b54d97a1fcfd5f6633062b0c873c22 |
|
01-Mar-2011 |
Xavier Ducrohet <xav@android.com> |
Resource management refactoring and clean-up.
- (I)ResourceRepository is now a common class instead of an
interface. This contains most of the code to control
a repository (which was extracted from ProjectResources)
ProjectResources extends it adding minor features such as
library support, and inline ID definition.
FrameworkResources extends it adding support for public
resources (which used to be duplicated and dispersed
in weird places).
Changed the way resources are reloaded on resource change event.
Instead of marking the resources as modified (using
Resource.touch()), the resources are now parsed as the files are
processed during the resource delta visitor. This makes more sense
as there are now other listeners to the resource changes (hyperlinks)
that access the resource list in their listeners, which wouldn't work
previously.
This also makes the code cleaner as the previous method had to query
the repo for items and return a list of new ones, which was kinda
crappy. The new code is much simpler, as is the post update process.
- ResourceItem is now the base class for resource items. It includes
all the small methods that were added by all the child classes or
interfaces.
Project/ConfigurableResourceItem are merged into the based class.
IIdResourceItem and IdResourceItem are gone and replaced by a
simpler InlineResourceItem.
FrameworkResourceItem is a simple override for framework resources.
- Also improved the API of a bit for the resource repository, making
more use of unmodifiable lists and emptyList/Map()
Change-Id: Ie3ac1995213fed66153c7e7ecbdd170ec257be62
|
| cef4bf36760dd776ddab69652beee255c854283b |
|
25-Feb-2011 |
Xavier Ducrohet <xav@android.com> |
Change the FolderTypeRelationship and ResourceFile API to return list.
This is better as we can return unmodifiable list instead of
arrays that could be overriden.
Change-Id: Id473925ee6355b2bedeb2d2575bc4ca4f949acb3
|
| 868a7bbe7c5862c02483ef8f71276fc551d40d60 |
|
25-Feb-2011 |
Xavier Ducrohet <xav@android.com> |
Move ResourceFolderType into common.
Moved some constants from sdklib (which is not a dependency
of common but instead depends on common) into common.
Change-Id: I6fdfbad4e77813a9f2a2ca9ea0d740692d8bce5b
|
| c3105b949cd2a0f6cbf8a12ec4f30e49b5b5a502 |
|
25-Feb-2011 |
Xavier Ducrohet <xav@android.com> |
Rename AndroidConstants -> AdtConstants.
These are constants specific to ADT.
There'll be an AndroidConstants class in common.jar with
more generic android constant values.
Change-Id: I8368920f92c28cbfb87098087bf01f2d2cdee095
|
| 9aa538ffaf7abdcf4fe56c51da75666e60c67a90 |
|
25-Feb-2011 |
Xavier Ducrohet <xav@android.com> |
Move the sdk io classes to common.jar
Change-Id: I59a7b770071707ed058aa104bab8a16aa8950d56
|
| eaf6870a9e0f1cf2a8cc18f2904dc05c7192ac20 |
|
04-Feb-2011 |
Tor Norbye <tnorbye@google.com> |
Add support for adding non-String value resources
The ResourceChooser only supported adding new Strings. This changeset
lets you add other types of value resources -- dimensions, integers,
etc. It will create a new file in res/values/ if necessary, based on
the plural form of the resource name (e.g. for "string" resources it
will create "strings.xml", etc). For existing files, it will add a new
entry to the existing file, using the same indentation as the last
top-level element in the file.
Change-Id: I09272ff52af38a8a7a059d455f398befbe0d1abc
|
| 1f72cb7cb032538b79e79d6fc7ff3905e9766ce1 |
|
29-Jan-2011 |
Xavier Ducrohet <xav@android.com> |
Move Pair and annoatations into resources.jar now renamed as common.jar
Move all the resource query methods that returned an array of 2 Strings
to return a pair of ResourceType and String.
Change-Id: I6b8447aa27005de786e2defef81ad88a72363523
|
| 3bd45f0b16f5ebfafd8080a0f17f71d85c9840ed |
|
28-Jan-2011 |
Xavier Ducrohet <xav@android.com> |
Change APIs using String instead of ResourceType.
Move ResourceType into resources.jar so that it's accessible
to layoutlib.jar
This is cleaner and allows us to us more efficient EnumMap objects.
Change-Id: If11cbc69ae3ca8bd6c96e6d0ef402570a07af16f
|
| 54dbb36a117da8b4279bf64d684122b0afde849a |
|
12-Jan-2011 |
Tor Norbye <tnorbye@google.com> |
Warn user about compilation errors causing rendering failures
If you have certain types of errors in your project, then rendering
will fail with messages that may be confusing.
This changeset attempts to identify some of these common scenarios and
offer detailed explanations to guide the user in the right direction.
Specifically:
1. If the project contains aapt errors (which means aapt did not run
successfully), AND the rendering failed with an error related to
resource lookup, then begin the render error message with an
explanation in bold that this project contains resource errors that
could explain the below rendering errors, and to investigate those
resource errors first.
2. If the project contains javac errors, AND the rendering failed
after the custom project class loader has been consulted, then
display a message stating that compilation errors could have
caused the failure and to investigate those errors first.
3. If a custom view is loaded, and it does not provide a 2- or 3-
argument constructor (which takes an AttributeSet), emit a warning
that XML attributes on the view will not work.
In addition, this changeset cleans up a few other related things:
- Tags are no longer displayed as part of the error message; these are
intended for internal checking only (for example to identify
resource errors from other errors)
- The error display text can now show a vertical scrollbar if the text
is longer than the available space.
- The code which marks the project class loader as used is marked used
as soon as it's asked to resolve a class name, rather than at the
completion of a successful load, since we want to know about failing
custom classes as well.
Change-Id: Ib37a329eed44719ecf741b96ff96747ec4f92ad0
|
| d99f34325d9d2ace6968d6f46b57f5e5bf773e31 |
|
24-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Fix error in include cycle detection
The code to detect cycles in include dependencies was wrong; it would
incorrectly identify some valid DAGs as having a cycle. We don't
necessarily have a cycle just because we encounter a node we've
already seen; it is only a cycle if we encounter a vertex that we are
currently visiting further back in the depth-search.
Change-Id: I3149c80d54258e6fff4cb0a0b1a3cefcb1db56f2
|
| c628731aff0ceaef8deee198f8e9956396ff7855 |
|
18-Dec-2010 |
Raphael Moll <ralf@android.com> |
Fix NPE when deleting a layout resource file.
The IncludeFinder tries to read the file, but the workspace
is not in sync so although the resource exists in the
workspace there is no XML file to read anymore.
Change-Id: If0ca5cca8e6978f1777531d6413d7c30a54c9d7d
|
| 2f70fafe0bc1cf6d14cb35241ca252ca3cbe5674 |
|
16-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Fix non-externalized-string references
I had accidentally used //NON-NLS- instead of //$NON-NLS- in some
code. That explains why Eclipse would sometimes insert a space
between the // and the NON part...
This changeset replaces these with proper //$NON-NLS- entries.
Change-Id: Icf4251a352895293ebe82d8207a4dbfe7d8126d5
|
| ae5f1f7f6a5ef8a0b4ca037524c3cd3209343144 |
|
15-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Fix model locking
Fix the bug where editors sometimes can't be reopened due to an
assertion in the XML model. The IncludeFinder code I added last week
had a mismatch between the type of lock acquired (an edit lock) and
the lock released (a read lock).
Change-Id: I2d3053ec4e9d1efba62ab0f3216d15f738192ddd
|
| 1714fd536b42f9963c00e171a9d04319832564f2 |
|
09-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Add support for including within specific configurations
The current support for includes are limited to including a view
within the "base" layouts (defined in layouts/). This changeset
generalizes this to track ALL include-sources (such as an include from
the landscape version) and offers to let you view and edit the current
view within each of those specific configurations. The configuration
will be switched to one that is compatible with the outer, including
view. It is possible that this will switch to a different inner view;
that seems better than trying to force editing an inner view in an
outer view that won't actually be shown at runtime.
We should enhance the configuration chooser such that it will only
offer options in its various combo boxes that are compatible with the
inner view as well. That is not addressed by this changeset.
Change-Id: Id5171d367cf65e2403bbac1640a179de4b420bd6
|
| 2a58932d3c4e2642cbdbfc161b4f7b884b3d7ea6 |
|
04-Dec-2010 |
Tor Norbye <tnorbye@google.com> |
Add a hyperlink resolved for Android XML files
This changeset adds basic hyperlink handling to Android XML files
(such as AndroidManifest.xml and layout xml files).
It registers a hyperlink detector for our XML files, and the hyperlink
detector looks up the XML model and finds the node and attributes
under the cursor. If found. it then checks these attributes for a set
of patterns that it can link to:
* If it finds an <activity> element, it looks up the activity name and
the package on the root element, and lets you jump to the activity.
Ditto for services.
* If it finds a @layout attribute value, it attempts to open the
corresponding layout file in the res/ folder in the project. Ditto
for other per-file resources like @drawable, etc.
* If it finds a value resource, like @string, @dimen, etc, it will
search through the various XML files in values/ and open up the
corresponding XML declaration in the editor with the declaration
selected.
Note that the resolver does NOT use proper full resource resolution
based on the SDK parsing that we have in use within the layout editor
etc. That's the natural next step.
Change-Id: I5880878fe67f26fb8d3b08b808c02baa1049f2c5
|
| 4517a1f5f4f9fd21b6a611d8a40ac8b81a7bb9c5 |
|
29-Nov-2010 |
Tor Norbye <tnorbye@google.com> |
Include View Support
Add improved support for includes. You can now view and edit a layout
within another containing layout. On a page with includes, you can
double click to warp into the included layout, and it will be shown
within the container layout (but with a semi-translucent mask to make
it obvious that you are editing only the included content, not the
container.)
You can also right click on a view and choose "Show Included In",
which is a pull-right which lists all the other layouts that are
including this view. (If there are no such views, the menu item will
be empty).
In addition, this changeset adds code to detect if there are cycles in
the includes, and if so adds a problem marker in the Problems view
listing the offending chain of includes.
This is all managed by a new "IncludeFinder" class, which listens for
resource file edits (so it only kicks in when you save an XML file,
not after each XML edit). It scans layout XML files for includes and
maintains a map of file includes. This is done such that it can very
quickly provide a list of all files that are including a given target
file. This list is also persisted across IDE sessions via a project
property.
Also fixes outline-expansion to ensure that the outline always shows
the top level children.
Note: The include-relationships are based on the base layouts (the
ones in layouts/, not in customized versions in layout-land,
layout-port, etc.)
Change-Id: I710560f03f7e214219669af8ffba91874d9881b9
|