Auto-Layout Issues: iOS 7 vs iOS8 - ios

I am trying to create a collapsible toolbar that works like this (running in iOS 7 -- ugly colors etc. for visualization purposes):
However, when I run the code in iOS 8, this is what happens:
I have set up a constraint system that is based on the following:
A centering view (not shown) keeps the toolbar in the screen middle.
A sizing view is adjusted to collapse the toolbar. The sizing view is anchored to the right of the centering view(via a trailing constraint).
A container view holds the actual content of the toolbar. It is anchored to the right of the sizing view (also via a trailing constraint).
Various content views are contained in the container view. They have no constraints. The default constraints applied by the system should be width, height, top, left, which ensures that they keep their relative positions in the container view.
The collapsing of the toolbar is achieved as follows:
- (IBAction)showLess:(id)sender {
self.widthConstraint.constant = 50; // adjust this number for collapse / expand
[UIView animateWithDuration:0.3 animations:^{
[self.centeringView layoutIfNeeded]; // trigger animation
}];
}
Which adjusts the width of the sizing view.
Problem:
iOS 8 seems to behave as if I had left anchored the content view, but this is not true.
I would sincerely appreciate:
An explanation as to why iOS 8 would have such a radically different interpretation of the given (reasonably simple) constraints.
A pointer as to how I can get the intended behavior in iOS 8
Source code available here (updated version that works in iOS 8).
UPDATE:
The issue was solved with answers from Stack-overflow. Basically, the right answer is this, but it was nicely summarized in this answer.
The difference between iOS7 and iOS8 is not in the way the constraints are interpreted, but in the way that update commands are trickled down through the view hierarchy.
When I implemented the behavior first in iOS 7, I noticed that the animation would only work properly if I called layoutIfNeeded on the parent view of the sizing view (i.e. on centering view). In iOS 7 this apparently trickled down the view hierarchy automatically. In iOS 8, this is not the case. You have to manually invalidate the view whose constraints have changed with setNeedsLayout, and then update the layout with layoutIfNeeded. My solution in the updated code looks like this:
- (IBAction)showLess:(id)sender {
self.widthConstraint.constant = 50;
[self.sizingView setNeedsLayout]; // *** THIS LINE IS NECESSARY TO MAKE THINGS WORK IN iOS 8
[UIView animateWithDuration:0.3 animations:^{
[self.sizingView layoutIfNeeded]; // trigger animation
}];
}
I hope this helps others who are also stuck on this forward compatibility issue.

The issue was solved with answers from Stack-overflow. Basically, the right answer is this, but it was nicely summarized in this answer. The difference between iOS7 and iOS8 is not in the way the constraints are interpreted, but in the way that update commands are trickled down through the view hierarchy. When I implemented the behavior first in iOS 7, I noticed that the animation would only work properly if I called layoutIfNeeded on the parent view of the sizing view (i.e. on centering view). In iOS 7 this apparently trickled down the view hierarchy automatically. In iOS 8, this is not the case: You have to manually invalidate the view whose constraints have changed with setNeedsLayout, and then update the layout with layoutIfNeeded. My solution in the updated code looks like this:
- (IBAction)showLess:(id)sender {
self.widthConstraint.constant = 50;
[self.sizingView setNeedsLayout]; // *** THIS LINE IS NECESSARY TO MAKE THINGS WORK IN iOS 8
[UIView animateWithDuration:0.3 animations:^{
[self.sizingView layoutIfNeeded]; // trigger animation
}];
}
I've updated the question to include the answer, but in response to #unmircea I am posting a separate answer, as well.

Related

iOS8 - animate all subviews not working

I'm trying to animate all views up when showing the keyboard to avoid overlap.
However, this old trick no longer seems to work:
for (UIView *subview in self.view.subviews){
CGRect r = subview.frame;
r.origin.y += yOffSet;
[UIView animateWithDuration:duration animations:^{subview.frame = r;} completion:block];
}
Any idea why?
==== UPDATE
These subviews don't animate on my iPhone6 running iOS8. They do however on my iPhone4 running iOS 7.1.2. Both use AutoLayout.
If you are using Auto-Layout you should not animate using frames anymore but constraint constants.
Also keep in mind that the "subviews" array property only contains the immediate "children" views. This could affect things, depending on your setup.
Edit I just noticed the problem only occurs on iOS7/iphone 4. There is a known issue with Auto-Layout and iOS7/iOS8 compatibility.
It comes down to how the updates are propagated along the view hierarchy.
There is a number of stackoverflow posts on this subject:
Auto-Layout Issues: iOS 7 vs iOS8
Issue with Auto Layout on iOS 8 (code works perfectly on iOS 7)

iOS - viewDidLayoutSubviews called before auto-layout completed on iOS7

We're currently having a problem that only seems to affect iOS7 devices.
Within our .xib file we have two views within a container view (i.e.: not at the top level of the view hierarchy) that need to be circular on display. The views have constraints applied to their position and horizontal spacing within the container, and an aspect ratio condition requiring they are square. The views should expand in width/height on larger screen sizes, respecting the constraints described.
In our VC, we have the following in viewDidLayoutSubviews to force these views to appear circular:
- (void)viewDidLayoutSubviews {
self.progressContentContainerView.layer.cornerRadius = self.progressContentContainerView.frame.size.width/2;
}
This seems to work fine on iOS8, however on iOS7 there is a period after the view has been displayed where the constraints have not yet been applied and the size of the view/views is incorrect (see attached screenshots). This resolves itself and correctly renders a circle after half a second. This only appears to happen when the views that we intend to be circular are NOT at the top level of the VC's view hierarchy which seems to imply that viewDidLayoutSubviews is called before the subviews of subviews have also been laid out.
My guess is that we could potentially fix this issue by subclassing UIView for the nested container, adding references to the circular view within this subclass and overriding viewDidLayoutSubviews here to make the cornerRadius adjustment. This seems like a bit of a workaround though and I'm interested to see if there are other options.
Is there a cleaner/more idiomatic solution to this problem?
I know this is an old question but have you tried calling either:
[self.progressContentContainerView setNeedsUpdateConstraints];
or:
[self.progressContentContainerView layoutIfNeeded];

