crash when popping view controller
Yep problem was some sort of bug/issue with auto-layout. I'm not sure what is is, but I've run into this issue elsewhere with system added controls (like the cancel button on a UISearchBar). I Converted the whole project to struts and it works with all the same code.
I'll wait until auto-layout's been around a bit longer before converting back.
Strange Crash when dismissing view controller, auto-layout to blame?
App crash If popViewController while scrolling UITableView
Your app is crashing because of
index out of bound
You should call
self.myChecksModel.resetModel()
In
override func viewDidDisappear(_ animated: Bool) {
super.viewDidDisappear(animated)
self.myChecksModel.resetModel()
}
AutoLayout: removeFromSuperview / removeConstraints throws exception and crashes hard
I had an (extensive) conversation with an Apple engineer about this crash.
Here are the two most probable causes:
You have an invalid constraint, such as
view1.left = view2.left + 20
whereview2
is unexpectedly nil, or has a multiplier of 0. Be sure to double (and triple) check your constraints to make sure that they are correct. Here are 2 examples of problematic constraints:// The first constraint would be a problem if view2 were nil
[NSLayoutConstraint constraintWithItem:view1 attribute:NSLayoutAttributeTop relatedBy:NSLayoutRelationEqual toItem:view2 attribute:NSLayoutAttributeBottom multiplier:1 constant:20];
// The second constraint is a problem because the 0 multiplier causes view2 to be "lost"
[NSLayoutConstraint constraintWithItem:view1 attribute:NSLayoutAttributeTop relatedBy:NSLayoutRelationEqual toItem:view2 attribute:NSLayoutAttributeBottom multiplier:0 constant:5];You're hitting a bug in the internal Foundation auto layout engine related to accumulated loss of floating point precision. When you've crashed, the way you can know that this is the case is to search through the (large) exception log in the console for a very small (nearly zero) floating point number such as this:
<505:-7.45058e-08>*PWPlotLegendEntryView:0x600000582be0.Height{id: 34609} +
(Search for e-
in the console output to find small numbers like this.) This number (-7.45058e-08
in this case) represents the coefficient at this particular point in time while the internal engine is solving constraints. In this case, the number is supposed to be exactly 0, but due to the way the auto layout engine does calculations with floating point numbers it has become an extremely tiny negative number instead which blows everything up. If you can find such a number in the output, you know that you've hit this bug.
How can you work around this issue?
Changing the order that you add (activate) constraints can end up changing the order of calculations in the internal engine, which as a result can cause this issue to disappear as the math is done without any problematic loss of precision.
This issue seems to come up more frequently when you have changed the content compression resistance or content hugging priorities for views, so try commenting out any code that does that to see if it's causing this bug to happen, or re-ordering it to happen earlier or later in your constraint setup code.
More details about my specific case:
I ran into this crash on iOS. The steps to reproduce it were quite interesting:
- A view controller containing a table view was pushed on screen (in a navigation controller).
- The table view had to contain enough cells so they didn't all fit in the visible area, then it had to be scrolled to the last cell and then back up a bit (presumably, this was causing cells to be reused, which was triggering this issue).
- Then, when the view controller containing the table view was popped off the navigation stack, immediately after the pop animation completed the app would crash at the point where the view controller's view was removed from the view hierarchy.
After a lot of trial and error I was able to isolate the issue to one specific thing: setting the content compression resistance & hugging priorities for a UIImageView
in each of the table view cells. In this case, the image view is being positioned using Auto Layout inside the cell, and to achieve the correct layout the image view needs to be exactly its intrinsic content size (the size of its image).
This was the problematic code:
// Inside of the UITableViewCell's updateConstraints method...
[self.imageView setContentCompressionResistancePriority:UILayoutPriorityRequired forAxis:UILayoutConstraintAxisHorizontal];
[self.imageView setContentCompressionResistancePriority:UILayoutPriorityRequired forAxis:UILayoutConstraintAxisVertical];
[self.imageView setContentHuggingPriority:UILayoutPriorityRequired forAxis:UILayoutConstraintAxisHorizontal];
[self.imageView setContentHuggingPriority:UILayoutPriorityRequired forAxis:UILayoutConstraintAxisVertical];
Removing the above code and replacing it with 2 constraints (at Required priority) to fix the width & height of the image view to the image's size achieved the same result, but avoided the crash. Here's the replacement code (using PureLayout):
[self.imageView autoSetDimensionsToSize:self.imageView.image.size];
I also found that just moving the problematic 4 lines to a different place in my constraint setup code resolved the issue, presumably because this changed the order of calculations sufficiently to prevent the problematic loss of precision.
Autolayout yellow warnings. Will it crash my app in run time
Yellow warnings and auto-layout warnings in console are not related.
Yellow warnings means that what you see in IB is not what you will get at runtime according to current constraints. If you want to see what you will get you should click yellow warning and press "update frame". If you want to get at runtime what you currently see in IB you should press yellow warning and select "update constraint".
Runtime warnings in console means some constraints conflict at runtime. You should analyse the warning message to find what is the issue.
PopViewController strange behaviour
I'm not 100% certain but I don't think you should actually be popping the view controller in that delegate method.
"should" delegate methods don't normally do something. They just assert whether something should or shouldn't be done.
Change your method to this...
- (BOOL)navigationBar:(UINavigationBar *)navigationBar shouldPopItem:(UINavigationItem *)item {
if ([[self.viewControllers lastObject] isKindOfClass:[ViewController1 class]]) {
ViewController1 *vc1 = (ViewController1 *)[self.viewControllers lastObject];
[vc1 handleBackAction];
if (vc1.canPopVC == YES) {
return YES;
} else {
return NO;
}
}
return YES;
}
And see if it works.
All I have done is removed the popViewController
calls.
EDIT - How to add a custom back button
In a category on UIBarButtonItem
...
+ (UIBarButtonItem *)customBackButtonWithTarget:(id)target action:(@SEL)action
{
UIButton *button = [UIButton buttonWithType:UIButtonTypeCustom];
[button setBackgroundImage:[UIImage imageNamed:@"Some image"] forState:UIControlStateNormal];
[button setTitle:@"Some Title" forState:UIControlStateNormal];
[button addTarget:target action:action forControlEvents:UIControlEventTouchUpInside];
UIBarButtonItem *barButton = [[UIBarButtonItem alloc] initWithCustomView:button];
return barButtonItem;
}
Now whenever you want to set a custom back button just use...
UIBarButtonItem *backButton = [UIBarButtonItem customBackButtonWithTarget:self action:@selector(backButtonPressed)];
Related Topics
How to Broadcast Multiple Ibeacon Signals from Only One Bluetooth? and How
Uilabel with Two Different Color Text
Fix Cordova Geolocation Ask for Location Message
How to Get Index Path of Cell on Switch Change Event in Section Based Table View
Thread Error in Ibaction While Overriding Prepareforsegue Function
How Get the List of Errors Thrown by a Function
Enable and Debug Zombie Objects in iOS Using Xcode 5.1.1
How to Integrate Crashlytics into an iOS Framework Target
Swift Compatibility Between Versions for a Library
Pod Install Command with Error
Urlresponse Is Not Retrieved After Storing in Cache Using Storecachedresponse
Swift: Failed to Assign Value to a Property of Protocol
Applicationwillterminate: Not Being Called
New Itunes Connect Interface -- Should It Immediately Be Seen on "Prerelease"
How to Effectively Process Uitouches in a Multitouch Sequence
Unarchive Array with Nskeyedunarchiver Unarchivedobject(Ofclass:From:)