Using selector drawable xml doesnt work about fresco

[liaohuqiu]

I don't think selector is supported now.

[adiohaion]

I guess it's not, but if this library is to replace the ImageView (which i am surely want it to be), it will need to address this issue.

btw its not in the gotchas - http://frescolib.org/docs/gotchas.html#_

[Shailevy]

+1

It's ok not to support, especially in an initial release, but its need to be better documented. I think it's the same case xml drawables (shapes)

[plamenko]

Can you give us more context on that? Since this is not an image that is being fetched from the network / file / whatever, why don't you do this instead:

mSimpleDraweeView.getHierarchy().setPlaceholderImage(resId);
mSimpleDraweeView.setUri(null);

Then if you actually need an actual image, rather than just XML drawable, switch back again:

mSimpleDraweeView.getHierarchy().setPlaceholderImage(palceholderId OR null);
mSimpleDraweeView.setUri(uri);

[plamenko]

One important difference that one should be aware of is that Uri is used to specify an actual image that goes through the pipeline. That means fetching, caching, transcodng, resizing, postprocessing, etc.

Drawables are not those kind of images, don't confuse those two. Shape and similar drawables cannot go through the pipeline. What the pipeline does with images, doesn't apply to drawables.

One important consequence is the difference between the two when the resource is actually an image (e.g. PNG):

This will fetch the given PNG from the internal storage and cache it in our memory caches:

simpleDraweeView.setImageURI(Uri.parse("res://" + resPackage + resId));

This will inflate the BitmapDrawable via Resources.getDrawable(resId), which is subject to Android's built-in drawable cache, etc:

mSimpleDraweeView.getHierarchy().setPlaceholderImage(resId);

[plamenko]

I think it's safe to close this issue.

[adiohaion]

@plamenko, when you are using a selector in the drawable xml, you are using actual images (im not speaking about shapes). we need to be able to set images on click/selected/unselected like the platform allows (like i wrote in the first message here), and like ImageView accepts. those images might consume a lot of memory (like in my project) and are really relevant to the issue this library tries to address.

[plamenko]

The solution I provided above is as good as ImageView. In fact, it does exactly the same thing. So, you don't really lose anything by switching from ImageView.

In short, it is very unlikely that we will add a more sophisticated support for what you described.
One can specify an arbitrarily complex hierarchy of drawables in XML and parsing that XML to get to the leaf nodes that are the actual images and then rebuilding that same hierarchy, but with leaf nodes replaced with the BitmapDrawables that wrap images obtained by our pipeline seems very unfeasible. This would require us to rewrite the Android's XML inflation logic. In my opinion it's not worth the effort.

If you give us more context on what are you trying to achieve, we may be able to help you better.

[adiohaion]

Thank you for clearing that out. I will find a different way to handle it, this library is truely amazing and ill keep using it however i can.

[plamenko]

You are welcome. But as I said, if you give us more context, we may be able to devise a better way of solving your issue.

[adiohaion]

I will try to clarify. I have a custom view which dynamically construct a 5 image picker, this means there are 5 images in a LinearLayout and the user needs to pick one of them according to some question. this picker is replicated a few times (could be even 10-15 times) in a ScrollView with different kind of question for each one (so this is actually a form for the user).
When the user pick one of the images, the image is changing so it would appear selected. this is why we are using selectors in drawable xml and the function image.setSelected(true), which is very comfortable.

Saving this images in the ashmem is not super important like on other parts of the app (when we are using bigger images on larger scale), but of course could be nice to have.

[plamenko]

What kind of change happens when the image is selected? If it's some simple color manipulation (like making it darker), or adding some overlay, then this can be achieved easily with: overlayImage

[adiohaion]

It's actually a different image, and it stays that way unless the user selects a different choice in the picker. just a general question, in facebook app, do you store all images in ashmem or just the images that are consuming lots of memory?

Thanks again for all the help!

[tyronen]

Fresco stores all images in ashmem on Android 4.x and lower. On Android 5.x, they are stored in the Java heap.

[saantiaguilera]

Hi, is this dead? We might need selectors for Fresco with webp images in api<18 @plamenko

If we use ImageView it will crash because its not supported, so thats not an option.