I believe using autoresizing for orientational changes would be good while managing the UI with Autolayout.
So many programmers are recommending against both at the same time,But As far as I understand it should be fine.
Because Autoresizingmask is easy to play with.
I think autoresizing mask itself turns into constraints actually I believe
translatesAutoresizingMaskIntoConstraints
Correct me If I am wrong
If its okay or not okay can some explain in depth why ?
As far as I am aware it is absolutely alright to use both autolayout and autoresizingmasks together. What you don't want to do is add autolayout constraints to a view that you are using autoresizing masks to govern layout. A general use case for autoresizing masks is adding a view to a view and wanting it to be pinned top, bottom,leading, and trailing. In that case it is simply
let pinnedToSuper = UIView(frame: self.view.bounds)
//all views default to .translatesAutoresizingMaskIntoConstraints if added programmatically
pinnedToSuper.autoresizingMask = [.flexibleWidth,.flexibleHeight]
self.view.addSubview(pinnedToSuper)
Notice how much easier this is as opposed to adding each constraint.
Prior to autolayout autoresizing masks were all iOS had to help with layout. Heads up autoresizing masks are also known as springs and struts. An example use case autoresizing masks break down is if you want a view to maintain a perfect square(or to make a circle) keeping aspect ratio and also resizing with the view in all orientations. In this case you would have to add code in layoutSubviews to resize the view manually based on parent bounds. You can see that this could get tedious especially if you are dodging views that are separately being handled by autolayout. This is probably why it is good to be careful when using both. I tend to use it in simple cases such as adding a view that sticks to the superviews bounds.
Important distinction when using together.
You should avoid trying to add autolayout constraints to a view that you are using autoresizing masks to attempt to blend them and achieve a layout because you will likely get conflicting constraints with no real effect. You can however add autolayout constraints to a view that has a subview that is being governed by autoresizing masks and there should not be any issues. This is my typical use case. I hope this helps you with how you might use it.
Related
In my example, I have three buttons at the top of the UIStoryBoard. This works well for non-iphone x devices. However, it gets cut off when I use iPhone x. The buttons go above the safe area.
I was wondering if it is possible for the UIButtons to respect the safe areas without auto layout in storyboard? If not, how do I replicate this layout (UIButtons auto-resizing with flexible width and flexible height) with auto layout and respecting safe areas? I believe I should use aspect ratio on the UIButton's itself. Not sure if this is the proper way.
Turns out the answer is easier than I thought. Just put all the UIButton's inside another view. Then add constraints to that view that respects the safe areas. This way the UIbuttons can still use autoresizing.
Migrating a project using autoresizing masks for iPhone X
I started to create a very simple tic-tac-toe game.
The main goal is to make the view proportional to all screen sizes of all iOS devices.
So I put the image on a ViewController, make it full size of screen and then I put it into a Stack View. I've added constrains to this Stack View 0 to all sides.
And when I ran the simulator then everything looks good. But I receive a message in console panel. What does it mean?
It could happen because you changed the Mode attribute of the StackView:
I got this warning when I set Mode to Aspect Fit.
Any layer change on a UIStackView will result in this warning. As the warning points out UIStackView is a transform-only layer and it differs quite slightly from a UIView. As per documentation:
The UIStackView is a nonrendering subclass of UIView; that is, it does
not provide any user interface of its own. Instead, it just manages
the position and size of its arranged views. As a result, some
properties (like backgroundColor) have no effect on the stack view.
Similarly, you cannot override layerClass, drawRect:, or
drawLayer:inContext:.
More on this here.
It may not point to the exact source of the OP's issue but hopefully, it will shed some light on why UIStackView behaviour is not the same and should not be confused with UIView.
For someone that need: I set clipToBounds to false in StackView.
It looks like what you did is perfectly correct.
However, I'm wondering why you chose to put your imageview into a stackview when you could have just as easily pinned the sides without the stackview. I am a big fan of stackviews but they don't make sense everywhere. Unless you're planning on adding new views, and resizing your ticktactoe board, I might not use it.
I have been searching the proper difference between Auto Layout and Auto Resizing, but didn't able to find the exact answer. Where I can use "Auto Layout" and where "Auto Resizing" in app? Any help would be a part of thanks.
As Matt Neuburg states in his book:
Autoresizing is a matter of conceptually assigning a subview “springs
and struts.” A spring can stretch; a strut can’t. Springs and struts
can be assigned internally or externally. Thus you can specify (using
internal springs and struts) whether and how the view can be resized,
and (using external springs and struts) whether and how the view can
be repositioned.
And
Autolayout, depends on the constraints of views. A constraint (an
instance of NSLayoutConstraint) is much more sophisticated than the
"autoresizingMask" it’s a full-fledged object with numeric values, and
can describe a relationship between any two views (not just a subview
and its superview).
I recommend watching the WWDC 2012 session https://developer.apple.com/videos/wwdc/2012/?id=202
Auto Layout is a new way to define dynamic GUIs. Before, we had autoresizing masks, that described how a subview will resize or move when its superview is resized. With Auto Layout you can do the same and also a lot more complicated GUIs quite easily.
Autoresizing is one of the most useful property for layouting the views in their hierarchies.
go through this link.
http://www.techpaa.com/2012/05/understanding-uiview-autoresizing.html
AutoResizing : Autoresizing means that how the content of a view will fit to the view. It probably depends on the self content of the view.
AutoLayout: AutoLayout means how the external constraints like the position of the view , the size of view supported by the other neighboring components.
AutoLayout triggers the AutoResizing Task and for autoresizing activity , auto-layout forcefully or normally change or break the default constraints of views which are related to the corresponding view if needed.
Use autolayout in the superview with constraints [this helps when there are changes in the space in the View due to different devices(such as 3.5 or 4 inches retina)] and use autoresize for resizing the GUI objects in a view [this helps when there are changes in the space in the View during the orientation of the device]
Problem
Some third party library is used. Some views disappear after their translatesAutoresizingMaskIntoConstraints are set to NO.
Don't have other autoresizingMask setting for my views in my own code; in the library, the autoresizingMask parts of code have been removed too. Instead, explicit bounds/center/frame are set for those views. There're no nib files, views are all programmatically created.
I know some other people solve similar problem by giving a thorough autolayout constraints set, but in my case, I mean to turn off autolayout and do it manually. No idea when autolayout is turned on.
Some people say that "by default, as your app launches, autolayout is switched off, and the system behaves as in iOS 5 and before. But if, at any time while your app runs, the system sees an autolayout constraint (generated in code or by the loading of a nib that has “Use autolayout” checked), the autolayout system is switched on, and from then on you’re running under autolayout." (Programming iOS 6 by Matt Neuberg, pages 383-384), but in my project I don't think there's any autolayout constraints left.
The code is bulky, but will upload some skeleton if necessary.
Thank you for tips!
If you don't want to use Auto Layout you have to set translatesAutoresizingMaskIntoConstraints to YES. Here's a reference:
This works through the property
translatesAutoresizingMaskIntoConstraints. When this property is YES,
which it is by default, the autoresizing mask of a view is translated
into constraints. For example, if a view is configured as in Figure
6-1 and translatesAutoresizingMaskIntoConstraints is YES, then the
constraints |-20-[button]-20-| and V:|-20-[button(20)] are added to
the view’s superview. The net effect is that unaware views behave as
they did in versions of OS X prior to 10.7.
For views that are aware of Auto Layout, in most circumstances you
will want translatesAutoresizingMaskIntoConstraints to be NO. This is
because the constraints generated by translating the autoresizing mask
are already sufficient to completely specify the frame of a view given
its superview’s frame, which is generally too much. For example, this
will prevent a button from automatically assuming its optimal width
when its title is changed.
I want to position a sub UIView (sub_UIView) as a subview of parent UIView (parent_UIView). When the parent_UIView resizing/moving, the sub_UIView would stay the relative position of the parent_UIView. For example, the sub_UIView is at the bottom right corner of the parent_UIView. When the parent_UIView is moving, the sub_UIView would stay at the bottom right corner of the parent_UIView automatically.
I managed to do this manually by updating the frame of the sub_UIView when the parent_UIView's frame moving, but how to do this automatically in iOS? are there any properties for this? (similar to autoresizingmask for resizing subviews)
Updated old response, that only mentioned resizing masks
Autolayout (iOS 6)
In iOS 6, autolayout was added, albeit, kinda ugly to work with XCode in a storyboard/xib. Autolayout is way too big to explain, but the essence of it, is that it's a set of rules between views within the hierarchy. Thus, you can stick the x position of a view to the right border of a parent view. See the Auto Layout Programming Guide
Autoresizing Masks (iOS 2)
Take a look at the options in the Size Inspector:
This is the equivalent of doing
myView.autoresizingMask = UIViewAutoresizingMaskFlexibleTopMargin |
UIViewAutoresizingMaskFlexibleLeftMargin |
UIViewAutoresizingMaskFlexibleWidth |
UIViewAutoresizingMaskFlexibleHeight;
Notice that there's a difference between doing it by code and doing it through IB. The IB autoresizing settings for the borders work as struts, selecting the right one, for example, means, "my right border is now stuck to the superview's right border".
On the other hand, code does the opposite, where you need to specify which borders are not strut-ed, aka. they are flexible. Height and Width works normally.
Layout Subviews (iOS 2, but gotchas for iOS5+)
If everything fails, don't start doing manual positioning all over the place, I've been in that position, and it just leads to unmaintanable, spaghetti code, where three or more methods are messing with the same view properties.
Instead, prefer to do all your custom positioning on UIView -layoutSubviews. This method gets called as needed when a setNeedsLayout has been triggered, for example, when the width a view changes, the subviews get the layout subviews event. Also makes implementing rotating interfaces much easier, since this method gets called for the new width, to determine how the animation will look like.
Keep in mind that layout subviews works after Auto Layout/Auto-resizing masks have been performed.