Asked  7 Months ago    Answers:  5   Viewed   39 times

UIView and its subclasses all have the properties frame and bounds. What's the difference?



The bounds of an UIView is the rectangle, expressed as a location (x,y) and size (width,height) relative to its own coordinate system (0,0).

The frame of an UIView is the rectangle, expressed as a location (x,y) and size (width,height) relative to the superview it is contained within.

So, imagine a view that has a size of 100x100 (width x height) positioned at 25,25 (x,y) of its superview. The following code prints out this view's bounds and frame:

// This method is in the view controller of the superview
- (void)viewDidLoad {
    [super viewDidLoad];

    NSLog(@"bounds.origin.x: %f", label.bounds.origin.x);
    NSLog(@"bounds.origin.y: %f", label.bounds.origin.y);
    NSLog(@"bounds.size.width: %f", label.bounds.size.width);
    NSLog(@"bounds.size.height: %f", label.bounds.size.height);

    NSLog(@"frame.origin.x: %f", label.frame.origin.x);
    NSLog(@"frame.origin.y: %f", label.frame.origin.y);
    NSLog(@"frame.size.width: %f", label.frame.size.width);
    NSLog(@"frame.size.height: %f", label.frame.size.height);

And the output of this code is:

bounds.origin.x: 0
bounds.origin.y: 0
bounds.size.width: 100
bounds.size.height: 100

frame.origin.x: 25
frame.origin.y: 25
frame.size.width: 100
frame.size.height: 100

So, we can see that in both cases, the width and the height of the view is the same regardless of whether we are looking at the bounds or frame. What is different is the x,y positioning of the view. In the case of the bounds, the x and y coordinates are at 0,0 as these coordinates are relative to the view itself. However, the frame x and y coordinates are relative to the position of the view within the parent view (which earlier we said was at 25,25).

There is also a great presentation that covers UIViews. See slides 1-20 which not only explain the difference between frames and bounds but also show visual examples.

Tuesday, June 1, 2021
answered 7 Months ago

Try it and see is the only way forward on the iPhone, because like you say, despite the volume of the documentation that ships with the SDK, it's not very specific in many cases.

As for opaque though, this is just a hint to the compositing engine that tells it it doesn't need to bother to displaying any layers that are covered by the opaque layer. However, the compositing is done by the graphics chip on the phone, so in many cases it is not more efficient to not draw the obscured part of a partially obscured layer, which is most likely why you are not seeing things get messed up at the moment (i.e. cocoa is ignoring the setting in the cases you've tried). By the same token you are not seeing a performance improvement from setting opaque to true.

So my advice would be to stick with using the opaque property the way the docs say because you are risking a buggy rendering for no real benefit.

Saturday, August 14, 2021
The Coding Wombat
answered 4 Months ago

Besides the shadowing and so on mentioned in the previous answers, using this is more generic and thus will work more effectively in certain scenarios. Let me illustrate.

var object = {
    name: 'John Doe',
    print: function () {

var anotherObject = Object.create(object);

object.print(); // John Doe
anotherObject.print(); // John Doe = 'Jane Doe';
console.log(; // Jane Doe
anotherObject.print(); // John Doe

What I'm doing here is that I'm creating an object that has a name 'John Doe' and then I create anotherObject that inherits from it. Now in this scenario, you would expect anotherObject.print() to print its own name. But it doesn't.

This is because your function is tied to that particular object. If I would have used this instead, it would have referred to the new object appropriately.

Also, imagine what happens if I were to do this.

anotherObject.print() // Error!

This is because even though you think it has nothing to do with that previous object, its function still refers to that very property. Doesn't it?

Hence, keep it generic. Use this. Keeps your code drier, I say.

Saturday, August 14, 2021
answered 4 Months ago

This is the raw material design theme, which is used by Android 5 and upNot sure how this works wrt. new Android libraries for app design:

<style name="AppTheme" parent="android:Theme.*">

This is a way to use material design on pre-lollipop devices, which maintains compatibility.

<style name="AppTheme" parent="Theme.AppCompat.*">

You can design for newer APIs using AppCompat and still have it work on earlier API levels than what the base level for material design is.

In this case, it essentially means that you can run material design on platforms that predate material design. This isn't as important anymore now that versions that early make up at most ~2.5% of the market share at the time of writing.

Note, however, that using AppCompat does give you additional compatibility helpers beyond just being able to use the material theme on older devices. Also note that AppCompat has since been deprecated in favor of whatever system is currently mainstream and that Google hasn't axed yet (Jetpack?), which may or may not work differently.

Thursday, October 7, 2021
answered 2 Months ago

I just found the answer to this. I realised that the superview of the UIView has the userInteraction set to disabled (which is the default value). So when I enabled the userInteraction of the superview, the touches are now recognised.

Monday, November 1, 2021
answered 1 Month ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :