I've got a custom subclass of UIView, lets call it BottomBox.
BottomBox has override methods for:
-(void)setBounds:(CGRect)bounds;
and
-(void)setFrame:(CGRect)frame;
with calls to [super set*:*] in each, and logging of current and new CGRects, and breakpoints in both.
BottomBox objects have the autoresizingMask set:
bottombox1.autoresizingMask =
UIViewAutoresizingFlexibleTopMargin |
UIViewAutoresizingFlexibleLeftMargin |
UIViewAutoresizingFlexibleRightMargin;
and they are positioned at the bottom of the screen.
BottomBox objects contain sublayers of the main .layer property, and these sublayers are transformed, and the bounding box of these layers go outside the region of the BottomBox objects' view bounds. This causes the frame/bounds accessors to give back adjusted bounds values, which I have accounted for.
But after a device orientation change, the BottomBox objects are being resized abnormally, despite the autoresizingMask property defining no flexibility to width or height. In my experience, the height of the bounds/frame are not being adjusted, but the width is being extremely warped.
Now, I feel I am simply misunderstanding the real meaning of bounds and frames. Perhaps, in reality, they're calculated on the fly for every access, based on the subviews and sublayers.
I'd like to know if there is any other way these can be adjusted, perhaps I'm overlooking something.
During device rotation, any UIViewController that permits reorientation, and view resizing, affects any subviews if it's view.autoresizesSubviews is YES.
Then any subviews with any flexible resizing mask will permit the call of setFrame from within [UIView(Geometry) _applyAutoresizingMaskWithOldSuperviewSize:].
The receiver of setFrame: will receive the frame adjusted according to the autoresizing mask, properly.
In my BottomBox, there is a setFrame override, to inspect the frame argument, plus the values of the frame after calling [super setFrame:frame].
My implementation-specific notes:
For example, a 432-pixel-square rotated -120 deg, has a new bounding
box of 589.
Then when the device is rotated and setFrame is called because of ANY flexible autoresizing mask constant, then setFrame receives a 589-pixel-square frame size.
The rotation is silently applied and yet another outer bounding box is defined by a 803-pixel-square.
In practice, this 803 square was actually maintaining 589 pixels in height, it was not resized vertically. This is because of the auto resizing mask. and rigid bottom margin in my specific context.
So in summary, a view that originally was 432 pixels square managed to become a view bounded by an 803x589 pixel rectangle. Seriously warped.
Related
Say I'm creating an animation, and I want to move the center of a UIView to a certain CGPoint I have. I know what I want the center to be, just the aforementioned CGPoint, and I know the width and height that I want, but when I go to create the frame for my UIView I have no idea what to set for the x and y for the origin.
Should I just be setting 0, 0 or anything really? Does it matter?
Should I just be thinking as setting center as a different method of setting the origin? Makes me wish CGRect had an instantiator with center as an option.
There has been a previous question addressing a somewhat similar question, but it addresses them as three separate entities, rather than how to deal with center when creating the view.
Yes, go ahead and set the initial frame's origin to anything, since subsequently setting the center will effectively move this origin anyway. It is not uncommon to initialise views with a frame of CGRectZero when it is going to be fully configured later.
frame is actually just a calculated property based on the view's center and bounds, and so all three are intrinsically linked when it comes to view layout. The UIView Class Reference has this to say about it:
The geometry of a view is defined by its frame, bounds, and center
properties. The frame defines the origin and dimensions of the view in
the coordinate system of its superview and is commonly used during
layout to adjust the size or position of the view. The center property
can be used to adjust the position of the view without changing its
size. The bounds defines the internal dimensions of the view as it
sees them and is used almost exclusively in custom drawing code. The
size portion of the frame and bounds rectangles are coupled together
so that changing the size of either rectangle updates the size of
both.
I have a UIView. I am drawing a line inside the UIView programmativally. But when the line goes outside the UIView, the part of the line which goes out, is invisible. How can I resize the UIView so that whatever I draw inside the drawRect method is visible?
you can change the frame of view. If your line is horizontal then give width to view else increase height of view.
view.frame = CGRectMake(view.frame.origine.x, view.frame.origine.y,view.frame.size.width,lengthOfLine );
If the curve you are drawing is a subview, then you can make use of sizeToFit method. This will make the view's frame enclose the curve(and all subviews, for that matter). Then you can reposition and scale the view's frame to make it fit in the window.
You have mentioned in a comment that you are actually drawing a curve. From what I can tell, you will need to calculate the curve's bounding box yourself.
Based on the bounding box, update the UIView's bounds property (as Durgaprasad suggested). This also resizes the underlying CALayer, which also gives its underlying Core Graphics rendering context a larger bitmap.
Without knowing more about your curve, it's hard to help, apart from linking to some very generic discussion on quadratic Beziers.
You may want to update your question with a minimal implementation of -drawRect: that will allow someone to reproduce your issue.
So let's say I have a UIView that in its standard configuration spans the full width and height of its container. For the purposes of this question, let's say that its dimensions are 320x400. Suppose that this view contains content that may be (and typically is) larger than its standard dimensions (so it scrolls through content).
Now if this UIView has a UIRotationGestureRecognizer associated with it that is used to rotate the view using its transform property, how do I ensure that its frame size/drawable area is always sufficiently large for its current orientation (by "sufficiently large" I mean that the rendered content should always extend out to the original bounds, and not be clipped prior to reaching the edge of the original bounds)? For instance, if I rotate it 90 degrees the view needs to understand that its "width" may now consume up to 400 pixels, while its height is constrained to 320 pixels.
Note that I don't want to scale the view as part of the rotation operation. Any "additional" space that becomes available due to the current rotation should be used to display additional content, if available, and not to simply display the same content at a higher zoom level.
You don't want any empty spaces to appear when rotating. The solution is to have a subview containing a background which is sufficiently large enough to cover the entire viewport during rotation. I'd say a 400 by 400 view should do. This view can either be the parent of your contentview, but that'll give you a bit of a positioning hassle.
Easier would be to add a subview on your currentview. Put the (large) background on this subview, make sure this view is at the bottom of the view stack and on your currentview put clipsToBounds=NO.
Beware though that disabling clipping can have a performance impact especially if your view hierarchy becomes complex.
Can somebody point me to a good primer on the above, and what happens to one when you mess with the others? It seems as though no matter what I do, once I start messing with either the status bar orientation or the view transform (even if all I'm doing is 90-degree rotations), I can count on my views ending up sideways, upside down and backwards, and on a frustrating afternoon of trial and error trying to get them straightened out. I'm sure it all makes sense once you know the logic and what order everything's applied in, but so far, empirically, I haven't been able to figure it out.
I don't know of a good single document primer on the subject, but the following is what I've learned from experience and reading the docs.
center, bounds, and frame
If you set frame then center and bounds will be updated. If you set center or bounds then frame will be updated. Frame is a convenience method for manipulating center and bounds using the superview's coordinate system.
From UIView Class Reference:
The geometry of a view is defined by its frame, bounds, and center properties. The frame defines the origin and dimensions of the view in the coordinate system of its superview and is commonly used during layout to adjust the size or position of the view. The center property can be used to adjust the position of the view without changing its size. The bounds defines the internal dimensions of the view as it sees them and is used almost exclusively in custom drawing code. The size portion of the frame and bounds rectangles are coupled together so that changing the size of either rectangle updates the size of both.
See The Relationship of the Frame, Bounds, and Center Properties for more details.
transform
If you set the transform property to something besides the identity transform, frame is undefined. If you set the transform to something else, you should only manipulate the view geometry using center (to position the view in it's superview) and bounds (to adjust the size of the view). Here's the relevant info from UIView Class Reference:
The origin of the transform is the value of the center property, or the layer’s anchorPoint property if it was changed. (Use the layer property to get the underlying Core Animation layer object.) The default value is CGAffineTransformIdentity.
...
Warning If the transform property is not the identity transform, the value of this property is undefined and therefore should be ignored.
See Coordinate System Transforms for more details.
UIInterfaceOrientation
UIInterfaceOrientation doesn't affect the transform, bounds, center, or frame properties directly. However, when the device orientation changes, the view controller will automatically resize its subview (which will in-turn resize it's subviews and so on).
See Responding to Device Orientation Changes and View Controller View Resizing for more details.
Well although it's late in the dark night, I don't get it why there are two different rectangles: frame and bounds.
Like I understand it, one single rectangle would have been just enough to do everything. Positioning the View itself relative to another coordinate system, and then clipping it's content to a specified size. What else would you do with two rectangles? And how do they interact with each other?
Does anyone have a good explanation? The one from the Apple docs with the kid holding the fruit is not very good for understanding.
Here's the cheatsheet:
frame is where the view is (with respect to the superview)
bounds is where the view is allowed to draw (with respect to itself)
Some more clarification:
If you are positioning the view in its superview, you almost always change the frame origin.
If you are clipping where the UIView is drawing, you almost always modify its bounds.
Note that you are allowed to have bounds that is bigger than the frame. That is, you can draw "outside the lines" of where you are.
Frame is in the superview's coordinate system, bounds is in the view's coordinate system. From my perspective, it is a convenience to have both. Frame seems to be the more useful of the two, unless there is some case I am unaware of where a subview can have a completely different coordinate system (e.g. pixels scaled differently) than the superview.
I've been having troubles with bounds lately and have done some experimentation. The bounds property does limit where a UIView can draw, but does not limit its subviews. The other thing bounds controls is touch event dispatching. A view will not, as far a I can tell, receive touch events that are outside its bounds. Furthermore, any subview that outside of the parent view's bounds will also not receive touch events. In these situations, you have to pretty meticulously update the bounds of the container view as the size and position of its subviews change. Everything will always draw fine (because subviews aren't clipped by the bounds of their parent) but touches won't be received.
(This really should be a reply to an earlier post, but since I can't reply yet, it's stuck here...)