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];
}
Related
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.
I'm not a full-time iOS dev and have to make some changes to someone else's code. We have a custom view where a UILabel is added in drawRect like this (edited for brevity):
- (void)drawRect:(CGRect)rect
{
UILabel *myLabel=[[UILabel alloc] initWithFrame:CGRectMake(50.0f, 50.0f, 100.0f, 30.0f)];
myLabel.text=#"here is some text";
[self addSubview:myLabel];
}
I have never really seen this and thought that drawRect was ONLY for adding drawing operations (and have only seen UIBezierPaths). Should this be moved to initWithFrame (or a common setup method like setupMyView). Or is ok to leave in drawRect? Is there anything besides custom drawing that should be in drawRect?
Sorry for asking a somewhat basic question but even reading the Apple docs leave a bit to be desired.
Unless there is a very good reason to setup the view's subviews from within the drawRect method (I can think of none) I would strongly suggest leaving drawRect as purely a drawing method and move that addSubview stuff out of there! I would suggest overriding the -init method that is currently used to initiate the parent view. For example:
-(instancetype)initWithFrame:(CGRect)frame {
if (self = [super initWithFrame:(CGRect)frame]) {
UILabel *myLabel=[[UILabel alloc] initWithFrame:CGRectMake(50.0f, 50.0f, 100.0f, 30.0f)];
myLabel.text=#"here is some text";
[self addSubview:myLabel];
}
return self;
}
I would definitely not do anything like that in drawRect. One method I've used in the past is to add it to layoutSubviews, because at that point the view is aware of the true bounds/frame. You'll want to ensure that you only generate the view stuff once, as layoutSubviews is called many times, such as on rotation. I usually do something like the following, where _viewGenerated is an instance variable:
- (void)layoutSubviews {
[super layoutSubviews];
if (!_viewGenerated) {
[self generateView];
_viewGenerated = YES;
}
}
- (void)generateView {
// do everything with any labels, images, etc., here...
}
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.
We can create formsheet views of non-standard size using the following bit of code (below), but the resulting view isn't centered -- the x-coordinate is always where a standard sized formsheet view would be. Changing the center property of the view and superview doesn't affect anything in a useful way. How can we use a custom formsheet size that is correctly centered?
Add the following code to the view controller that is being presented as a UIModalPresentationPageSheet:
#implementation MySpecialFormsheet {
CGRect _realBounds;
}
- (void)viewDidLoad {
// code below works great, but the resulting view isn't centered.
_realBounds = self.view.bounds;
[super viewDidLoad];
}
- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
self.view.superview.bounds = _realBounds;
}
I've only found success changing the frame after presenting it. I actually do it like so:
GameSetupViewController *gameSetup = [[GameSetupViewController alloc] init];
[gameSetup setDelegate:self];
[gameSetup setModalPresentationStyle:UIModalPresentationPageSheet];
[self presentModalViewController:gameSetup animated:YES];
[gameSetup.view.superview setAutoresizingMask:(UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth)];
[gameSetup.view.superview setFrame:CGRectMake(64, 64, 896, 640)];
But perhaps you could get away with using viewDidAppear or some other handle.
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…