Programmatic Device Specific iOS Constraint is nil - ios

I came across an interesting problem that only arises on iPhone 6/6+ and iPad mini with retina display.
In the following code:
- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];
if(self.seeMoreContents)
{
BOOL isText = [self.seeMoreContents isText];
self.imageView.hidden = isText;
[self.textView removeConstraint:self.textHeightConstraint];
[self.textWrapperView removeConstraint:self.textWrapperHeightConstraint];
if (!isText)
{
__weak FCSeeMoreViewController *weakSelf = self;
[self.imageView setImageByFlashcardSide:self.seeMoreContents completion:^(BOOL preloaded){
weakSelf.imageView.center = CGPointMake(weakSelf.view.frame.size.width / 2, weakSelf.view.frame.size.height / 2);
[weakSelf.scrollView setContentOffset:CGPointMake(0, 0)];
}];
}
}
}
- (void)viewDidLayoutSubviews
{
if ([self.seeMoreContents isText])
{
self.textView.text = self.seeMoreContents.text;
self.textView.font = self.fontForContents;
self.textWrapperView.hidden = NO;
[self.textView sizeToFit];
CGFloat height = self.textView.frame.size.height;
[self updateView:self.textView withConstraint:self.textHeightConstraint ofValue:height];
[self updateView:self.textWrapperView withConstraint:self.textWrapperHeightConstraint ofValue:height + self.wrapperMargin];
[self.scrollView setContentSize:CGSizeMake(self.textView.frame.size.width, height + self.scrollTextMargin)];
[self.scrollView setContentOffset:CGPointMake(0, -self.wrapperScrollVerticalConstraint.constant)];
}
[super viewDidLayoutSubviews];
}
- (void)updateView:(UIView*)view withConstraint:(NSLayoutConstraint*)constraint ofValue:(CGFloat)value
{
constraint.constant = value;
[view addConstraint:constraint];
}
By the time the two messages of udpateView get passed, the constraints have become nil. I could attribute this to weird garbage collection behavior, but it only happens on iPhone 6/6+ and mini retina iPad.
I have changed this whole controller to work better and to not to programmatically set constraints, but I want to know how/why this can happen on specific devices. Any insight would be greatly appreciated.

Override this method in your UIViewController to detect changing of 'traits':
func willTransitionToTraitCollection(_ newCollection: UITraitCollection,
withTransitionCoordinator coordinator: UIViewControllerTransitionCoordinator)
This is where you intercept constraint changes to get them at the right time, otherwise it's a race and your code can lose.
I suspect not using that function to get the timing right may be why you are not seeing consistent results. I bumped into the same kind of problem awhile back - not finding constraints that should have been there when I went looking for them.
Another thing to consider about mysterious constraints appearing and disappearing, of course, is UIView's
translatesAutoresizingMaskIntoConstraints
property, which if true (the default), causes iOS to dynamically create constraints, besides whatever you may have created programmatically or created in Interface Builder. And I have noticed some iOS generated constraints can disappear in different devices and orientations, as the iOS implementation that applies and removes such constraints is a black box.

Related

What is the correct way to call [super layoutSubviews]?

