Imageview doesn't rotate accordingly to the device

[DrAma999]

How to reproduce: Launch the demo project and rotate the device few times.
Issue : the image view doesn't rotate accordingly with device. When it rotates accordingly if you double tap on it, the image rotates to the default state.

[u10int]

This is a known issue and is listed in the TODO section of the repo's readme file. I hope to get to this sometime next week.

[DrAma999]

So sorry, I didn't read the README with the right attention.
The fact is that adding views to window, is always a bit of pain when device rotates, because windows don't. Is there any particular reason to add it on a window? adding as a subview will come almost free.

[felixLam]

I have started working on this on a branch:
https://github.com/iosphere/URBMediaFocusViewController/tree/feature/interfaceRotation

My idea would be to get this to work at least when presented from a targetViewController. We should be able to rely more on the scrollView auto resizing. There are still a lot of unresolved issues on this branch (such as the initial center after rotation when reusing the same view controller, the min/max scale not adjusting after rotation and the background not properly resizing...). I hope that I get more work on this done during the week.

[u10int]

@felixLam I started working with the rotation support issue a couple of months ago, but properly handling the fromRect/fromView after a rotation is proving to be a pain in order to dismiss the image back to its target rect, which has to be transformed to account for the rotation. There's also the issue with the blurred/push-back view that doesn't work well with rotations since it's essentially a screenshot before this media focus view is presented. This blurred/background image would need to be updated with each rotation ideally.

The easiest solution is to only support rotating the image within this media focus view controller and not worry about the background view, which I have partially working in a local branch. Needless to say I haven't determined an elegant way of handling this that works in all cases, but hopefully I can find more free time in the coming weeks to dig into this issue a little more.

[felixLam]

I understand the approach. For the dismissal back to the target rect, we might rely on the delegate to provide the current rect. The background view would indeed need to be updated. Something that might be avoided at least when not using the blur. I'll see if I can make any progress. I would be happy to help. This is a very nice control. Thanks.

[felixLam]

Hi there,
I have just pushed a working version of the interface orientation code that relies on the targetViewController. The presentation methods without view controller still exhibit the issues with rotation.

What is still missing is a recalculation of the originalFrame when shrinking down. This should not be too complex if done via the delegate.

I have attached a screenshot.

Are pull requests welcomed?

Kind regards.

[u10int]

Nice work, thanks for taking a look at this. Pull requests are definitely welcome, but I'll review your code and clean up as necessary before fully committing to the repo. Also, if rotation depends solely on having a targetViewController defined, I would want to work through this some to ensure it works regardless of the targetViewController being set or not so it works in all cases, not just some to avoid users thinking it's a bug. This relates to your other issue and my comments regarding it: #19

[felixLam]

I think that things will get really complicated if you want to implement this without relying on the interface orientation of the view controller. The view geometry of the window is quite complicated when it comes to rotation (bounds, frame vs transforms).

I fully understand your concerns from #19 though. The code as it is now at least improves the situation for those using this control with UIViewController containment.

I am cleaning up the code a bit (mainly moving the methods to their respective locations in the file) and will make a pull request.

[u10int]

Sounds good. When dealing with device rotation and the view/window geometry, you just have to use bounds instead of frame since frame on the view or window will always refer to the standard geometry in portrait orientation. In most cases using bounds makes dealing with rotation considerably easier to manage.

[felixLam]

I added PullRequest #20