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.kay...@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
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
On Fri, Oct 12, 2012 at 11:35 AM, Xavier Ducrohet <x...@android.com> wrote:
> 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.kay...@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
On Friday, October 12, 2012 8:35:51 AM UTC-7, Xavier Ducrohet wrote:
> 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<javascript:>> > 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
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...)
On Fri, Oct 12, 2012 at 9:16 AM, Adam Vollmer <volmar...@gmail.com> wrote:
> 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
> On Fri, Oct 12, 2012 at 11:35 AM, Xavier Ducrohet <x...@android.com> wrote:
>> 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.kay...@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
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)..
On Fri, Oct 12, 2012 at 11:49 AM, Xavier Ducrohet <x...@android.com> wrote:
> 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?
> On Fri, Oct 12, 2012 at 9:16 AM, Adam Vollmer <volmar...@gmail.com> wrote:
>> 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
>> On Fri, Oct 12, 2012 at 11:35 AM, Xavier Ducrohet <x...@android.com> wrote:
>>> 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.kay...@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
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).
On Fri, Oct 12, 2012 at 4:08 PM, Özcan Kaymak <o.kay...@gmail.com> wrote:
> 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).
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.
On Fri, Oct 12, 2012 at 3:59 PM, Manfred Moser <mosa...@gmail.com> wrote:
> 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
> On Fri, Oct 12, 2012 at 11:49 AM, Xavier Ducrohet <x...@android.com> wrote:
>> 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?
>> On Fri, Oct 12, 2012 at 9:16 AM, Adam Vollmer <volmar...@gmail.com> wrote:
>>> 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
>>> On Fri, Oct 12, 2012 at 11:35 AM, Xavier Ducrohet <x...@android.com> wrote:
>>>> 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.kay...@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
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.
On Fri, Oct 12, 2012 at 5:55 PM, Xavier Ducrohet <x...@android.com> wrote:
> 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.
> On Fri, Oct 12, 2012 at 3:59 PM, Manfred Moser <mosa...@gmail.com> wrote:
>> 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
>> On Fri, Oct 12, 2012 at 11:49 AM, Xavier Ducrohet <x...@android.com> wrote:
>>> 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?
>>> On Fri, Oct 12, 2012 at 9:16 AM, Adam Vollmer <volmar...@gmail.com> wrote:
>>>> 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
>>>> On Fri, Oct 12, 2012 at 11:35 AM, Xavier Ducrohet <x...@android.com> wrote:
>>>>> 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.kay...@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
On Fri, Oct 12, 2012 at 8:48 PM, Manfred Moser <mosa...@gmail.com> wrote:
> 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
> On Fri, Oct 12, 2012 at 5:55 PM, Xavier Ducrohet <x...@android.com> wrote:
>> 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.
>> On Fri, Oct 12, 2012 at 3:59 PM, Manfred Moser <mosa...@gmail.com> wrote:
>>> 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
>>> On Fri, Oct 12, 2012 at 11:49 AM, Xavier Ducrohet <x...@android.com> wrote:
>>>> 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?
>>>> On Fri, Oct 12, 2012 at 9:16 AM, Adam Vollmer <volmar...@gmail.com> wrote:
>>>>> 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
>>>>> On Fri, Oct 12, 2012 at 11:35 AM, Xavier Ducrohet <x...@android.com> wrote:
>>>>>> 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.kay...@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
On Fri, Oct 12, 2012 at 8:57 PM, Xavier Ducrohet <x...@android.com> wrote:
> 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.
> On Fri, Oct 12, 2012 at 8:48 PM, Manfred Moser <mosa...@gmail.com> wrote:
>> 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
>> On Fri, Oct 12, 2012 at 5:55 PM, Xavier Ducrohet <x...@android.com> wrote:
>>> 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.
>>> On Fri, Oct 12, 2012 at 3:59 PM, Manfred Moser <mosa...@gmail.com> wrote:
>>>> 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
>>>> On Fri, Oct 12, 2012 at 11:49 AM, Xavier Ducrohet <x...@android.com> wrote:
>>>>> 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?
>>>>> On Fri, Oct 12, 2012 at 9:16 AM, Adam Vollmer <volmar...@gmail.com> wrote:
>>>>>> 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
>>>>>> On Fri, Oct 12, 2012 at 11:35 AM, Xavier Ducrohet <x...@android.com> wrote:
>>>>>>> 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.kay...@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