I just saw in the Facebook SDK for iOS that they call [super layoutSubviews]; at the end and not at the beginning of the layoutSubviews method.
As far as I know, we should always do it as the first line.
Can implementing it a different way cause any unexpected UI behavior?
- (void)layoutSubviews
{
CGSize size = self.bounds.size;
CGSize longTitleSize = [self sizeThatFits:size title:[self _longLogInTitle]];
NSString *title = (longTitleSize.width <= size.width ?
[self _longLogInTitle] :
[self _shortLogInTitle]);
if (![title isEqualToString:[self titleForState:UIControlStateNormal]]) {
[self setTitle:title forState:UIControlStateNormal];
}
[super layoutSubviews];
}
According to the UIView Class Reference,
The default implementation of this method does nothing on iOS 5.1 and earlier. Otherwise, the default implementation uses any constraints you have set to determine the size and position of any subviews.
Thus, that the Facebook SDK example app calls [super layoutSubviews] at the end of their implementation could be an artifact of the app being initially built for an iOS version prior to iOS 5.1.
For more recent versions of iOS, you should call [super layoutSubviews] at the beginning of your implementation. Otherwise, the superclass will rearrange your subviews after you do the custom layout, effectively ignoring your implementation of layoutSubviews().
look into the code, before [super layoutSubviews], it is not about the frame. so put it at the end may work well too.
I guess the coder must want to check the title and modify the title based on some rules, he thinks everytime the layoutSubviews being called is a right opportunity to do that, so he put the code here.
You always have to call [super layoutSubviews] last, if the intrinsic content size of a view will be changed. If you change the title of the button, the intrinsic content size of the UIButton will be changed, therefore the last call.
The first call to [super layoutSubviews] is always required because iOS updates the layout based on the constraints.
However, the technical most correct way of implementing your sample should be:
- (void)layoutSubviews
{
[super layoutSubviews];
CGSize size = self.bounds.size;
CGSize longTitleSize = [self sizeThatFits:size title:[self _longLogInTitle]];
NSString *title = (longTitleSize.width <= size.width ?
[self _longLogInTitle] :
[self _shortLogInTitle]);
if (![title isEqualToString:[self titleForState:UIControlStateNormal]]) {
[self setTitle:title forState:UIControlStateNormal];
}
[super layoutSubviews];
}

Why viewDidLayout only got called once on iOS 7, but several times on iOS 8

