Re: New Build System and drawable structure

[Xavier Ducrohet]

This is orthogonal to the new build system as it's tied to aapt (which
the build system relies on).

I'd like to improve things there but it'll come later.

Could you describe your use case? Basically what do you want those
subfolders to represent?

On Fri, Oct 12, 2012 at 7:57 AM, Özcan Kaymak <o.ka...@gmail.com> wrote:
> Will we developers be able to organize drawables into subfolders with the
> new build system?
> There is also a issue filed about this: here



--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Adam Vollmer]

This is a huge want for me as well.

There are a few directions that this can take

First, what I think everyone wants, is the ability to logically sort their resources instead of dumping everything into the same directory. It can be effectively transparent to aapt; all it has to do is understand how to recurse into subdirectories from res/layout-whatever and include all of the content in there.

We've got literally thousands of resources; the ability to put lots of them into bins (e.g. store resources, player resources, misc) is a huge help for trying to sort out just what we actually have.

A second ask, which isn't really related but which I think would be really neat and useful, would be to have "base" directories for resource types, with more specific subdirectories. For example, we've got drawable, drawable-ldpi, drawable-mdpi, drawable-hdpi, drawable-xhdpi. What if we had a directory called drawable, which had subdirectories called ldpi, mdpi, hdpi, and xhdpi?

Obviously, this doesn't mesh as well with the first suggestion, but I'm spitballing, and it would help our res directories from being giant spaghetti messes

[Joe Bowbeer]

In general, I would like to be able to treat resources (and assets) as first-class dependencies.

What this means in practice, I'm not really sure, but perhaps some inspiration can be drawn from WAR overlays in Maven?

http://maven.apache.org/plugins/maven-war-plugin/overlays.html

[Xavier Ducrohet]

It might be possible to have sub folders under the main ones, but
probably not in conjunction with having drawable/ldpi.
Also it would probably be limited to one level of sub-folders.

No guarantees though, I have to see how disruptive that would be in
the tools. The impact in ADT in particular might be non-negligible.

One other thing we've been thinking about is bundles. This is to
answer another problem but we may as well discussed it here too.

There are cases where resources depend on other resources that are
likely not used on their own.
For instance, creating a custom button requires a drawable selector
that redirects to some 9-patches. The 9-patches are never used except
in the selector.
One issue is removing the selector or updating it (changing the name
of the 9-patches) but not removing the old 9-patches won't lead to any
compilation issue since (in most case) the 9-patches are used directly
by other resources or code. So the app still works but there are
obsolete resources in it.
Other examples could be custom themes which would use colors, drawables, etc...

The idea is to have a bundle (zip archive) that contains files in a
structure similar to the res folder. Those are put in the project
folder somewhere and at built time this is used as additional resource
folders (after extraction).
Of course we'd need tools to create such bundles (selector editor,
theme/style editor, etc...)

thoughts?

[Manfred Moser]

I think this is one of the perfect use cases for the android archive format.

You could e.g. have one project that only has the resources for store,
the next one for player and so on.

Each could also have the respective code and more.

Then you could basically build and application by declaring
dependencies to these different android archives (aar) and write the
glue code to stick it together

and you could even do lots of different ones.

Another use case would be a white labelled application and resource
bundles that just contain the theme and related customizations ..

Each branded app would just declare the theme and the white labelled
app as dependencies and stick it together..

Once this works the pain of having lots of resources in one project
automatically goes away..

This is already possible now with the apklib format and the android
maven plugin but the new gradle build and the aar format will make
this even more powerful (and yes the maven plugin will support that
too)..

manfred

[Özcan Kaymak]

The most simple use case would be that when you have a lot drawables (50+), it is getting quite jumbled. If you could organize this into (multiple) subfolders, it would help the developer a lot. Also, this applies to other resources as well (like layouts mostly).

[Manfred Moser]

So far I have used a naming convention for the resources btw..
suboptimal but it works.

[Xavier Ducrohet]

The issue with android archives is that there's a cost to them in the
app with multiple R classes (although we could detect no source code
and not generate it), but the dependency has an order and library
resources override resources from other libraries.

I think the proper way to have res only packages would have to detect
conflict and break the build on conflicts.

[Manfred Moser]

Sounds like a plan ;-)

You could also have a switch that causes not to generate separate R
classes for libraries that use the same package space and if there are
duplicate resources fail the build hard with an explicit message.

manfred

[Xavier Ducrohet]

I would almost prefer to have a different type of projects:
- resource only
- no manifest
- no dependencies

This would be much easier to handle those at the app project level.

[Manfred Moser]

Well.. if it makes it easier... now is the time to do it. There
definitely seems to be a need for it..

manfred

[Özcan Kaymak]

According to this issue this has been marked as "Released" and the last message says "This is largely possible in the Gradle build system as it exists today".
However I couldn't find a sample to achieve this.
Also because the message says "... largely possible ...", I would think that it isn't fully possible. What part is missing and will it (ever) be completed?

[Mark Murphy]

On Sat, Jan 4, 2014, at 11:39, Özcan Kaymak wrote:
> According to this
> issue<http://code.google.com/p/android/issues/detail?id=2018#c64>this has

> been marked as "Released" and the last message says "This is
> largely possible in the Gradle build system as it exists today".
> However I couldn't find a sample to achieve this.
> Also because the message says "... largely possible ...", I would think
> that it isn't fully possible. What part is missing and will it (ever) be
> completed?

I inquired further about that comment here:

http://code.google.com/p/android/issues/detail?id=64010

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_: Version 5.4... And
Climbing!