Auto Layout VS Frame Sizes

Auto Layout vs Frame Sizes

tl;dr
Learn how to use Auto Layout – it's a huge time saver for real-world apps!

Long answer:

Finally it is up to you if you want to use features like Auto Layout or Size Classes that Apple provides. The main benefit of those is not really performance in terms of UI rendering in the final product. It is the time you need to invest into thinking about all edge cases if you plan to develop an app that works on different screen sizes and orientations.

Let's say you want to do all the work you need to do to support iPhone 4/4s screen size, iPhone 5/5s screen size, iPhone 6/6s (Plus) screen size and iPad screen size plus Portrait and Landscape modes for all the above screen sizes yourself (here's a good overview): Well, there's nothing wrong with it, just go for it. You would then, of course, need to test things very carefully and also always keep this list up to date – in each app you are using your own solution. If that's for you, do it.

But most people want to get their ideas out without struggling with things like different screen sizes too much. You could of course extract your own logic from one app to use it in all of your apps, and that's exactly what Auto Layout and Screen Sizes are about. Simply put, Apple has done all of the work to make your frame-setting work in different screens for you. You just need to use their new vocabulary (Constraints) to make it work.

In other words: It's an abstraction layer on top of handling with the screen rendering logic directly. If you don't like it, let it go. But if you're planning to do some serious apps that should work on different iPhone/iPad generations and also plan to maintain those however, then, please, learn how to do things with Auto Layout and Size Classes. It will save you and all future maintainers quite some time in development.

A good starting point is the docs. Or a tutorial like this one on raywenderlich.com.

Apple says the following about this difficulty themselves (in the docs linked above):

In many ways, programmatically defining a view’s frame provides the most flexibility and power. When a change occurs, you can literally make any change you want. Yet because you must also manage all the changes yourself, laying out a simple user interface requires a considerable amount of effort to design, debug, and maintain. Creating a truly adaptive user interface increases the difficulty by an order of magnitude.

BTW:
There's no difference at all in using Auto Layouts or Frames regarding the programming language: Both Swift and Objective-C support both ways perfectly well. It seems you just didn't find out how to change frames in Obj-C yet. ;)

One more thing:
You also don't need to use Storyboards to use Auto Layout. You can use Auto Layout from code. See the docs here. There's even plenty of frameworks trying to make this easier (the original APIs from Apple tend to be not very pretty in many terms), I can recommend SnapKit.

Why use Autolayout/Constraints instead of frame and layoutSubviews?

Spend some time to learn auto-layout. You will be glad you did.

The layout you have shown can be expressed with much more simplicity in Interface Builder, and more importantly, will be more easily updated as new requirements surface.

While it's true that this particular screen, as it is, will work. You will quickly learn as your app grows that it is too labor-intensive to express everything in code.

Note also that if you ever want to run this app on the iPad, the app won't be able to support multi-tasking.

Advantages of setting Constraints vs Setting Frames of UIViews

Setting frames do not guarantee resizing when the frame changes (through rotation). Autolayout does guarantee this by adjusting the view based on frame and relative sizes. You would most likely use autolayout in a multi-orientation app.

Frames vs Bounds and autolayout constraints?

Q) **a)**Why is the frame size showing 600*536 whichever screen I may
run it. eg. It prints the same if I run it on a 4s screen or else in
an iPad screen?

**b)**And it always infers the size of my VC in my storyboard!!. eg. If i design the screen in a 3.5 inch VC,the frame size becomes
320.0*416.0.

It will depend on when you check the size of the content view (or the view controller's main view). If you were to check the size in the viewDidLoad() method, you'd see it's the size you see in Interface Builder. That's the size it was saved in the storyboard, and it hasn't been resized for the device yet.

However, if you check the size in the viewDidAppear() method, it should be a size that fits on the device's screen.

If you actually want to mess with the frames directly, you'd probably want to do that in viewDidLayoutSubviews(). At this point the view will have been resized for the device, and you can get the updated measurements and modify the frames. Although it's usually best to just set up constraints properly instead, and let auto layout make the changes.

iOS *Cell Performance: Autolayout vs Frame?

Converting from Auto Layout to frames will be time consuming and will give you the least benefit in performance. Not to mention complications when you develop in iOS7. (See my other answer on this here).

As Kugler's study shows, Auto Layout should be fast enough. Don't forget, frames or Auto Layout, it all comes down to math calculations, something modern CPUs are pretty good at.

In your case, I would recommend quite a different approach. For a start, check that you are manipulating constraints correctly, and in the right place. That means updateConstraints and updatedViewConstraints. Adding or removing constraints is an expensive operation. But really, you should only be doing it once - via those methods - on view creation. Don't forget to check that the constraints have already been created so that you don't get exceptions by adding repeatedly.

Also, remember, you don't need to add or remove constraints if you are just updating a constant. Something you can do outside of those aforementioned methods.

Next, consider what's happening with the table view. It's scrolling fast and cellForRowAtIndexPath is asking for the next cell. In your case, the cells all look pretty different. To solve that, use a different reuseIdentifier for each variation.

As long as your data operation to populate the cell is minimal, you might see a tiny shudder on initial cell creation. However, thereafter the scrolling should be very smooth.

What's the difference between frame and layout in Interface builder's size inspector?

When lining controls up and measuring their distances from each other it's often desirable to think about the controls' locations in terms of the visual space they occupy on the screen, rather than simply their raw frames. In many cases, the visual rectangle a control occupies, and its frame are vastly different. For example, a regular size push button looks to be about 20 points tall on the screen, with a 2 or 3 point drop shadow. In reality, the frame of a properly configured push button is 32 points tall, not ~23. This extra 9 points points of padding isn't visually apparent.

"Layout Rectangle" is the name Interface Builder uses for this concept.

The layout rectangle is useful to look at for applications of measuring and sizing. The Apple Human Interface Guidelines might make the statement that "Two push buttons aligned vertically, and horizontally next to each other should have 12 points of space separating them horizontally." This 12 points of space separating the buttons should be measured from the button's layout frames, not their raw frames.

Using auto layout with UIImageView doesn't preserve frame size

You should not set any frames when using auto layout. You need to add two more constraints for the width and height of the image view.

let imageView = UIImageView()
// your other code here

imageView.addConstraint(NSLayoutConstraint(item: imageView, attribute: .Width, relatedBy: .Equal, toItem: nil, attribute: .NotAnAttribute, multiplier: 1, constant: 100))

imageView.addConstraint(NSLayoutConstraint(item: imageView, attribute: .Height, relatedBy: .Equal, toItem: nil, attribute: .NotAnAttribute, multiplier: 1, constant: 100))

---

Related Topics