Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[iOS][Image Rendering][ResourceResolvers] BackgroundImage is not filled properly when set second time #4667

Closed
akaashdev opened this issue Aug 26, 2020 · 4 comments
Labels
Bug Partner-CiscoWebEx Bugs impacting CiscoWebEx integration scenarios Platform-iOS

Comments

@akaashdev
Copy link
Contributor

Platform

What platform is your issue or question related to? (Delete other platforms).

  • iOS

Version of SDK

v1.2.11

Details

BackgroundImage seems not fill properly when set the second time on an imageView passed via ResourceResolver. We generally set a placeholder image first until the original image gets downloaded. So, when the original image tries to replace the placeholder, it doesn't follow proper filling.

IMG_3092

Also, the icon images doesn't fill properly too.

Mac version of same card

Screenshot 2020-08-26 at 7 41 14 PM

card-details.zip
Attached the card payload and images in this zip.

@akaashdev akaashdev added the Bug label Aug 26, 2020
@ghost ghost added the Triage-Needed label Aug 26, 2020
@jwoo-msft jwoo-msft added Partner-CiscoWebEx Bugs impacting CiscoWebEx integration scenarios Platform-iOS labels Aug 26, 2020
@jwoo-msft
Copy link
Member

jwoo-msft commented Aug 26, 2020

@akaashdev
This is similar to #4650, #4585, and possibly #4665

When an UIImage is set to an UIImageView, it will notify the observer and the observer sets the constraints on the UIImageVew based on UIImage's size attributes. After the notification happens, the observer is removed, and no further notification will be generated. So if you used the observer for placeholder image, there will be no notification for the real image, so the constraints won't be proper likewise.

If the use of the placeholder image is a requirement, this issue, #4650, #4665, and #4585 will be a feature request since your scenario is not supported.

@akaashdev
Copy link
Contributor Author

akaashdev commented Aug 27, 2020

@jwoo-msft
Use of placeholder image is definitely a requirement for us. The logic is to have a placeholder image, matching the dimensions of the original image, set before the original image comes in. This is to avoid the change in the card's height. We run into performance issues and sometimes in crash scenarios when the heights of the card (inturn the height of the cell) changes frequently.
And yea, if there is any other way to tackle the height changing issue, we're happy to give it a shot. But still, we would prefer using a placeholder image shown first, as it sort of gives a visual feedback of an image being downloaded.

@jwoo-msft
Copy link
Member

@jwoo-msft
Use of placeholder image is definitely a requirement for us. The logic is to have a placeholder image, matching the dimensions of the original image, set before the original image comes in. This is to avoid the change in the card's height. We run into performance issues and sometimes in crash scenarios when the heights of the card (inturn the height of the cell) changes frequently.
And yea, if there is any other way to tackle the height changing issue, we're happy to give it a shot. But still, we would prefer using a placeholder image shown first, as it sort of gives a visual feedback of an image being downloaded.

Hi @akaashdev
Thanks for the feedback.
As this issue is now tracked by #4682, do you mind if I close this issue? You can reopen this issue if resolution to #4682 does not resolve this issue.

@akaashdev
Copy link
Contributor Author

Sure! This can be closed!
Thanks! 👍

@ghost ghost removed the Triage-Needed label Aug 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Partner-CiscoWebEx Bugs impacting CiscoWebEx integration scenarios Platform-iOS
Projects
None yet
Development

No branches or pull requests

2 participants