This is closely related to #425 but I thought it was better to separate them as I wanted to discuss a solution thats specific to this.
getMeasuredWidth() and getMeasuredHeight() will always be zero for a WRAP_CONTENT dimension. Meaning the query is deferred indefinitely.
I'm happy to make a pull request for this but I'm unsure which route I should take. Options that I see include:
1) Throw an exception for making such a request (fit() on an ImageView with a LayoutParam of WRAP_CONTENT)
2) Forget about deferring the request because we're still "fitting" into a WRAP_CONTENT view, so I can just do a check and ignore the deferred, pulling the entire image into the View.
3) This is user error and we should ignore it? It seems #365 might be an option as to how the user could work around it when they only have one dimension. But wouldn't work if both dimens are WRAP_CONTENT and it requires the user to know the API..
(2) has the benefit that it should fix #425
Open to other ideas and I'll be happy to whip up a pull request.
I don't think we can do anything about this. You can't know the logic inside the view's onMeasure
so the what the LayoutParams
declare may have little-to-no effect on determining whether the view will ever have a size or not. Granted, in most cases we can infer that the wrong behavior will happen but I don't think we can generalize it.
The only option I see being viable would be to log a warning if the app's debuggable flag is set to true.
Oooh. A custom ImageView that does it's own thing with WRAP_CONTENT
. I never thought about that. That is a bit of an edge case but certainly one we should consider.
I wish there was a way to generalize it. Possibly setting a max limit on how long you can defer? That sounds kind of kludgy though.
If I don't come up with any better suggestions, I think I'll put together a pull request this weekend for at least the warning log you mentioned.
A max wait time is also interesting. I'll have to think on this a bit. I really like the idea of preventing people from doing the wrong thing, though.
One more thing, what about attaching to one of the layout listeners (off of getViewTreeObserver()
)? We have the target ImageView so that should be possible. And we'd be able to know if the measured width/height is non-zero after a layout pass.
I haven't spent much time with the inner workings of Picasso so just spitting out what comes to mind :-)
Yep. We use a ViewTreeObserver
now but could look at changing it's behavior to indicate when this happens.
I got the same "issue". Actually I am using a work-around to reach the "wrap_content". Picasso.with(context)
.load(picToLoad)
.placeholder(R.drawable.placeholder)
.error(R.drawable.errorplaceholder)
.fit()
.centerInside()
.into(target);
android:layout_width="wrap_content"
android:layout_height="match_parent"
android:layout_alignParentRight="true"
android:adjustViewBounds="true" />
The placeholder drawable is a big picture (white jpg, light weight). So it's filling the imageview to its parent and when the wanted picture is loaded, it will be scaled as desired, applying adjustViewBounds as well.
This is not a solution but it's doing the trick .
I think the solution would be in the "defer" process after the placeholder is placed.
I have something to propose.
What about getting the parent's measuredWidth and measuredHeight when setting the placeholder?
Issue is that the loaded image is resized to the placeholder's width and height. I was trying using the default ic_launcher and the loaded image was resized to the ic_launcher drawed size (not filling parent view).
Modifying onPreDraw code (class DeferredRequestCreator) and into(ImageView target, Callback callback) (class RequestCreator) in the deferred statement giving the data.resize() the target parent's width and height, it's applying the right sizes.
@fvitullo That's easily broken in layouts where the child ImageView
doesn't occupy the full size of the parent.
Yes, it's working with a fixed size container. Im thinking about a way to improve this solution.
@fvitullo Updates on this? Is this something we would want supported by Picasso or just a special case?
@dnkoutso Not yet. That approach is working for a special case: a container with an ImageView inside with "match_parent" - "wrap_content" width/height (or viceversa).
Hi all,
I have problem at my project stil. I have an imageview same as below:
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:contentDescription="@string/app_name"
android:scaleType="center" />
If images size bigger, imageview not displaying even waiting so long time. Please can you explain how to solve this problems.
@mstfchelik have you tried Picasso 2.4? I think this is fixed.
@mstfchelik also try Picasso 2.5.0 now. Closing.
@dnkoutso I still encounter this problem when using Picasso 2.4. Which commit fixed this issue?
Did you try Picasso 2.5?
@dnkoutso Yes, it is the same as 2.4.
I also have this issue in 2.5.2.
I also still have this in 2.5.2.1 ..
I have this issue in 2.5.2
IMHO https://github.com/square/picasso/blob/303366b749b2b58ea3a1561ff64e093941ebfbbd/picasso/src/main/java/com/squareup/picasso/DeferredRequestCreator.java#L69
is responsible for this behavior.
What if we change it to
((width <= 0 || height <= 0) && !target.getAdjustViewBounds()) || target.isLayoutRequested()
?
In my project ImageView layout_width/layout_height = match_parent/wrap_content
, the image does not fit in ImageView. It locates center in view and smaller than original size. @cdbkr solution is working. The other way If ImageView layout_width/layout_height
(match_parent both of them) and adjustViewBounds
(true) attributes set are acceptable for your project, it will work.
Most helpful comment
I have this issue in 2.5.2