views:

335

answers:

4

Hi all,

I'm trying to switch from two-stage rotation to one-stage rotation (to avoid the console warning, and because Apple recommend doing so because one-stage is faster).

However I can't figure out how to get the new size of my view (taking into account the navigation bar, status bar, etc) early enough to perform the update of my UI during the animation (rather than simply snapping the items to their new positions at the end as many applications seem to do, which results in a big "jerk" right at the end of the animation).

The sizes I get in the willAnimateRotationToInterfaceOrientation:duration: method are (perhaps obviously) the old sizes.

I can see I should be able calculate it by hand, working out the current bar heights, then inferring the new view frame size by deducted those from the rotated screen dimensions? (which isn't that difficult to do, though is perhaps fragile as it assumes the navigation bar, status bar, etc will be the same height in both orientations, and you'd have to manually take account of the toolbar being different heights in portrait vs landscape - I just want to make sure I've not missed a more straightforward or common way.)

Any feedback on approaches other people have taken would be great!

Thanks

Joseph

+3  A: 

Which OS version are you targeting? Under OS 4.0 (which is what I did a quick test in), [view bounds] within willAnimateRotationToInterfaceOrientation:duration: returns the new, post-rotation bounds.

If you are not seeing that, I’d suggest double-checking that your view has the appropriate auto resize mask set.

adurdin
I have to target 3.1 and 3.2 as well unfortunately. I'll need to check my code, see if it does work on 4.0 or I have some wider problem that was preventing it working. Thanks for your answer, I'll update this once I've checked more.
JosephH
+4  A: 

I've had the most success using my view's layoutSubviews method for autorotations. When layoutSubviews gets called during an orientation change, the view's bounds are already set to what they will be at the conclusion of the rotation. You can also at this time query the status bar, navigation bar, and toolbar for their sizes and get the correct post-rotation values (although the status bar width and height may be swapped--I just take the smaller value as the height, works great). Using that information you can lay out subviews and they will then be animated as part of the rotation.

It can be annoying to create a UIView subclass for every situation where you want to do this, so I created a special subclass of UIView called DelegatingView, which looks like this:

@protocol DelegatingViewDelegate

- (void)layoutSubviewsForView:(UIView*)view;

@end

@interface DelegatingView : UIView {
    id<DelegatingViewDelegate> _delegate;
}

@property (nonatomic,assign) id<DelegatingViewDelegate> delegate;

@end

@implementation DelegatingView

@synthesize delegate = _delegate;

- (void)layoutSubviews {
    [super layoutSubviews];
    [_delegate layoutSubviewsForView:self];
}

@end

I use this as my base view, add subviews to it, and set my UIViewController as the delegate. Then I can layout subviews from my view controller, having access to the current orientation and so on.

Hilton Campbell
Thanks for this - layoutSubviews definitely does work much better; I wonder why the Apple rotation documentation completely fails to mention this as an option!
JosephH
+2  A: 

If you have complex layout requirements in the view of your view controller, it is worth it to create a subclass of UIView and perform your layout code in -layoutSubviews (the correct place to do view layout). As Hilton Campbell pointed out, if you use this method for layout, you can check frame sizes and subview relationships and set their new positions appropriately.

If your view controller's view has a simple set of subviews, then you should probably just set their autoresizingMask properties appropriately, and let them animate themselves automagically.

Jerry Jones
A: 
Toro