R.java should recognize resources in sub-directories [37009920]

Infeasible

Feature Request

[AOSP] duplicate

[AOSP] Released

Migrated-Tools-Gradle

Migrated-Tools-Studio

[AOSP] assigned

Migrated-Tools-Core Studio

Status Update

No update yet.

Description

dw...@gmail.com

created issue #1

Nov 11, 2014 05:04AM

Hello,

I just tested the feature introduced in this issue (marked as released), but it's not working:

https://code.google.com/p/android/issues/detail?id=2018

Problem:
I have a subfolder inside the "drawables" folder and the assets in that subfolder are not accessible via the R class.

I'm using Android Studio (beta) 0.8.14

Thanks

Comments

xa...@android.com <xa...@android.com> #2Nov 11, 2014 09:53PM

We allow having different res folders, but not subfolders under each res/<foo>/ folder.

dw...@gmail.com <dw...@gmail.com> #3Nov 11, 2014 10:27PM

Hello,

In the

Issue 36907008

that I linked there is an example that explains that the idea is to have things like "/res/drawable/group1/image2.png".

So according to what #2 says, that is not possible yet. So that Issue should not be in the Released state, right?

I don't know if I'm missing something here, but if I'm wrong could you point me to some docs about this feature?

je...@google.com <je...@google.com> #4Apr 7, 2015 08:06PM

Assigned to cm...@google.com.

this needs to be sorted out. Xav (and myself) think it's not implemented, yet Scott seems to think the feature is present. I also think there another similar bug, they should be merged.

zy...@google.com <zy...@google.com> #6Jul 14, 2016 05:26PM

Status: Won't Fix (Obsolete)

Thank you for reporting this issue. At this time it appears this feedback is no longer relevant with the latest version of Android Studio. If you continue to experience this issue please open a new bug and we can reinvestigate.

is...@gmail.com <is...@gmail.com> #7Jul 14, 2016 06:12PM

Is there an alternative? Or why isn't relevant?

cm...@google.com <cm...@google.com> #8Jul 25, 2016 09:16PM

Status: New (reopened)

Closed in error.

[Deleted User] <[Deleted User]> #9Jan 29, 2018 09:57PM

This is problematic for so many reasons. Please just copy the iOS model and let assets be tagged in the filename image@360dpi.png or something, and also have paths. Currently design tools have to strip the paths, lowercase the names, and all sorts of hard-coded organization into Android's res folders.

This would help design tools generate the files where the user wants them. If you have a small project, this keeps all the resources in a single folder for review in the system Files/Thumbnail view. Uses would have to resolve duplicate assets by specifying more of the path.

je...@google.com <je...@google.com> Jan 16, 2019 05:19PM

Assigned to im...@google.com.

im...@google.com <im...@google.com> #10Mar 20, 2019 06:23PM

The way you can use multiple groups of resources within one resource type is by using different source-sets.

For example, you say you'd like to have:
- /absolute/path/to/app/src/main/res/drawable/group1/image1.png
- /absolute/path/to/app/src/main/res/drawable/group2/image2.png
- /absolute/path/to/app/src/main/res/drawable/image3.png

Instead of nesting the group under the resource folder, you can specify multiple source-sets:
- /absolute/path/to/group1/res/drawable/image1.png
- /absolute/path/to/group2/res/drawable/image2.png
- /absolute/path/to/app/src/main/res/drawable/image3.png (the original resource set)

Then in your build.gradle file you can add these new source sets to the current resource sets list:
android {
compileSdkVersion 28

sourceSets {
main {
res.srcDirs += [' /absolute/path/to/group1/res/', ' /absolute/path/to/group2/res/']
}
}
}

Would this solution work for you?

im...@google.com <im...@google.com> #11Mar 20, 2019 06:24PM

Note: if you define a file with the same name and type in different source sets it won't be an error - but the override will be applied according to the order of the source sets.

sa...@gmail.com <sa...@gmail.com> #12Apr 26, 2019 09:58AM

The problem isn't bringing in multiple source paths, the problem is not supporting path hierarchies in the Android view in AndroidStudio and in the R. autogenerated system.

The current system is the developer analog of keeping all of your data files saved to the Desktop. For a few files, it's convenient and manageable but the moment you have any large or complex organization (and this is especially true for the same file name and type in different folders) it becomes unwieldy. Folder systems were created to address this problem in the first place.

Real-world example:
I'm making a solitaire game and I want to have more than one deck face. I should be able to have this

/deck1/Ace.png
/deck2/Ace.png
/deck3/Ace.png

Then, when loading resources, I only need to change the starting path to access the resource. Hardcoded it would be R.drawable.deck1.ace, R.drawable.deck2.ace...

Yes, I could keep them in separate system folders and add multiple srcDirs but, as

comment #11

indicates, this will only give me access to one of the duplicates, both through R. and through the Resources list in the layout designer.

This isn't even to mention the incredibly long list under the drawable tree item in the Android view that, in my case, has a sub-folder for each card (e.g "Ace (2)" with two "Ace.png" entries underneath).

lu...@google.com <lu...@google.com> Oct 15, 2021 02:57PM

Reassigned to lu...@google.com.

lu...@google.com <lu...@google.com> #13Apr 22, 2024 10:29AM

Status: Won't Fix (Infeasible)

After an internal feasibility study on the feature, we have decided not to add resource folder sub-directories.

Many tools rely on the structure of the R class. This would be a very significant breaking change which would break 1st and 3rd party build tools. Changing the R class structure internal in AGP is a considerable amount of time and effort. Other potential implementations were also investigated, such as incorporating sub-directory names into resource names themselves, however this would lead issues such as resource name clashes. Allowing custom resource qualifies was also explored, but this makes project resource management more challenging. examining the feature request itself, resource sub-directories would likely encourage poor project structure such as not creating new project modules and instead creating monolithic modules; leading to worse build performance.

Ultimately, this issue is related to better organisation of related Android resources. If you feel the need to organise related resources in your project, it may be a sign to add a new library module with these resources. Project view search is also a powerful feature for navigating modules with many of a type of resource resources.

Message last modified on Apr 22, 2024 10:30AM

lb...@gmail.com <lb...@gmail.com> #14Apr 22, 2024 10:44AM

@13 How should an SDK/module/library have files that whoever uses it - the files won't be overridden and won't be auto-suggested by the IDE when reaching R ? A layout XML file? A Drawable file? Even strings?

The more of these that you use, the more chance for it to happen and the more junk the IDE will offer to auto-suggest for you.