I have an project using autolayout,
And I notice that after viewWillAppear, viewWillLayoutSubViews and viewDidLayoutSubViews pair will be called several times on iOS 8, for my case, it is 2-3 times usually.
The fist viewDidLayoutSubViews will get incorrect frame size, so I have to avoid for first viewDidLayoutSubViews, and init my views afterwards.
However, when I tested it on iOS 7, I found that only ONE viewWillLayoutSubViews and viewDidLayoutSubViews pair got called, so my code broke again.
My question is, what is changed on iOS 8 for this behaviour?
EDIT:
I have pasted my demo code here:
In the code, _pieChart will be added to self.ChartViewCanvas, and self.ChartViewCanvas is using autolayout. _pieChart is from old project code, which is drawn without auto layout.
I was required to draw the pie chart before viewDidAppear, because drawing in viewDidAppear will have a 1 sec delay compare to other views in storyboard. This is not allowed for me.
Is there any way to know when is the final viewDidLayoutSubViews? Calling [self.ChartViewCanvas addSubview:_pieChart]; multiple times will lead to lower performance, and sometimes _pieChart's drawInRect will not be called every time, so the chart is not update.
- (void)viewDidLayoutSubviews {
[super viewDidLayoutSubviews];
_pieChart.delegate = self;
if (!_pieChart) {
_pieChart = [[PieChartView alloc] initWithFrame:CGRectMake(0, 0, pieRadius * 2, pieRadius * 2)];
}else {
[_pieChart setFrame:CGRectMake(0, 0, pieRadius * 2, pieRadius * 2)];
}
//_pieChart.translatesAutoresizingMaskIntoConstraints = NO;
if ([_pieChart superview]) {
[_pieChart removeFromSuperview];
}
[self.ChartViewCanvas addSubview:_pieChart];
}
Probably only Apple knows, but I won't deal with that too much if everything is working fine. In iOS8 Apple changed a lot view controllers (again) in they way they are presented from containers VC as for rotation and UITraitCollections.
For instance UIAlertView is now a view controller, when you show one you trigger all the mechanism related to present a VC.
If this fact is creating an issue it must be said that you should not rely on how many times those methods are called because they were always be unpredictable there are too many variables to be taken into account.
A quick and dirty solution could be wrap your code in a dispatch_once if you want that it will be called only one time.
If you add your view using auto layout correctly you won't see any sort of bug.
[EDIT]
Here is a little snippet about how it might look your viewDidLoad:
- (void)viewDidLoad
{
[super viewDidLoad];
//.. your stuff
//We don't need any frame autolayout wil take care of calculating it on its pass
_pieChart = [[PieChartView alloc]initWithFrame:CGRectZero];
_pieChart.delegate = self;
_pieChart.translatesAutoresizingMaskIntoConstraints = NO;
[self.ChartViewCanvas addSubview:_pieChart];
NSDictionary *bindings = NSDictionaryOfVariableBindings(_pieChart);
// We create constraints to tell the view that it needs to sctretch its bounds to the superview
NSString *formatTemplate = #"%#:|[_pieChart]|";
for (NSString * axis in #[#"H",#"V"]) {
NSString * format = [NSString stringWithFormat:formatTemplate,axis];
NSArray * constraints = [NSLayoutConstraint constraintsWithVisualFormat:format options:0 metrics:nil views:bindings];
[_pieChart.superview addConstraints:constraints];
}
// Do any additional setup after loading the view.
}
Of course that is going to call drawRect:, draw rect is called when a view is marked as dirty in the display pass, but before display is usually called the autolayout engine to calculate frames of views in needs for layout.
I tried this out on my application and found the same as you: 1 call on iOS7 and 3 on iOS8. From the stack traces this seems to be down to doing double layout after viewWillAppear and an extra layout following viewDidAppear not seen on iOS7.
My suggestion would be that you add any views in viewDidLoad (or viewWillAppear), then only do layout adjustments in the layout subview runs. Based on your updated post something like:
- (void)viewDidLoad{
[super viewDidLoad];
_pieChart = [[PieChartView alloc] initWithFrame:CGRectMake(0, 0, pieRadius * 2, pieRadius * 2)];
[self.ChartViewCanvas addSubview:_pieChart];
_pieChart.delegate = self;
}
- (void)viewDidLayoutSubviews {
[super viewDidLayoutSubviews];
[_pieChart setFrame:CGRectMake(0, 0, pieRadius * 2, pieRadius * 2)];
}
For interest the difference between iOS7 and 8 calling sequence was:
iOS7
i) viewWillAppear is called.
ii) layout of subviews is called. From the stack this seems to relate to the navigation bar and animation.
ii) viewDidAppear is called.
iOS8
i) viewWillAppear is called.
ii) layout of subviews is called. From the stack this seems to relate to the navigation bar and animation.
iii) exact same layout with exact same stack is called again. So something in the stack must request a rerun from some point.
iv) viewDidAppear is called.
v) An extra layout of subviews is called. This seems driven from a transaction pushed onto the run loop.

UISearchBar - internal UITextField height issue

