I just updated my Xcode ver from 7.3 to 8.0 and some buttons borders disappeared.
The code looks fine, so I really don't know what happened to the layers.
btw - in some other controllers I can see the layers borders.
self.button.layer.borderColor = borderColor.CGColor;
self.button.layer.borderWidth = 2;
self.button.layer.cornerRadius = CGRectGetHeight(self.button.frame) / 2;
before: (The image is only for example - the borders looks different at real time)
now:
The reason is that XCode 8 introduces a new way to zoom in Storyboards.
Before XCode 8, in the view controller life cycle, frames were not known in viewDidLoad (or in properties didSet). You had to wait until viewDidLayoutSubviews (which is when Autolayout had finished applying the constraints to determine the frames of every subview in the main view.
But bounds were accessible before that: they were just set to the size of the IBOutlet in the storyboard.
In XCode 8, things are different : due to their new zooming system, even the boundsare not correct before ViewDidLayoutSubviews (they may exist but with dummy values like 1000 x 1000).
In conclusion :
you can use such things as cornerRadius in viewDidLoad or in the IBOutlet
didSet, as long as you use a fixed value
if you need to define your cornerRadius based on bounds, then do so in viewDidLayoutSubviews, or use NSLayoutConstraints (their value is fixed and known from Autolayout)
if you need to use cornerRadius in views (like UITableViewCell or UICollectionViewCell subclasses), then you can either do so in layoutSubviews (but then you need to give either a fixed value or a NSLayoutConstraint constant to cornerRadius), or in awakeFromNib(in that case, just add self.layoutIfNeeded before doing anything frame- or boounds-related, in order to force the cell to recalculate its subviews' frame).
I think problem in it:
CGRectGetHeight(self.button.frame) / 2;
When you set corner i think height button don't have value or value to larger border will don't show. You can try change it to
self.button.layer.cornerRadius = 15;
If work, I think you can check your logic and set it when height button get right value.
Try this and check:
#import <QuartzCore/QuartzCore.h>
self.button.layer.borderColor = [UIColor whiteColor].CGColor;
self.button.layer.borderWidth = 2;
self.button.layer.cornerRadius = 5; // Change this value on your requirement
self.button.clipsToBounds = YES;
To force view frame to be calculated, you can try with layoutIfNeeded.
For example for a label in a UITableViewCell :
override func awakeFromNib() {
super.awakeFromNib()
self.layoutIfNeeded()
self.qualityIndexLabel.makeRound()
}
use dispatch_after
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.8 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
self.button.layer.borderColor = borderColor.CGColor;
self.button.layer.borderWidth = 2;
self.button.layer.cornerRadius = CGRectGetHeight(self.button.frame) / 2; });
the RoundedRect is deprecated use UIButtonTypeSystem instead.
see https://developer.apple.com/reference/uikit/uibutton?language=objc for more information.
Related
I have a UIButton, and I would like to access the UIImageView of its background image so that I can make the image circular. I know that I can affect the image itself but I would prefer to do this more elegantly. I also know that I can use the button.currentBackgroundImage property to get the UIImage in the background, but I want the view itself. Once I have the view I intend to use this code:
buttonImageView.layer.cornerRadius = buttonImageView.frame.size.width / 2;
buttonImageView.clipsToBounds = YES;
How can I access the buttonImageView?
EDIT:
Due to #vhristoskov's suggestions, I tried cropping the button itself with this code:
self.button.layer.cornerRadius = self.button.frame.size.width/2;
self.button.clipsToBounds = YES;
And it made this shape:
After debugging I found that frame.size.width was 46, when it should have been 100. So I tried this code instead:
self.button.layer.cornerRadius = self.button.currentBackgroundImage.size.width/2;
self.button.clipsToBounds = YES;
And that produced this shape:
And this time, the cornerRadius was being set to 65. So it actually seems like my problem is that I don't have the correct width at the moment. Which property should I access to get the correct number?
Well as I guessed and as you've already found - the problem is in the button size. To be sure that your button's size at runtime is what you expected to be - review your constraints. In the example below the button has vertical and horizontal central alignment and fixed width and height.
Constraints:
To have perfectly circular button you should have button.width == button.height. If this condition is met your code should work like a charm:
self.button.layer.cornerRadius = CGRectGetWidth(self.button.frame) / 2;
self.button.clipsToBounds = YES;
Assuming that you called something like:
[self.myButton setBackgroundImage:[UIImage imageNamed:#"image"] forState:UIControlStateNormal];
in viewDidLoad or earlier, you can then call the following in viewDidAppear:
if (self.myButton.subviews.count > 0 && [self.myButton.subviews[0] isKindOfClass:[UIImageView class]]) {
UIImageView *imageView = self.myButton.subviews[0];
imageView.layer.cornerRadius = imageView.frame.size.width / 2;
imageView.clipsToBounds = YES;
}
but it is not more elegant as the subview ordering is an implementation detail of UIButton and may change at any time.
I tried to get a circle image using layer, here is my code
_compassArrow.layer.cornerRadius = _compassArrow.frame.size.width / 2;
_compassArrow.layer.masksToBounds = YES;
_compassArrow.layer.borderColor = [UIColor whiteColor].CGColor
the compassArrow is an imageview which display the compass image. And when I run my program, it looks terrible:
my actual picture
I don't know what happened to it. I've add some constraints to it, to make it has equal width with the device. Does this influence my image?
I think you set cornerRadius before your constraints are applied. Try to put this code in layoutSubviews or viewDidLayoutSubviews for example.
This way, the _compassArrow.frame.size.width value will be the one after constraints applied on it, and you'll get the correct cornerRadius.
Here is a piece of code that should allow you to do this.
_compassArrow.layer.borderWidth = 1.0
_compassArrow.layer.masksToBounds = false
_compassArrow.layer.borderColor = UIColor.whiteColor().CGColor
_compassArrow.layer.cornerRadius = profilePicture.frame.size.width/2
_compassArrow.clipsToBounds = true
I am doing a test project, and came across a problem with UITextView.
I am dynamically getting the content size of the text in the text view, and then increasing its height when needed. When the height reaches the threshold I have set, I will set scrollEnabled = YES to enable scrolling. Weird thing seems to happen as shown in the following screen shots:
Before going to new line and enabling scrolling:
After entering the next character, which will enable the scrolling:
After that, entering another character again, the text view will become normal again with scroll enabled (in fact the height remains as in the previous screen shot, I change the height according to content size, so it become the same height before enable scroll):
Anyone has came across this problem and able to solve it? If this is an iOS7 bug, any other suggestion for creating a message input text box? I wonder if previous iOS versions have this problem though.
Edited:
It seems like this problem occurs when the textview's scrollEnabled is YES and change the textview.frame.size.height, then the height will reset to the initial height (as in the height set in Interface Builder). Wonder if this will help for this problem.
The following shows the code used for editing the height of the text view (it is a method for the selector which will be called upon received UITextViewTextDidChangeNotification):
NSInteger maxInputFieldWidth = self.inputTextField.frame.size.width;
CGSize maxSize = CGSizeMake(maxInputFieldWidth, 9999);
CGSize neededSize = [self.inputTextField sizeThatFits:maxSize];
NSInteger neededHeight = neededSize.height;
if (self.inputTextField.hasText)
{
[self.inputTextField scrollRangeToVisible:NSMakeRange([self.inputTextField.text length], 0)];
if (neededHeight <= TEXTVIEW_MAX_HEIGHT_IN_USE && neededHeight != previousHeight)
{
previousHeight = neededHeight;
CGRect inputTextFieldFrame = self.inputTextField.frame;
inputTextFieldFrame.size.height = neededHeight;
inputTextFieldFrame.origin.y = TEXTVIEW_ORIGIN_Y;
self.inputTextField.frame = inputTextFieldFrame;
}
else if (neededSize.height > TEXTVIEW_MAX_HEIGHT_IN_USE)
{
if (!self.inputTextField.scrollEnabled)
{
self.inputTextField.scrollEnabled = YES;
CGRect inputTextFieldFrame = self.inputTextField.frame;
inputTextFieldFrame.size.height = TEXTVIEW_MAX_HEIGHT_IN_USE;
inputTextFieldFrame.origin.y = TEXTVIEW_ORIGIN_Y;
self.inputTextField.frame = inputTextFieldFrame;
}
else if (neededHeight != previousHeight)
{
previousHeight = neededHeight;
CGRect inputTextFieldFrame = self.inputTextField.frame;
inputTextFieldFrame.size.height = TEXTVIEW_MAX_HEIGHT_IN_USE;
inputTextFieldFrame.origin.y = TEXTVIEW_ORIGIN_Y;
self.inputTextField.frame = inputTextFieldFrame;
}
}
}
Over a year later and scrollEnabled is still causing problems. I had a similar issue where setting scrollEnabled = true (I'm using Swift) would not cause any changes.
I solved the problem by setting autolayout constraints on all sides of the textView. Then, like you detailed here, I just set textView.frame again. My guess is that this causes some internal update, which actually turns scrolling on. I'm also guessing that autolayout then forces the textView to stay at the right height, as opposed to the collapse that you're experiencing.
The brilliant Pete Steinberger has had a lot of problems with the UITextView and implemented a lot of fixes as a result.
His article can be found here with links to his code.
For a direct link to the code, it can be found here, but I recommend reading the post.
I ran into a similar issue (I'm using auto-layout) and was able to solve it with the following set up:
Adding top, leading, bottom, trailing margin constraints to my text view
Adding a greater-than-or-equal-to minimum height constraint with priority 999 (in my case this was set to 50)
Adding a less-than-or-equal-to maximum height constraint with priority 1000 (in my case this was set to 125)
Adding an equal-to height constraint with priority 1000 (set to 125) and making sure it's not installed (uncheck the 'installed' option in Interface Builder or set 'active' to NO/false on the constraint in code)
I then use the following code to determine the height of the text view and enable/disable scroll and constraints:
- (void)textViewDidChange:(UITextView *)textView {
...
CGSize size = textView.bounds.size;
CGSize newSize = [textView sizeThatFits:CGSizeMake(size.width, CGFLOAT_MAX)];
if (newSize.height >= self.textViewMaxHeightConstraint.constant
&& !textView.scrollEnabled) {
textView.scrollEnabled = YES;
self.textViewHeightConstraint.active = YES;
} else if (newSize.height < self.textViewMaxHeightConstraint.constant
&& textView.scrollEnabled) {
textView.scrollEnabled = NO;
self.textViewHeightConstraint.active = NO;
}
...
}
Using sizeThatFits: to determine the desired size of the text view, I either set scroll enabled or disabled. If it's enabled, I set the height constraint to active to force the text view to stay at the desired height.
In iOS 6 and earlier a uitableviewcell's imageView was positioned all the way over to the left with a 0 offset. In iOS 7 though this has been changed and there is now a 15 point space now. I would like to position the imageView like it is in iOS 6. I'm already subclassing the uitableviewcell with AKHighlightableAttributedCell to deal with attributed text not being highlighted. So based on some searching I added:
- (void) layoutSubviews
{
[super layoutSubviews];
// Makes imageView get placed in the corner
self.imageView.frame = CGRectMake( 0, 0, 80, 80 );
}
The issue is everything else still doesn't get repositioned and so I'm thinking there must be a better way to do this. I'd read some people mentioning using a negative offset to move everything over but I wasn't sure how this would work with constraints as it needs to scale properly for each orientation. Is there an easier solution to this that I'm missing? Thank you.
It appears I was doing it the correct way. The missing piece regarding the divider between fields was setting the inset on iOS 7. You can do this in the viewdidload or viewwillload and set self.tableView.separatorInset = UIEdgeInsetsMake(0, 0, 0, 0);
You will need to add a check if running iOS 7 or newer as this is a new property I believe. A better option might be setting it in the storyboard by selecting the table view and then setting separator insets from default to custom.
Here is the layoutSubviews method that repositions imageView and textLabel. If you have a description add that as well.
- (void) layoutSubviews
{
[super layoutSubviews];
// Makes imageView get placed in the corner
self.imageView.frame = CGRectMake( 0, 0, 80, 80 );
// Get textlabel frame
//self.textLabel.backgroundColor = [UIColor blackColor];
CGRect textlabelFrame = self.textLabel.frame;
// Figure out new width
textlabelFrame.size.width = textlabelFrame.size.width + textlabelFrame.origin.x - 90;
// Change origin to what we want
textlabelFrame.origin.x = 90;
// Assign the the new frame to textLabel
self.textLabel.frame = textlabelFrame;
}
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…