IOS4 note 15 (4) Bounds and Center

Bounds and Center

 

Suppose we wish to give a view a subview inset by 10 pixels. The utility function CGRectInset makes it easy to derive one rectangle as an inset from another, but what rectangle should we use as a basis? Not the superview’s frame; the frame represents a view’s position within its superview, and in that superview’s coordinates. What we’re after is a CGRect describing our superview’s rectangle in its own coordinates, because those are the coordinates in which the subview’s frame is to be expressed. That CGRect is the view’s bounds property.

So, the code looks like this:

UIView* v1 = [[UIView alloc] initWithFrame:CGRectMake(113, 111, 132, 194)];

v1.backgroundColor = [UIColor colorWithRed:1 green:.4 blue:1 alpha:1];

UIView* v2 = [[UIView alloc] initWithFrame:CGRectInset(v1.bounds, 10, 10)];

v2.backgroundColor = [UIColor colorWithRed:.5 green:1 blue:0 alpha:1];

[self.window addSubview: v1];

[v1 addSubview: v2];

[v1 release]; [v2 release];

 

 

You’ll very often use a view’s bounds in this way. When you need coordinates for drawing inside a view, whether drawing manually or placing a subview, you’ll often refer to the view’s bounds.

 

The screen also has bounds, and functions in that sense as the window’s superview, even though a UIScreen isn’t a view. Moreover, the window’s frame  is always set to the screen’s bounds (see the example earlier  in this chapter of creating a window in code). Thus, window coordinates

are  screen  coordinates. For  example, when asking  the  screen  for  the applicationFrame, the answer comes back in screen coordinates, which are  also window  coordinates,  and  can  thus  be  used  for  positioning something within the window.

Interesting things happen when you set a view’s bounds. If you change a view’s bounds size, you change its frame. The change in the view’s frame takes place around its center, which remains unchanged.

So, for example:

UIView* v1 = [[UIView alloc] initWithFrame:CGRectMake(113, 111, 132, 194)];

v1.backgroundColor = [UIColor colorWithRed:1 green:.4 blue:1 alpha:1];

UIView* v2 = [[UIView alloc] initWithFrame:CGRectInset(v1.bounds, 10, 10)];

v2.backgroundColor = [UIColor colorWithRed:.5 green:1 blue:0 alpha:1];

[self.window addSubview: v1];

[v1 addSubview: v2];

CGRect f = v2.bounds;

f.size.height += 20;

f.size.width += 20;

v2.bounds = f;

[v1 release]; [v2 release];

 

What appears is a single rectangle; the subview completely and exactly covers its superview, its frame being the same as the superview’s bounds. The call to CGRectInset started with the superview’s bounds and shaved 10 points off the left, right, top, and bottom to set the subview’s frame. But then we added 20 points to the subview’s bounds height and width, and thus added 20 points to the subview’s frame height and width as well. The center didn’t move, so we effectively put the 10 points back onto the left, right, top, and bottom of the subview’s frame.

 

When you create a UIView, its bounds coordinate system’s (0,0) point is at its top left. If you change a view’s bounds origin, you move  the origin of  its  internal coordinate system. Because a subview is positioned in its superview with respect its superview’s coordinate system, such a change will change the apparent position of a subview relative to its superview. To illustrate, we start with our subview inset evenly within its superview, and then change the bounds origin of the superview:

UIView* v1 = [[UIView alloc] initWithFrame:CGRectMake(113, 111, 132, 194)];

v1.backgroundColor = [UIColor colorWithRed:1 green:.4 blue:1 alpha:1];

UIView* v2 = [[UIView alloc] initWithFrame:CGRectInset(v1.bounds, 10, 10)];

v2.backgroundColor = [UIColor colorWithRed:.5 green:1 blue:0 alpha:1];

[self.window addSubview: v1];

[v1 addSubview: v2];

CGRect f = v1.bounds;

f.origin.x += 10;

f.origin.y += 10;

v1.bounds = f;

[v1 release]; [v2 release];

 

Nothing happens to the superview’s size or position. But the subview has moved up and  to  the  left so that it is flush with its superview’s top left corner. Basically, what we’ve done is to say to the superview, “Instead of calling the point at your upper left (0,0), call that point (10,10).” Because the subview’s frame origin is itself at (10,10), the subview now touches the superview’s top left corner. The effect of changing a view’s bounds origin may seem directionally backward — we increased

the superview’s origin in the positive direction, but the subview moved in the negative direction — but think of it this way: a view’s bounds origin point coincides with its frame’s top left.

We have seen that changing a view’s bounds size affects its frame size. The converse is also true: changing a view’s frame size affects its bounds size. What is not affected by changing a view’s bounds size is the view’s center. This property, like the frame property, represents the view’s position within its superview, in the superview’s coordinates, but it is the position of the bounds center, the point derived from the bounds like this:

CGPoint c = CGPointMake(CGRectGetMidX(theView.bounds),

                        CGRectGetMidY(theView.bounds));

A view’s center is thus a single point establishing the positional relationship between a view’s bounds and its superview’s bounds. Changing a view’s bounds does not change its center (we already saw that when we increased a view’s bounds size, its frame expanded around a stationary center); changing a view’s center does not change its bounds.

Thus, a view’s bounds and center are orthogonal (independent), and describe (among other things) both the view’s size and its position within its superview. The view’s frame is therefore superfluous! In fact, the frame property is merely a convenient expression of the center and bounds values. In most cases, this won’t matter to you; you’ll use the frame property anyway. When you first create a view from scratch, the designated initializer is initWithFrame:. You can change the frame, and the bounds size and center will change to match. You can change the bounds size or the center, and the frame will change to match. Nevertheless, the proper and most reliable way to position and size

a view within its superview is to use its bounds and center, not its frame; there are some situations in which the frame is meaningless, but the bounds and center will always work.

We have seen that every view has its own coordinate system, expressed by its bounds, and that a view’s coordinate system has a clear relationship to its superview’s coordinate system, expressed by its center. This is true of every view in a window, so it is possible to convert between the coordinates of any two views in the same window. Convenience methods are supplied to perform this conversion both for a CGPoint and for a CGRect: convertPoint:fromView:, convertPoint:toView:, convertRect:fromView:, and convertRect:toView:. If the second parameter is nil, it is taken to be the window.

For example, if v2 is a subview of v1, then to center v2 within v1 you could say:

v2.center = [v1 convertPoint:v1.center fromView:v1.superview];