I'm using an NIPagingScrollView to display several pages on the iPhone.
Everytime I flick to a page, the next page is also pre-loaded, which is fine.
When I rotate the iPhone from Portrait to Landscape mode, I let layoutSubviews do the re-layouting in my subclass of NIPageView. The NIPagingScrollView is set to auto-stretch in width and height to stay fullscreen. This works for the current page.
But when I flick to the next page, the layout is broken, as it was prefetched before and also layouted by an automatic call to layoutSubviews.
I guess the origin is not updated right on the next page on rotation, or something like that.
Has someone a hint on how I can avoid this problem (other than not using Landscape)? And is this a bug in Nimbus?
EDIT: I discovered that NIPagingScrollView provides the methods willRotateToInterfaceOrientation:duration: and willAnimateRotationToInterfaceOrientation:duration: which should be called by the view controller. I implemented these calls, but it still does not help.
Indeed NIPagingScrollView provides those methods, but if you look at them, you'll see that the layout computations are based on the scrollview frame values.
So if you want the correct values to be given to your paging scroll view, just for example, the frame or your main view (the controller view) to the paging scroll view (_scrollView in the example).
That way, just before the animation, your paging scroll view will have the correct waited frame, and your layout will be recomputed correctly.
- (void)willAnimateRotationToInterfaceOrientation: (UIInterfaceOrientation)toInterfaceOrientation
duration: (NSTimeInterval)duration {
// Your missing line of code to set the scroll view frame values
[self->_scrollView setFrame:self.view.bounds];
[self->_scrollView willAnimateRotationToInterfaceOrientation: toInterfaceOrientation
duration: duration];
[super willAnimateRotationToInterfaceOrientation: toInterfaceOrientation
duration: duration];
}
Related
I have my app 98% complete but stumbled across an issue which is stumping me!
Any help would be great.
Basically....I have a 5 tab controller. I have done some remodelling on the first tab view so that moving it from portrait to landscape moves everything around so that it looks great.
The other 4 tabs also move from portrait to landscape and back with ease.
Now....the issue I stumbled across was that if I had say tab 5 in portrait, moved it to landscape and then tapped tab 1, the only bits in tab 1 that orientate to landscape are the bits i fixed in the sizing inspector.
The bits I've re-positioned in code won't landscape.
If I however turn that tab 1 portrait and then back to landscape, it works!
The label fields I've moved with code using .frame and CGRectMake is in the
-(void)willAnimateRotationToInterfaceOrientation: (UIInterfaceOrientation)interfaceOrientation duration: (NSTimeInterval)duration
method.
.......do I need to put some code in the AppDelegate which the TabController resides in??
It makes sense to me that the TabBarController knows the orientation.
When you tap a tab.....what method gets actioned first before the view loads??
I think I need to catch the orientation then, adjust my label positions and then load the view.......
I would appreciate any thoughts?
Gaz.
EDIT: It's like what I want to do is be able to change things in tab 1 if the orientation changes in other tabs.can you do that? It seems that the 5 tab views are separate...
Try making a call to your rotation method in your view controllers viewWillAppear method, checking for correct orientation, and moving what you need to move. Should look something like this
-(void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[self autoRotate];
}
I think that if you move something in code it maintains it's position, so you need to change it's position every time the orientation changes in every view controller where you move objects in code. Like:
- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation
duration:(NSTimeInterval)duration {
if(UIInterfaceOrientationIsLandscape(toInterfaceOrientation)){
//change positions with animation using duration
}else if(UIInterfaceOrientationIsPortrait(toInterfaceOrientation)){
//change positions with animation using duration
}
}
I hope it helps.
I have a configuration UITableView that can launch a colour picker via a UINavigationController approach:
[self.navigationController pushViewController:colorPickerViewController animated:YES];
[colorPickerViewController release];
The effect of this means the ColourPicker will have a navigation bar at the top ( and back button)
The structure of the ColourPickerViewControll and it view ColourPickerView is as follows:
- ColourPickerViewController - in it's XIB file at the top level view it has:
- ColorPickerView : UIView (i.e. custom UI view) - in it's methods it has:
- (id)initWithCoder:(NSCoder*)coder {
if ((self = [super initWithCoder:coder])) {
CGFloat currVertBounds = self.bounds.size.height;
The issue here is the the value of currVertBounds is coming to 480, so it's not taking account of the navigation bar
QUESTION: How do I get the true displayed height of the ColorPickerView instance?
Is it something to do with trying to get the layout calculated in the custom UIView, and perhaps the custom view isn't rendered within the overall controll/navigationController at that stage?
You're reading bounds too early. None of the layout/subviewing magic that happens in UIKit will take place during [super initWithCoder:]. You should be reading bounds and laying out your view either:
In viewDidLoad/viewWillAppear, and set up the autosizing parameters for all manually created UI elements so they can get moved around with respect to different interface orientations. In these functions I wouldn't rely on bounds being exactly correct but I would say it's at least the right height:width ratio. It could possibly be in the wrong orientation, though.
In viewDidAppear, if you wish to manually position elements. By the time you hit viewDidAppear all of the resizing and such has taken place, and the only thing left to worry about is future rotations, which you should adjust your view for in willAnimateRotationToInterfaceOrientation:duration:.
Docs on willAnimateRotationToInterfaceOrientation:duration: state:
By the time this method is called, the interfaceOrientation property is already set to the new orientation. Thus, you can perform any additional layout required by your views in this method.
iOS 5.0 docs add the clause:
...set to the new orientation , and the bounds of the view have been changed. Thus...
I think this is still the case for prior iOS versions.
Views for iPhone will by definition have a height of 480 pixel when created in Interface Builder, so that's what you're seeing when you're initializing the view. Once the view has been properly initialized and added to the view stack, it will be resized to match the actual space available.
You're simply asking the view of its height before it has been adjusted.
Try reading the height in viewDidLoad, then it should be correct.
Yes, this is right because the instance of UINavigationController is declared in your (delegate.h) & that navigationBar is added to window not on your self.view
When you check the bounds of your current view, it should definitely return 320 * 480.
It should not include height of navigation bar in you view, as it not on that view. Its on window.
I have a UIScrollView in which vertical only scrolling is enabled. I'm displaying a grid of buttons (similar to the photo viewer image grid). The grid has to be drawn differently based on screen orientation, so that all of the screen real estate is used. Given the size of my buttons, I can fit 3 per row in portrait, and 4 per row in landscape.
I reposition all of the buttons in: willRotateToInterfaceOrientation:duration and then call: setContentSize: on my UIScrollView. Everything seems to work just fine, with the exception of the auto-scrolling that occurs after the call to SetContentSize:. In other words, let's say I was in portrait, and scrolled 3/4 of the way down the list, when I rotate to landscape, it auto-scrolls all the back up to the top.
The interesting thing is, in the same scenario, if I were to do a small flick scroll up or down, and then immediately rotate the device, the scroll view redraws correctly, and retains the current scroll position!
So, to be clear, the culprit here seems to be SetContentSize:, but obviously I have to call that for the scroll view to scroll correctly.
Any ideas on how I can retain the current scroll position?
Thanks!
You might try implementing the UIScrollViewDelegate method scrollViewShouldScrollToTop:, which tells the caller whether to scroll to the top or not. You may have to have some flag in your delegate that indicates if a rotation is underway or not, because under normal conditions you may actually want the ability to tap the status bar and have the scroll view scroll to the top.
If, on the other hand, you don't ever want the scroll view to scroll to the top automaticlly, simply implement that delegate method and have it return NO.
I had this problem, just did this and it works well for me
- (void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration
{
//calculate percentage down scrollview currently at
float c = self.scrollView.contentOffset.y / self.scrollView.contentSize.height;
//reposition subviews in the scrollview
[self positionThumbnails:toInterfaceOrientation];
//set the new scrollview offset to the same percentage,
// using the new scrollview height to calculate
self.scrollView.contentOffset =
CGPointMake(0, c * self.scrollView.contentSize.height);
}
In my case, I have a scrollview with a fixed width to device size, and variable height
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];
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.
I'm developing an image viewer, much like the Photos App.
It's a UIScrollView with paging enabled with images loaded from the internet, so I've adapted portions of the LazyTableImages sample. The Scroll View and each ImageView inside of it have all of their autoresize mask flags set.
When I first observed how resizes were happening during rotation, it looked good, but once I started trying to interact with the scroll view, I realized that I also had to programmatically change the size of the contentView. I did that by implementing didRotateFromInterfaceOrientation: in my view controller.
[self.scrollView setContentSize:CGSizeMake(numberOfImages * portraitWidth, [scrollView bounds].size.height)];
With interaction behaving properly, I then discovered that, if I was viewing the second photo and rotated, portions of both the 1st and 2nd photos would be shown on the screen. I needed to change the contentOffset as well.
I've tried to fix this two ways - both by using the scrollRectToVisible:animated: method of UIScrollView, as well as trying to set the contentOffset property directly. And I've experimented by putting this code in implementations of both the "one-step" and "two-step" responses to changes in Orientation. For example:
-(void)didAnimateFirstHalfOfRotationToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation {
[self.scrollView setContentOffset:CGPointMake(currentlyViewedPhotoIndex * largeImageHeight,0) animated:YES];
In all cases though, it just looks janky as hell. Either I clearly see the scroll happen, or it just jumps. Uuuuuuuuuuugly! Is there a way to do this so that it behaves exactly like the Photos app does?
What I wound up doing instead - just before rotation starts, hide the UIScrollView and create a UIImageView that contains the currently viewed image. Rotate, that image will rotate all nice and pretty, and when rotation completes remove the ImageView and unhide the Scroll View.
Update - if you're reading this today (anytime after iOS 6), use a UIPageViewController and set transitionStyle to UIPageViewControllerTransitionStyleScroll, for crissakes.
I did something slightly different when faced with the same problem. In willRotateToInterfaceOrientation:duration:, I hide all of the UIScrollView's subviews except for the currently displayed subview, and in didRotateFromInterfaceOrientation: I unhide the subviews.