I'm working on a component that is a subclass from UIView and contains a UIScrollView.
When scrolling, I noticed different behaviors depending on which SDK I build with. On iOS 4 the layoutSubviews message is send on the scroll view's superview (which is my component) but on iOS 5 it seems that the message is not send anymore...
After taking a look at the iOS 5 release notes and changelog, I did not find any mention of such a change. Did I miss somethin?
In iOS5, layoutSubviews is not called on a scrollView's superview. But it was in iOS4.
If you want this behavior in iOS5, do this in your subclass of UIScrollView:
- (void)layoutSubviews {
[super layoutSubviews];
// causes layoutSubviews to get called on superview
[self.superview setNeedsLayout];
This was probably changed to be more efficient. Just because UIScrollView is scrolling, doesn't mean it's superview needs to layout itself.
I had big probs with resizing the size of button witch was subview in tableview. The nib loaded the smaller button and after loading I resize it. But the table view content didn't. (In iOS 4.* it was perfect but in iOS 5). So I figured out that I have to place my resizing in ViewDidLoad. I hope it helps to some1 =)
Related
Is it safe to call layoutIfNeeded inside viewDidLoad in an Xcode 8 iOS project like the code below?
- (void)viewDidLoad {
[super viewDidLoad];
[self.view layoutIfNeeded];
CGFloat frameHeight = CGRectGetHeight(self.frame);
subview.layer.cornerRadius = frameHeight * 0.5;
}
It works fine in Xcode 7 without layoutIfNeeded.
You can call it in viewDidLayoutSubviews() if you have issue.
From Apple iOS 10 Release notes is:
Sending layoutIfNeeded to a view is not expected to move the view, but in earlier releases, if the view had translatesAutoresizingMaskIntoConstraints set to NO, and if it was being positioned by constraints, layoutIfNeeded would move the view to match the layout engine before sending layout to the subtree. These changes correct this behavior, and the receiver’s position and usually its size won’t be affected by layoutIfNeeded.
Some existing code may be relying on this incorrect behavior that is now corrected. There is no behavior change for binaries linked before iOS 10, but when building on iOS 10 you may need to correct some situations by sending -layoutIfNeeded to a superview of the translatesAutoresizingMaskIntoConstraints view that was the previous receiver, or else positioning and sizing it before (or after, depending on your desired behavior) layoutIfNeeded.
Third party apps with custom UIView subclasses using Auto Layout that override layoutSubviews and dirty layout on self before calling super are at risk of triggering a layout feedback loop when they rebuild on iOS 10. When they are correctly sent subsequent layoutSubviews calls they must be sure to stop dirtying layout on self at some point (note that this call was skipped in release prior to iOS 10)."
Essentially you cannot call layoutIfNeeded on a child object of the View - now calling layoutIfNeeded has to be on the superView, and you can still call this in viewDidLayoutSubviews.
I think a better approach would be to do this either in viewWillAppear or viewDidLayoutSubviews
Those are times when the frame is actually finalized. viewDidLayoutSubviews is good because it will react to changes in the views frame.
If you have a requirement of different cornerRadius values for different size classes, I would use traitCollectionDidChange instead of viewWillLayoutSubviews or viewDidLayoutSubviews.
override func traitCollectionDidChange(previousTraitCollection: UITraitCollection?) is called only when the iOS interface environment changes. If the view is being loaded for the first time, previousTraitCollection will be nil.
That way, if your application supports multitasking, as soon as the view size changes to show two apps on your device screen at once, your views and will resize properly to fit the new size class. Using the layoutSubviews methods will also work, but might put additional processing strain on your application.
In order to get my app in line with guidelines for iOS8, I've implemented auto layout in my custom table view cell. On iOS8 this looks fine - the cells are laid out as I'd like at all screen sizes. On iOS7 however, the text boxes start out with only one line of text each, with the remaining text cut off (with an ellipsis). When touching the button however (on touch down), the cell's layout changes and it looks more like it does on iOS8. I can't seem to find what is being called here, and there aren't any constraint errors/warnings coming up in the console. Any idea how I might debug something like this, or is this a known bug in iOS8 so far?
I've noticed too when using self-sizing cells made in a storyboard. I was able to get it to work correctly by calling layoutIfNeeded in the cell's didMoveToSuperview method,
-(void)didMoveToSuperview {
[self layoutIfNeeded];
}
The problem
In a custom view of mine (a UIScrollView subclass) I am calling setNeedsLayout in response to a "reload data" event (triggered by an external source). Most of the time this works correctly and layoutSubviews is called when the next view layout cycle occurs. Sometimes, however, layoutSubviews is not called! Up until now I was living with the "certain knowledge" that setNeedsLayout always triggers layoutSubviews. Apparently I was wrong. I even tried calling layoutIfNeeded after setNeedsLayout, but still no success.
The question
Obviously, I would like to solve my particular problem. On the other hand, I would like to improve my understanding of the view layout process on iOS, so I am formulating my question in a general way: Do you know of any conditions that can prevent layoutSubviews from being called after setNeedsLayout has been called? Answers that focus on UIScrollView are quite welcome, since that is where I am having trouble.
Problem context
I am on iOS 7.1, using Xcode 5.1.1. Notes on the implementation of my custom scroll view:
The scroll view has a single container view of type UIView that is always the same size as the scroll view content size
The scroll view's layoutSubviews implementation places custom subviews into the container view by manually calculating the subviews' frames
The custom subviews' implementation uses Auto Layout
Here is how the reloadData implementation looks like:
- (void) reloadData
{
// Iterates through an internal array that holds the subviews,
// then empties the array. Subviews are deallocated at this
// point.
[self removeAllSubviewsFromContainerview];
self.contentOffset = CGPointMake(0, 0);
// I verified that the content size is always greater than
// CGSizeZero (both width and height)
CGFloat contentWidth = [self calculateNewContentWidth];
self.contentSize = CGSizeMake(contentWidth, self.frame.size.height);
// Here is the problem: Sometimes this triggers layoutSubviews,
// sometimes it does not.
[self setNeedsLayout];
// Adding the following line for debugging purposes does not
// help, making it clear that setNeedsLayout has no effect.
// [self layoutIfNeeded];
}
Last but not least, here are some observations I made:
layoutSubviews is called as expected if the content offset or content size change. layoutSubviews is not called in my particular case if these two values don't change. I first assumed that this observation is a general working principle of UIScrollView, i.e. that layoutSubviews is generally not called for UIScrollView unless content offset or content size change. However, when I wrote a couple of minimal projects I failed to reproduce this assumed "general" behaviour - in those projects layoutSubviews was always called as expected, regardless of whether content offset or content size changed or not.
layoutSubviews is always called as expected if the scroll view displays dummy UILabel instances instead of my own custom subviews
layoutSubviews is always called as expected if I use my own custom subviews, but replace Auto Layout in the custom subviews' implementation by manual frame calculations
The last two observations have led me to believe that Auto Layout is somehow involved, but I really have no idea how this could affect how setNeedsLayout works.
I'm working on project targeted for iOS 6 that leverages storyboards and auto layout. In the storyboard there are many places where a UITableView is added as a subview to a view controllers view. This table view uses prototype cells from the storyboard.
The issue we're running into is that if the view controller is initially loaded in landscape orientation and the device is then rotated to portrait, the table view begins to scroll both vertically and horizontally. The table views cells are drawn with the correct dimensions but there is additional white space to the right.
It appears that while the frame and bounds of the table view are being updated to the correct size on rotation, the table views content size is not. Regardless of any update rotation change the content size remains the same dimensions.
The issue doesn't present itself if programatic table view cells are used.
A few garish work arounds I've found, 1.) calling reloadData or reloadRowsAtIndexPaths:withRowAnimation: 2.) manually setting the property contentSize.
Both of these seem less than ideal.
I've added this
link to a dead simple sample project which demonstrates this issue. The only changes made are to the storyboard and the main view controllers implementation.
Before rotation
After rotation
I'm having the same issue - can't seems to find any documented answer related to this. I ended up manually modifying the UITableView contentSize like you mentioned in:
- (void) viewWillLayoutSubviews
{
self.tableView.contentSize = CGSizeMake(self.tableView.frame.size.height, self.tableView.contentSize.height);
}
I ran into this issue today and filed a bug report with Apple.
Appears that if you are using a custom cell with a UI element AND autoLayout, the UIScrollView content size is having problems.
If you remove all UI elements, OR turn off autoLayout, OR use a factory cell (basic, etc), all works fine.
Same issue I have rectified in my project.
I guess this is a bug in Storyboard.
Then I have solved it by manual coding in willAutorotate method by setting
tableview.contentsize = CGSizeMake(tableview.width, tableview.contentsize.height);
Hope this will work for you as well.
If you find any apple documentation regarding the same then please update me as well. Till then you can use the same solution.
Appears that if you are using a custom cell with a UI element AND autoLayout, the UIScrollView content size is having problems.
I had to turn off AutoLayout for my custom UITableViewCells to be able to scroll to the bottom on updating the data and then [self.tableView reloadData].
With AutoLayout turned on, the tableView.contentSize was being updated, but I still wasn't able to scroll to the bottom unless I rotated the device.
I found the following to work for me:
- (void)viewDidLayoutSubviews
{
[super viewDidLayoutSubviews];
dispatch_async(dispatch_get_main_queue(), ^{
self.tableView.contentSize = CGSizeMake(self.tableView.frame.size.width, self.tableView.contentSize.height);
});
}
Notice the async dispatch: if that line would be executed synchronously then the contentSize change would trigger another layout pass before the current one would have completed. This triggers an exception:
Auto Layout still required after sending -viewDidLayoutSubviews to the
view controller.
Usage of Constraints helped me. Since you are using Storyboards, it is really easy to set Constraint values for all edges, so UITableView will always fill the whole ViewController (of course if UITableView fills whole ViewController) regardless of device orientation.
I had the same problem.
I found this link. When I tried to implement this I did not find the Auto-sizing attributes for my view then I clicked on Master View Controller and then clicked on the File Inspector and uncheck Use Autolayout and then go to Attributes inspector auto-resizing should be there then you can change the attributes how you want it.
I am sure you must have managed to figure this out.
I have a UIScrollView filled with subviews, all is well when creating it and initially filling it.
But when I add a new subview that is positionned outside of the visible screen portion, or when I just resize an existing subview that is also outside of the visible screen portion, there is a subsequent 0.3s-long scroll animation (I can see it happening from my delegate) that seems to match the newly added/resized element.
Attempts:
pagingEnabled is always NO.
Setting scrollEnabled to NO during subview manipulations doesn't help.
Doing a setContentOffset:animated:NO after subview manipulations doesn't prevent the animation.
One single giant subview with all my subviews in it doesn't help.
My current workaround is to initially set the frame to fit inside the visible screen portion, or doing resizing work inside another superview, but it feels dirty, and won't handle all situations...
Is there a way to prevent this automatic scrolling animation when programmatically manipulating subviews?
Xcode 4.3, iOS SDK for 5.1.
I too discovered this problem and found this solution http://www.iphonedevsdk.com/forum/iphone-sdk-development/94288-disabling-uiscrollview-autoscroll.html
It involves subclassing the UIScrollView and entering no code in the following method.
- (void)scrollRectToVisible:(CGRect)rect animated:(BOOL)animated {
}
Like the guy says on the link I've found it works and no problems so far. Hope it works for you.
I had this problem because I set the content size of the scroll view prior to adding the subview.
As soon as I change the code so that the content size of the scroll view was set after adding the subview the problem went away.