I have a UIImageView, which I load with the following function:

func loadData() {

guard let recipe = recipe,

let fileN = recipe.photo,

!fileN.isEmpty else {

imageView.image = nil

xableTrashButton()

return

}

let filePath = ImageUtils.fileURL(fileName: fileN, directory: .applicationSupportDirectory)!.path

imageView.image = UIImage(contentsOfFile: filePath)

imageView.contentMode = .scaleAspectFit

imageView.sizeToFit()

xableTrashButton()

}

I create a new image using a standard UIImagePickerController. In its imagePickerController(_ picker:didFinishPickingMediaWithInfo info:) delegate method, I save the image to a file (in the .applicationSupportDirectory) and save the image name in my database. Then I dismiss the pickerController, and call the above loadData() method in it's completion handler.

I observe two cases. In all cases except the above "exit from picker" case, the image is shown scaled to fit in the UIImageView. But in the case of "exit from picker", the upper left corner of the image is shown in the UIImageView at its full size.

Does anyone have any idea what might be happening here? And what I can do to get the (desired) effect of displaying the image scaled to its imageView in all cases?

Thanks,

Rick Aurbach

1. For any image which has an intrinsic size larger than the destination UIImageView object, the sizing behavior is the same. Namely, when the picker is dismissed (calling loadData(), the upper left corner of the image appears, fully expanded. In all other cases where the image is displayed (such as after switching between scenes, etc.), the image has been scaled to fit the UIImageView's physical size.

2. This is two questions. The images that cause problems have a size (i.e. UIImage::size) larger than the physical dimensions of the device. And in both the "correct" and "incorrect" cases, the UIImageView:bounds rectangle has a size equal to the image's size.

Rick

On Jul 21, 2018, at 2:37 PM, Rick Aurbach via Groups.Io <rlaurb@...> wrote:

I have explicit constraints. I expected consistent behavior and really don't understand why I don't get it.

I've tried two cases:
(1) UIImageView directly embedded in a (sub)-controller's view. Fully bound.
(2) UIScrollView directly embedded in a (sub)-controller's view. Fully bound. UIImageView inside the UIScrollView with all four sides bound to the scrollView and with "equal heights" and "equal widths" constraints set.

Both cases behave the same (test case is iPad Air 2 running 11.4.1.

On Jul 23, 2018, at 8:13 AM, Rick Aurbach via Groups.Io <rlaurb@...> wrote:

Steve,

I don’t want to disagree with you, but I’m seeing additional pieces of evidence which suggest (to me, at any rate) that this issue is related to timing, not insufficient constraints. I’ll try to explain. (I know a sample app would be best, but I haven’t had time yet to build it. When I do, I’ll post it here.)

(1) First of all, is the important observation that the ONLY time the image is drawn unscaled is when returning from UIImagePickerController. That is, if I visit the scene with the ImageView at any other time, the image appears scaled to the ImageView. It is only when first picking the image and populating the ImageVIew for the first time with the new image that it appears unscaled.

Let me be a bit more explicit about that. The only time the image is drawn unscaled in the ImageView is when performing the following sequence:

• User selects to put a new image in the image view. 
• We display the appropriate UIImagePickerController. 
• The user makes the selection and clicks Done.
• The picker delegate’s didFinishPickingMediaWithInfo handler is called.
• In that handler, we explicitly dismiss the picker controller.
• In the dismiss function’s completion handler, we load the newly selected image into the ImageView (using exactly the same logic as we do when displaying the scene originally).
• In this case (and this case only), the image in the ImageView is displayed unscaled. 

(2) Originally, the ImageView sat bare in the (sub)-controller’s view. I also tried embedding the ImageView in a ScrollView. In this case, I bound the scrollView to its enclosures Safe Area, then bound the ImageView to the ScrollView and added the “equal height” and “equal width” constraints between ImageView and its enclosing ScrollView. [The ScrollView was not enabled for zoom.] This made no change in behavior.

(3) My imageView is built with a tap gesture recognizer. Tapping the image causes a new window to be presented (in overFullScreen mode), providing pan/zoom support. So I changed the code so that, when dismissing the UIImagePickerController, I first load data into the ImageView, then IMMEDIATELY present this other (covering) window. And when I close this window (thereby revealing the ImageView once again), the image is properly scaled. [I am, in fact, using this approach as a temporary workaround in my latest field-test release. If you’d like to see things in action, please email me privately and I’ll add you to the field test.]

Sorry if this is a bit muddy. It’s much harder to write about than to understand with even a brief glimpse at the code. That’s why I’ll try to generate a sample app.

Hope this helps.

Cheers,

Rick

On Jul 24, 2018, at 1:25 PM, Rick Aurbach via Groups.Io <rlaurb@...> wrote:

Your comment about timing being an issue disturbs me since, ideally, the behavior should be consistent irrespective of "timing" since everything is funneled through a single thread. Assuming that one of your paths isn't accidentally setting imageView.image on a background thread, are you making any layout adjustments in -viewWillLayoutSubviews, for example? I have had problems where, ultimately, it was my fault but it took a long time to figure out that I was effectively trying to position something at the wrong time.

Yup. It disturbs me too.

But unless UIImagePickerController is doing something funky behind the scenes, then no, I am not doing anything on a background thread, nor am I explicitly making any changes to layout except for setting imageView.image and calling imageView.sizeToFit().

In fact, I’ve tried calling my loadData() method from
DispatchQueue.main.asyncAfter(deadline: .now() + 0.25) { [weak self] in
self?.loadData()
}

and it doesn’t help.

What it “feels like” (whatever that means) is that there is some race condition or timing condition between code being executed in the UIImagePickerControllerDelegate’s done-handler and the layout/display subsystem for the imageView in the presenter’s view scene.

If you’re inclined to play with this, I put a sample app together yesterday afternoon. https://www.dropbox.com/s/avx6y6kkb9mpwhh/ImageViewScaling.zip?dl=0
Please note that Case #1 appears to work in the Sample App, but not in my real app. I’m currently using Case #3 in my real app. Case #2 fails in both places.

Cheers,

Rick

On Jul 30, 2018, at 9:24 AM, Rick Aurbach via Groups.Io <rlaurb@...> wrote:

Steve,

I know I’ve tried various things to force a re-layout, but obviously not that. 

Your solution worked in my app beautifully. Thank you so much for the suggestion.

I will follow up by filing a radar about the problem. I’ll suggest that they either fix the (presumed timing) bug or address the issue in documentation.

Thanks again.

Cheers,

Rick Aurbach

On Jul 31, 2018, at 3:55 PM, Rick Aurbach via Groups.Io <rlaurb@...> wrote:

Steve,

I haven’t explored your argument in a test environment, but the reason I said the call to setNeedsLayout() was in ‘addition’ to the call to sizeToFit() is the following excerpt from the documentation of UIImageView (color enhancement is mine):

var image: UIImage?

The image displayed in the image view.

Declaration

var image: UIImage? { get set }

Discussion

This property contains the main image displayed by the image view. This image is displayed when the image view is in its natural state. When highlighted, the image view displays the image in its highlightedImage property instead. If that property is set to nil, the image view applies a default highlight to this image. If the animationImages property contains a valid set of images, those images are used instead.

Changing the image in this property does not automatically change the size of the image view. After setting the image, call the sizeToFit() method to recompute the image view’s size based on the new image and the active constraints. 

This property is set to the image you specified at initialization time. If you did not use the init(image:) or init(image:highlightedImage:) method to initialize your image view, the initial value of this property is nil.

So, at an absolute minimum, this is a documentation issue…

Cheers,

Rick