Autolayout causing UI Elements to "snap" into place at runtime?

I have a UIView with a UIImageView at the very top, a UILabel below it, a UIButton below that, and a UISegmentedControl that determines what determines what embedded UIview to display at the bottom (which also a choice to not show any at all).
I've run into the problem where I've set up all of my constraints in the interface builder, and everything seems to be fine when I switch between screen sizes in the storyboard. However when I actually run the project on a device or emulated, the UIimage at the top is briefly stretched before "snapping" into a size the fits the constraints. Also, it seems as if the label disappears for a brief second and reappears after the image has snapped into a size. After the "snap" has occurred, everything is in place and there are no problems.
This snapping occurs both when testing on a 4 and 3.5 inch display. I find this odd because I've designed the UI for the 4inch screen perfectly.
Does anyone know why this is happening?
Edit
Here's whats the constraints look like in IB.
This is potentially due to adjustments that you might be making to your UI elements (or constraints) from the view controller in code. For example, if you are programmatically setting a different UIImage into your UIImageView, and this code is happening too late in the view lifecycle (for example, in viewDidAppear) after a layout pass has already calculated view positions and sizes, then you will see a visible snap as views take on new positions based on the new intrinsic content size of the image view.
This could be caused by other adjustments such as injecting a localized string into a UILabel in code, which causes the label to have a smaller or larger intrinsic content size, which in turn affects the layout based on your constraints.
If you are making adjustments to your UI in code, make sure they are happening in viewDidLoad or viewWillAppear: so that they occur before the view's initial layout pass (and the view's animation onscreen).
If you're still seeing issues, you can try explicitly forcing an immediate layout pass to occur on the view controller's view at the end of viewWillAppear: by doing the following:
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[self.view setNeedsLayout];
[self.view layoutIfNeeded]; // forces an immediate layout pass
}
Spacing between the UIElements might be the problem . Specially when using Pickers
Got it, You have applied constraint for Picker to adjust along with segmented control. So when app runs on 4 inch screen , picker automatically fits properly, but for 3.5 Inch picker always starts from bottom of the screen and picker will push segmented control upwards and hence segmented control will push rest control automatically.
Remove picker and segmented control constraint.

ios7 all searchviews and tableviews off by 20 pixels

EDIT: This is not an issue with the frame. The frame is in the correct spot. It is the content that is off. Yes, we are compensating for clear status bar. ViewDidLoad shows content offset is at 0,0.
On every page of my applcation that has a scrollview it's content is pushed down by 20 pixels. I think it may have something to do with the new StatusBar, or lack thereof. The bug also seems to be present in the simulators settings menu. Screenshot below. This only seems to affect the first scroll view that is added to a ViewController and only if no other views have been added to it. Table views are also being affected because they inherit from Scroll view. To be clear the scrollview starts at the correct origin but the content is pushed down by 20 pixels. This is bizarre because I would think if it was a status bar issue it would be 20 pixels above not below.
Currently we are fixing it by adding this to our base view controller
UIView *hackView = [[UIView alloc] init];
hackView.frame = CGRectMake(0, 0, 0, 0);
[self.view addSubview:hackView];
Obviously, this is a hack.
The same thing is happening on phone and in simulator even with the Gold Member version of IOS7 when building for latest IOS7. You can even see an example of the bug in the simulator's settings tableview and also in ours below.
This is a screenshot immediately after it loads. One bizarre thing that we noticed is that when we execute a pull to refresh it will correct the scrollview and rest at it's correct location. Alternatively, if we compensate it will look correct in the beginning but any subsequent pull to refreshes will migrate the scrollview to -20px
After further testing in Xcode, my original workaround still works, but the real culprit seems to be a Navigation Controller combined with the Adjust Scroll View Insets flag on the view controller. Disabling that solved the issue.
[self setAutomaticallyAdjustsScrollViewInsets:NO];
Original workaround: Try reordering your view hierarchy or add an empty view at the top.
This happened to me, and it appears that when a UIScrollView or similar subclass is first in the hierarchy it gets offset by 20 pixels (to keep it from hitting the status bar). However, this still occurs even when the view in question is nowhere near the top.
This is reproducible in Interface Builder, and an easy workaround for me has been to reorder my views so that a label or button is first under the view controller's view. If that's not possible in your case, adding an empty view (even off screen) above your scrollview also seems to solve the problem.
I added this to my UIViewControllers in viewDidLoad: which were affected and it fixed the issue for me:
NSComparisonResult order = [[UIDevice currentDevice].systemVersion compare: #"7.0" options: NSNumericSearch];
if (order == NSOrderedSame || order == NSOrderedDescending)
{
// OS version >= 7.0
self.edgesForExtendedLayout = UIRectEdgeNone;
}
Another, cleaner method:
if ([self respondsToSelector:#selector(edgesForExtendedLayout)])
self.edgesForExtendedLayout = UIRectEdgeNone;
How are you laying out your views? With autolayout you can use the topLayoutGuide, which should accommodate for these offsets.
In the Ios 7 the view starts from the window from y= 0, move your view to 20 pixel dowm
self.view.frame = CGRectmake (0,20,320,hight);
this is due to transparent status bar in iOS 7.
pull down the view to show it properly.

UITableView in storyboard not updating content size on rotation

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.

Resources