I'm working on an app where I place a UISearchBar at the top of a UIViewController that contains a UITableViewController. The UISearchBar filters the contents of the UITableView.
I've left things alone so far (aside from customizing the colors to match my app's theme, which was hard enough!), but on anything except iPhone 4/5, the UISearchBar is dramatically too small.
Therefore, I'm trying to update the size of the font and the height of the internal UITextField.
All of this has proved remarkably difficult to accomplish, requiring quite a bit of customization. So, if you know of a library that makes this easier, please let me know in the comments.
Here's the code I'm using right now:
// In a category for UISearchBar
- (void)setup {
self.tintColor = [UIColor offWhite];
for (UIView *view in self.subviews) {
[self configureView:view];
}
}
- (void)configureView:(UIView *)view {
if ([view isKindOfClass:[UITextField class]]) {
CGFloat fontSize, frameHeight;
if (IS_IPHONE_4) {
fontSize = 14.0f;
frameHeight = 24.0f;
} else if (IS_IPHONE_5) {
fontSize = 14.0f;
frameHeight = 24.0f;
} else if (IS_IPHONE_6) {
fontSize = 17.0f;
frameHeight = 28.0f;
} else if (IS_IPHONE_6PLUS) {
fontSize = 20.0f;
frameHeight = 32.0f;
} else {
// iPad
fontSize = 24.0f;
frameHeight = 36.0f;
}
UITextField *textfield = (UITextField *)view;
textfield.font = [UIFont buttonFontOfSize:fontSize];
textfield.textColor = [UIColor offWhite];
textfield.tintColor = [UIColor offWhite];
CGRect frame = textfield.frame;
frame.origin.y = (self.frame.size.height - frameHeight) / 2.0f;
frame.size.height = frameHeight;
textfield.frame = frame;
}
if (view.subviews.count > 0) {
for (UIView *subview in view.subviews) {
[self configureView:subview];
}
}
}
Note: I structured my code this way in case Apple changes the internal structure of the UISearchBar. I didn't want to hard-code index values.
So, this code "works", in that the end result is what I desire, namely, a taller UISearchBar with text sized as specified and the internal UITextField also taller, as specified. What I don't understand is the process of getting there.
If I call [self.searchBar setup] in my general AutoLayout process, it doesn't work (the internal UITextField is the wrong height). This makes sense to me, since the frame is (0,0,0,0) until the view is actually laid out.
If I call [self.searchBar setup] in my -viewWillAppear: method, it doesn't work (the internal UITextField is the wrong height). This doesn't make sense to me, since debugging shows the frames to still be (0,0,0,0), but I thought -viewWillAppear: was called when everything was laid out and set up.
If I call [self.searchBar setup] in my -viewDidLayoutSubviews method, it "works", but the internal UITextField starts out the "normal" height and then "jumps" to the correct height some time after the view actually appears.
I set up the entire UIViewController in code, using pure AutoLayout. I simply cannot get the UISearchBar set up the way I want BEFORE the view finished loading and is displayed on screen. I've seen some funky stuff in the past, but I've always been able to force a view to render as desired. Is there something special behind the scenes with UISearchBar? Does anybody know how to get this done?
You're mixing auto-layout and manual layout (someView.frame = …) on the same view. You can't do that.
Instead, to change the height, set the constant on your view's height constraint to frameHeight. Let the auto-layout engine set the frame for you.

How do I change the size of a UIView (UITextView) in iOS 7 based on user actions

I have an iPhone application (Six Things) that I wrote in iOS 6 which has a screen where the user enters text into a UITextView. When the keyboard is shown, the size of the UITextView was automatically shortened so that as the user was typing, the cursor was not hidden behind the keyboard (see picture).
I used the following handlers to do this:
When the keyboard was shown:
- (void)keyboardDidShow:(id)sender
{
NSDictionary* info = [sender userInfo];
CGSize kbSize = [[info objectForKey:UIKeyboardFrameBeginUserInfoKey] CGRectValue].size;
_txtSizeBase = self._txtInfo.frame;
float offset = kbSize.height < kbSize.width?kbSize.height:kbSize.width;
_txtSizeKeyboard = CGRectMake(_txtSizeBase.origin.x, _txtSizeBase.origin.y, _txtSizeBase.size.width, _txtSizeBase.size.height-offset+60);
self._txtInfo.frame = _txtSizeKeyboard;
...
}
When the "Done" button was pressed and the keyboard dismissed:
- (void)keyboardDidHide:(id)sender
{
self._txtInfo.frame = _txtSizeBase;
...
}
This worked well in iOS 6. But in iOS 7, I don't know of a way to force the view to change its size AFTER the viewDidLoad has already been called. Changing the size of the frame does not cause it to resize.
I've turned off auto-layout on this form so that I can have the screen adjust elements properly (y position) for both iOS 6/7 (using deltas in interface builder).
Any helpful suggestions would be appreciated.
---------------------- EDIT WITH SOLUTION -----------------------------
Because the solution to this was a bit tricky, I thought it would be helpful to post it.
I added a second .xib file for IOS6 (I only release for IOS 6+) with autolayout turned off and the positions adjusted as needed. Then I do the following:
-(id)initWithNibName:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil
{
if(![DeviceInfo isIOSAfter70])
{
self = [super initWithNibName:#"CreateRecordViewControllerIOS6" bundle:nibBundleOrNil];
}
else
{
self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil];
}
}
** This is not the most elegant solution, but it works and I just want to support IOS 6 users, not move forward with IOS 6 dev, so there it is. **
I turned on Auto Layout for the form:
I set a bottom constraint on the text view and tied it to a an IBOutlet called _bottomConstraint.
I modified the handlers for the KeyboardDidShow/Hide as follows:
-(void)keyboardDidHide:(id)sender
{
...
if([DeviceInfo isIOSAfter70])
{ // IOS7+
if(_bottomConstraint != nil)
{
_bottomConstraint.constant = _bottomConstraintConstant;
[self.view layoutIfNeeded];
}
}
...
}
-(void)keyboardDidShow:(id)sender
{
...
if([DeviceInfo isIOSAfter70])
{ // IOS7+
if(_bottomConstraint != nil)
{
_bottomConstraintConstant = _bottomConstraint.constant;
_bottomConstraint.constant += kbSize.height;
[self.view layoutIfNeeded];
}
}
...
}
I had similar issues with settings frames under iOS7. I think that it is not very wise to fight auto-constrains. Just enable auto-constrains (if you can) and animate constrains.
You can create IBOutlet from constrain with Interface builder, or if you are creating constrains programatically leave reference to it. Than use code similar to this:
[self.view layoutIfNeeded];
self.constrainVertical.constant = 10;
[UIView animateWithDuration:0.3 animations:^{
[self.view layoutIfNeeded];
} completion:^(BOOL finished) {
//put some finalizing code here if needed
}];
I am moving just one constrain, just to show you how it can be done. Also, when using constrains, forget about setting frames directly.
Hope it helps.

