views:

43

answers:

1

I am building an application that must add an overlay view once a scrollview is done zooming. I was having problems adding the overlay to the scrollview itself and keeping the position consistent, due to what I assume is the scrollview not being done zooming...no biggie...so I decided to add the overlay to the sharedApplication's keyWindow.

Now, the application is in landscape orientation, and I have to do a transform on the overlay to get it to orient properly...this is fine. The issue arises in having to reposition the overlay by this seemingly arbitrary amount to get it centered...I dislike doing things ad hoc like this, so I thought I'd ask if anyone has run into something like this, and why the view has to be repositioned by this strange offset. Any insight would be great.

CGAffineTransform transform = CGAffineTransformMakeRotation(M_PI/2);
tempOverlay.view.transform = transform;

// Repositions and resizes the view.
CGRect contentRect = CGRectMake(-107, -80, 480, 320); //where does this offset come from?!?
tempOverlay.view.bounds = contentRect;

[[[UIApplication sharedApplication] keyWindow] addSubview:tempOverlay.view];
A: 

I was going to post this as a comment instead of an answer originally, but I'll just go for the answer route instead, even though I don't think there's really enough information to go on here. The following assumes that you have a fairly standard iOS application, aside from this overlay oddity where you're attaching the view to the keyWindow.

First, don't attach add your overlay view to the keyWindow. Instead, define some method on your root view controller which requests the overlay be displayed. Then in your root view controller code, add the overlay view to the controller's view above everything else.

Then, don't apply the transform since it will no longer be necessary to rotate your view.

At the time you create your view, set it's frame to be the bounds of the root controller's view. Also set it to have a flexible width and height via the autoresizingMask of UIView. Then assuming your root UIView has it's autoresizesSubview property set to YES, your overlay view will be nicely resized to match the size of the root view as it changes orientation.

If after all this the position of the contents of your overlay UIView is incorrect then I suspect the problem is within the contents of that UIView and has nothing to do with the need for any magic numbers in your frame/bounds.

NOTE: I haven't actually tried the above and am not 100% confident that in general your root UIView will enjoy having this extra overlay UIView thrown on top of it, on the other hand, it might remain blissfully unaware of it and everything will Just Work. Either way, to me it feels a lot less 'ad hoc' than what you're currently trying to do.

imaginaryboy
I hear ya. The overlay is a fixed size though, and the root view controller's view is the scrollview, so it's always a moving target. I guess I could have this not be the case, and encapsulate everything in a standard view. The orientation doesn't change mid-application, and I only add the overlay to the keyWindow to avoid having to recalculate its location on-the-fly, saving a few cycles (maybe this is pointless, though). I'll post my findings as I delve deeper. Thanks for the ideas.
diatrevolo
I ended up adding the overlay to the root view controller to avoid the transforms.
diatrevolo