Resource Override Clarification

Say I have the following directory tree:

resources/drawables/launcher_icon.png
resources/drawables/drawables.xml

Now for a specific device, I want to use a different png:

resources-whatever/drawables/launcher_icon.png

I compile for my whatever device, but it still uses the original image. Huh. Ah, but I access the image via the <bitmap> in drawables.xml, and it's seeing the regular drawables.xml in the normal resources directory, which refers to the original image. Fine. I verify this by copying the original drawables.xml in resources-whatever:

resources-whatever/drawables/launcher_icon.png
resources-whatever/drawables/drawables.xml

And everything works as expected, getting the device specific image, but now if I make a change to the original drawables.xml, I need to propagate that change throughout any copies of it. Ugh. Ah, I think, I'll just symlink the device specific drawables.xml to the original and thus avoid the duplication problem, so now I have:

resources-whatever/drawables/launcher_icon.png
resources-whatever/drawables/drawables.xml -> ../../resources/drawables/drawables.xml

...but this doesn't work as expected. In this case I just get the original behaviour. It seems like the compiler is resolving the symlink and processing it as if we're in the target directory, which is where the original image resides, so we get that one.

Is this what is going on? Is there some way of resolving this type of situation without just having multiple copies of your xml files in different directories, because that is horrible.

Top Replies

FlowState 2 days ago +1 verified

tim_angus said:
Is there some way of resolving this type of situation without just having multiple copies of your xml files in different directories, because that is horrible.

No, you do have to have a…

All Replies

+1 FlowState 2 days ago

tim_angus said:
Is there some way of resolving this type of situation without just having multiple copies of your xml files in different directories, because that is horrible.

No, you do have to have a resource xml file in the resource override folder. When you reference an image via <bitmap>, the compiler won't try to look in other folders, as you've found. I think this kinda makes sense, as technically speaking, "resources" are the elements that are defined in the resource XML files.

tim_angus said:
now if I make a change to the original drawables.xml, I need to propagate that change throughout any copies of it.

Does this change pertain to the <bitmap> element which references launcher_icon.png?

If so, that's unavoidable.

If not, then the solution is separate out the stuff which doesn't pertain to launcher_icon.png, so it doesn't have to be duplicated.

e.g.

resources/drawables/drawables.xml (non-launcher-related drawables xml)
resources/drawables/launcher_icon.xml (launcher-related xml)
resources/drawables/launcher_icon.png

resources-whatever/drawables/launcher_icon.xml
resources-whatever/drawables/launcher_icon.png

0 tim_angus 2 days ago in reply to FlowState

Right, thanks, that confirms what I thought. Like many, many CIQ things, it's a frustrating solution to the problem. Like, it's a fundamentally good idea, but the implementation is not good. How it should work is to have a single virtual file system, whereby more qualified files override lesser qualified files, and there is one view of the world such that xml files referring to other assets get the overridden version of every file, regardless of which directory the file lives in. Indeed this is the intuitive way it would work, and the way every other comparable system I have ever used works.

Sigh.

0 FlowState 2 days ago in reply to tim_angus

tim_angus said:
Like many, many CIQ things, it's a frustrating solution to the problem. Like, it's a fundamentally good idea, but the implementation is not good.

I hear ya. Believe me, I have felt the same way many, many times. When I said it kinda makes sense, I was pretty much playing devil's advocate haha.