Animated Resize of UIToolbar Causes Background to be Clipped on iOS <5.1

I have implemented a custom split view controller which — in principle — works quite well.
There is, however one aspect that does not work was expected and that is the resize-animation of the toolbar on iOS prior to version 5.1 — if present:
After subclassing UIToolbar to override its layoutSubviews method, animating changes to the width of my main-content area causes the toolbar-items to move as expected. The background of the toolbar — however — does not animate as expected.
Instead, its width changes to the new value immediately, causing the background to be shown while increasing the width.
Here are what I deem the relevant parts of the code I use — all pretty standard stuff, as little magic/hackery as possible:
// From the implementation of my Split Layout View Class:
- (void)setAuxiliaryViewHidden:(BOOL)hide animated:(BOOL)animated completion:(void (^)(BOOL isFinished))completion
{
auxiliaryViewHidden_ = hide;
if (!animated)
{
[self layoutSubviews];
if (completion)
completion(YES);
return;
}
// I've tried it with and without UIViewAnimationOptionsLayoutSubviews -- didn't change anything...
UIViewAnimationOptions easedRelayoutStartingFromCurrentState = UIViewAnimationOptionCurveEaseOut | UIViewAnimationOptionBeginFromCurrentState;
[UIView animateWithDuration:M_1_PI delay:0.0 options:easedRelayoutStartingFromCurrentState animations:^{
[self layoutSubviews];
} completion:completion];
}
- (void)layoutSubviews
{
[super layoutSubviews];
// tedious layout work to calculate the frames for the main- and auxiliary-content views
self.mainContentView.frame = mainContentFrame; // <= This currently has the toolbar, but...
self.auxiliaryContentView.frame = auxiliaryContentFrame; // ...this one could contain one, as well.
}
// The complete implementation of my UIToolbar class:
#implementation AnimatableToolbar
static CGFloat sThresholdSelectorMargin = 30.;
- (void)layoutSubviews
{
[super layoutSubviews];
// walk the subviews looking for the views that represent toolbar items
for (UIView *subview in self.subviews)
{
NSString *className = NSStringFromClass([subview class]);
if (![className hasPrefix:#"UIToolbar"]) // not a toolbar item view
continue;
if (![subview isKindOfClass:[UIControl class]]) // some other private class we don't want to f**k around with…
continue;
CGRect frame = [subview frame];
BOOL isLeftmostItem = frame.origin.x <= sThresholdSelectorMargin;
if (isLeftmostItem)
{
subview.autoresizingMask = UIViewAutoresizingFlexibleRightMargin;
continue;
}
BOOL isRightmostItem = (CGRectGetMaxX(self.bounds) - CGRectGetMaxX(frame)) <= sThresholdSelectorMargin;
if (!isRightmostItem)
{
subview.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin;
continue;
}
subview.autoresizingMask = UIViewAutoresizingFlexibleLeftMargin;
}
}
#end
I’ve set the class of the toolbar in InterfaceBuilder and I know for a fact, that this code gets called and, like I said, on iOS 5.1 everything works just fine.
I have to support iOS starting version 4.2, though…
Any help/hints as to what I’m missing are greatly appreciated.
As far as I can see, your approach can only work on iOS SDK > 5. Indeed, iOS SDK 5 introduced the possibility of manipulating the UIToolbar background in an explicit way (see setBackgroundImage:forToolbarPosition:barMetrics and relative getter method).
In iOS SDK 4, an UIToolbar object has no _UIToolbarBackground subview, so you cannot move it around in your layoutSubviews implementation. To verify this, add a trace like this:
for (UIView *subview in self.subviews)
{
NSLog(#"FOUND SUBVIEW: %#", [subview description]);
run the code on both iOS 4 and 5 and you will see what I mean.
All in all, the solution to your problem lays in handling the background in two different ways under iOS 4 and iOS 5. Specifically, on iOS 4 you might give the following approach a try:
add a subview to your custom UIToolbar that acts as a background view:
[toolbar insertSubview:backgroundView atIndex:0];
set:
toolbar.backgroundColor = [UIColor clearColor];
so that the UIToolbar background color does not interfere;
in your layoutSubviews method animate around this background subview together with the others, like you are doing;
Of course, nothing prevents you from using this same background subview also for iOS 5, only thing you should beware is that at step 1, the subview should be inserted at index 1 (i.e, on top of the existing background).
Hope that this helps.
Since I think this is going to be useful for someone else, I’ll just drop my solution here for reference:
Per sergio’s suggestion, I inserted an additional UIImageView into the view hierarchy. But since I wanted this to work with the default toolbar styling, I needed to jump trough a few hoops:
The image needed to be dynamically generated whenever the tintColor changed.
On iOS 5.0.x the toolbar background is an additional view.
To resolve this I ended up…
Implementing +load to set a static BOOL on whether I need to do anything. (Parses -[UIDevice systemVersion] for version prior to 5.1).
Adding a (lazily loaded) property for the image view stretchableBackground. The view will be nilif my static flag is NO. Otherwise the view will be created having twice the width of [UIScreen mainScreen], offset to the left by half that width and resizable in height and right margin and inserted into the toolbar at index 0.
Overriding setTintColor:. Whenever this happens, I call through to super and __updateBackground.
Implemented a method __updateBackground that:
When the toolbar responds to backgroundImageForToolbarPosition:barMetrics: get the first subview that is not our stretchableBackground. Use the contents property of that view’s layer to populate the stretchableBackground’s image property and return.
If the toolbar doesn’t respond to that selector,
use CGBitmapContextCreate() to obtain a 32bit RGBA CGContextRef that is one pixel wide and as high as the toolbar multiplied by the screen’s scale. (Use kCGImageAlphaPremultipliedLast to work with the device RGB color space…)
Translate the CTM by that height and scale it by scale/-scale to transition from UIKit to CG-Coordinates and draw the view’s layer into that context. (If you fail to do this, your image will always be transparent blank…)
Create a UIImage from that context and set it as the stretchableBackground’s image.
Notice that this fix for iOS 5.0.x will not work as expected when using different background images for portrait and landscape or images that do not scale — although that can be tweaked by configuring the image view differently…

Resources