just as the question title,what does view.center means,
on my first look I think it's the center coordinate,but my practice proved it's not.
for example,I try to usesubView.center = parentView.center
to set subView locates in center of parentView,but not succeed,
so who can tell me the meaning of view.center,thanks!
The subView.center = parentView.center will not work because center of the superview is using its superview coordinates. See UIView Class Reference for more information.
A centre is a CGPoint expressed in terms of the superview's coordinate system and it determines the position of the exact center point of the view.
From Apple Documentation:
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.
Related
I do not quite understand the method convertPoint:toView:.
In Apple's documentation it is written that
convertPoint:toView:
Converts a point from the receiver’s coordinate system to that of the
specified view.
- (CGPoint)convertPoint:(CGPoint)point toView:(UIView *)view
But what does converting a point from one to the other actually mean?
Does it imply that the points in both bounds have different units? Or just different values?
If it is the latter, why is there such a method when we can simply assign the value of a's contentOffset to b's ?
CGPoint a = [a contentOffset];
[b setContentOffset:a];
How is convertPoint:toView: different from simply assigning contentOffset? Or did I misunderstand the entire concept? What does converting points actually do? When should this method be used?
Every UIView has its own coordinates system. So if you have a UIView_1 that contains another UIView_2, they both have a point (10,10) within them.
convertPoint:toView: allows the developer to take a point in one view and convert the point to another view coordinate system.
Example:
view1 contains view2. The top left corner of view2 is located at view1 point (10,10), or better to say view2.frame.orgin = {10,10}. That {10,10} is based in the view1 coordinate system. So far so good.
The user touches the view2 at point {20,20} inside the view2. Now those coordinates are in the view2 coordinate system. You can now use covertPoint:toView: to convert {20,20} into the coordinate system of view1. touchPoint = {20,20}
CGPoint pointInView1Coords = [view2 convertPoint:touchPoint toView:view1];
So now pointInView1Coords should be {30,30} in the view1 coordinate systems. Now that was just simple math on this example, but there are all sorts of things that contribute to the conversion. Transforms and scaling come to mind.
Read about UIView frame, bounds, and center. They are all related and they deal with coordinate systems for a view. Its confusing until you start doing stuff with them. Remember this frame and center are in the parent's coordinate system. Bounds is in the view's coordinate system.
John
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.
In CALayer's API, 'position' is used for setting the position of the layer.
By my own testing, setting bounds.origin does not do anything. Am I missing something?
The bounds.origin controls where the origin of the layer's coordinate system is, relative to the layer's frame in its superlayer. Changing it has two visible effects:
The position of sublayers of the layer. For example, when you scroll a UIScrollView, the scroll view doesn't change its subview's frames. It simply changes its bounds.origin. I suggest setting up a toy app with a scroll view and doing NSLog("scroll view bounds = %#", NSStringFromCGRect(scrollView.bounds)); from a timer or some other trigger to get a sense of what's happening.
The origin of the graphics context coordinate system in drawInContext:. Mostly commonly you would see this effect in a view's drawRect: method. Your CGContext inside drawRect: will have been translated by the self.bounds.origin.
You may find it helpful to read about “View Geometry and Coordinate Systems” in the View Programming Guide for iOS and “Layer Objects Define Their Own Geometry” in the Core Animation Programming Guide, although really neither of them have a good discussion of the bounds origin.
Changing the bounds rectangle changes the position and size of the content in the coordinate system of the layer itself. Changing the frame (or position) changes the position of the layer in the coordinate system of its super layer. Usually you only want to change the frame, not the bounds.
I am rotating the image on slider value -
I am using this code for rotation -
editingView.transform = CGAffineTransformRotate(editingView.transform,sliderVal);
its Rotating properly but if i am trying to move or resize after rotation,The editingView is resizing with unexpected behavior and view disappears from screen.
Please suggest me what i am doing wrong.
Well whenever you rotate a view which is inside a superview, you should preserve the position of the view. If you are not rotating any view across the origin then, you should first translate the view's origin to the superview's origin and then rotate and then again translate back to the original point.
Find the coordinate if the view you want to rotate with respect to its superview, say it (x,y).
Translate the view to the origin as;
view.transform = CGAffineTransformMakeTranslation(x,y)
Rotate the view by some angle, say PI,
view.transform = CGAffineTransformMakeRotation(PI)
After rotation translate back to the original point as;
view.transform = CGAffineTransformMakeTranslation(-x,-y)
And that's it. It should work with all the different rotation.
Have a look at this question.
Since you do not show any code on how you do the move or resizing, I suspect you are not properly concatenating the transforms. Furthermore, after you did the rotation, a translation will possibly work on the rotated coordinate system, therefore leading to unexpected behaviour.
Changing transform value affecting the frame value of UIView. As Apple says:
Warning: If this property is not the identity transform, the value of
the frame property is undefined and therefore should be ignored.
Apple docs
So, if you are moving or resizing your view using frame property, try do this with bounds, center properties
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.