I've been using the old way of doing things for quite a while, by setting the origin and size on individual frames and putting things exactly how I want them on the screen. Now i'm trying to move to using AutoLayout. But I'm having a bit of trouble that I cant seem to find an exact answer for.
I'm used to mainly using code for creating views and view controllers. As such, I've come familiar with creating custom view classes which combine multiple views to my liking. For example, i have a custom Profile Pin view that combines a UIImageView and a UILabel into one view to represent a profileImage and username. I then use these custom views in different places as a part of other views and view controllers.
It seems to me that autolayout is intended for views that need re-adjust sizing when screen orientation changes, or for readjusting subviews for different screen sizes.
My question is, should I be meticulous and use autolayout for custom views that have static placement and sizes? Like the UIImageVIew and the UILabel view in the Profile Pin view I described? The positions for the UIImageView and the UILabel view wont change, but the position for the Profile Pin view (their parent) probably will. Should I be using Autolayout for everything? Or is this not a situation that AutoLayout was intended for?
If your custom view has static contents where the size and position of it's subviews never change, then feel free to stick with manual frames internally. There's not much benefit to Autolayout in that case.
What you should do, though, is override intrinsicContentSize and return the correct size. This allows any parent view to use Autolayout to position and know the size of your custom view.
Many UIKit components use this technique - UISwitch being a prime example.
Related
My application gathers input from users and hence it is full of Labels, text boxes and buttons and I have to show or hide set of labels and text boxes based on certain conditions.
To accomplish it, I did the following.
Set fixed height (lets say 30) for all the controls
Set height constraint on each of the controls and created an outlet to the height constraint in the ViewController
Alter the heightConstraint.constant value programatically (between 0.0 and 30.0) based on the scenarios.
Having programmed like this, it is very difficult for me if there is any change in layout. (i.e., if user requested to add/remove any particular control from the view Controller).
I am using Auto Layout constraints. Could anyone suggest if there is a better way to accomplish my goal.
I am using IOS9 and Swift.
Many thanks in advance.
You can use UITableViewController with static cells for this case.
For hide/show row or section, you can change the size in the tableView:heightForRowAtIndexPath method.
UITableViewController automatically manages the layout and with static cell you can even create outlet for all the controls.
Have you considered using a table for this? It has mechanisms for inserting and deleting rows and would manage the layouting for you - only part you'd need to care about are the contents of the cells.
Instead of making IBOutlets to the height constraints of all the views that you might need to hide, you can just use the hidden property of UIViews to hide/show the view.
In case you need the view to make space for other views, you could set a simple animation and move the view out of screen bounds. You might face issues with layout constraints but it's surely worth the effort from a UI/UX perspective.
Additionally, if you know that you don't need a view any more you can even remove the view from it's superview.
Auto Layout Constraints allow me to size and lay out views perfectly, without knowing beforehand what screen they will be rendered on. This works reasonably well when I'm drawing a UI on a Storyboard.
Let's move on to creating views programmatically.
My app is running, the interface has been rendered on the screen, I have all the necessary coordinates and the sizing has been done.
I would like to create a few views dynamically, for instance:
a UIImageView, that appears at the press of a button, gets animated, then disappears
a collection of custom UIView, created and laid out on the screen depending on the underlying data model (imagine a sequence of events here, arranged on a custom timeline)
In similar scenarios, I still tend to use the good old frames, e.g.:
let myView = UIView(frame: CGRectMake(x, y, w, h))
without adding any NSLayoutConstraint.
Is there any definite advantage of using constraints instead, given the added complexity, especially when you need to animate views?
The most important aspects are when you actually calculate your frame (which method), if you want universal support and if you need to support various orientations.
Inside a viewController, if you print out your self.view frame in viewDidLoad and viewWillAppear: or viewWillLayoutSubviews, it might have different values. The final frame (for example, the one for iPhone 6 plus) is not calculated in viewDidLoad. So if you make your view setup there, the calculation will be wrong.
But with constraints, it does not matter where you add them. You might need to call layoutIfNeeded after the view changes, but you don't need to worry weather the frames have their final value.
For views that are visible only for a short time, auto layout could make a difference for different orientations. By using frames, you will have to update the frame of your temporary view in the orientation change callback.
Also, if you use auto layout in the storyboard, using static frames for views created programmatically might not give you the results you are expecting. But, of course, it depends on the particularities of your project.
I designed about 40 view controllers using a 5.5 inch storyboard layout. After all of that I tested it on the iPhone 4S...big mistake. everything is jumbled together being for a larger screen size. I was able to fix one view controller up using Size Classes. I am wondering if there is any way I can adjust all 40 at the same time, or at least avoid doing this for every single one. It is really frustrating finding this out now. Thanks!
This is a relatively complicated issue you are attempting to solve, but I have two potential solutions. Both suggestions are based on moving your current interface into containing UIScrollView instances
If you are using storyboards, then for each of your view controller scenes, put a UIScrollView as a descendent of the view controller's view. From there, provided your subviews are contained within other views (like a container view for a set of buttons), you can move those into your scroll view. You will have to setup constraints to define the size of the scroll view's content, but this will allow the size of the device to have a smaller impact on the interface as you will get scrolling as needed.
If you are using nib files (.xib) then it is essentially the same thing, but easier. In this case, move a UIScrollView onto the canvas, but not as a subview of the default view. Once that is out there, move the original view to be a subview of the scroll view and set constraints to be 0 from the subview to the scroll view. Finally, right click drag from the File's Owner icon to the scroll view and set that as the view outlet.
Hopefully one of these will help you.
Within the pageViewController:viewControllerAfterViewController: method, just before the return statement, the view which is about to be returned as the next page has the correct view frame size.
However immediately after the pageViewController:didFinishAnimating:previousViewControllers:transitionCompleted: method is called, I check the frame size of the newly introduced view controller ([pageViewController2.viewControllers objectAtIndex:0];) and I find it resized.
Note that, I have set [self.pageViewController.view setAutoresizesSubviews:NO] and the autoresizing mask to None for the newly created ViewController.
Any ideas in which step the new ViewController is being resized?
I think the problem is inherently related to the nature of UIPageViewController. It is built from UIScrollView. I don't exactly know why there is strange resizing behavior, but it seems to be particularly pronounced when the view controllers that make up your pages use auto layout. Seemingly, locking the constraints in your page view controllers to the superview makes the elements resize after the transition because the superview is itself getting resized after said transition.
This sucks because Apple is basically pushing all of us to adopt auto layout. Auto layout is awesome, and I recommend everyone use it from now on, but it really really sucks when you use it with a UIPageViewController. They really ought to either scrap that class or build something easier for developers, something that can be dragged into a storyboard outright.
A few things to consider.
1.) Don't lock anything to the "Top Layout Guide" or the "Bottom Layout Guide". Also make sure you have "Constrain To Margins" disabled on any view intended to hug the sides of the screen.
2.) If you are using a label in your individual page / content view controllers, make sure you bind/constrain it to something other than the superview. I wanted to place a label over a UIImageView, so I aligned the label to the leading and top edges of the image view (using AutoLayout constraints only), creating an offset to give the label some margins.
3.) The following would otherwise be a good tutorial. However, it is a bit outdated. I downloaded the project and basically modified it to get a UIPageViewController implementation that works. The only problem with this project is that it doesn't use AutoLayout. I'm currently writing a blog post that more clearly discusses how to use UIPageViewController and Autolayout together.
http://www.appcoda.com/uipageviewcontroller-storyboard-tutorial/
I am pretty confused on how to position the controls on a UIScrollView that extends beyond the associated UIView.
I have a long form that needs to be filled out which is on one long UIScrollView. I have read (but can't believe) that there is no way to use InterfaceBuilder in order to position the controls, but instead you have to hardcode X\Y coords. in code (or in IB, but they still won't show as WYSIWIG)
Do you really have to do this all with hard coded coords ?
If so what is the best approach to accomplish this ? What if certain controls can become "hidden"...do you then need to have code that moves the coordinates of all controls further down on the page up ?
Would a better approach be to put all the controls on different views and then add those views to the UIScrollView (at least you could then "see" them in IB...)
I hope I am missing something :-)
You do not have to do all of this in code.
You can just have an XIB file for your embedded UIView. This can be as large as you need it to be. Then have a view controller that loads this XIB, and add its view to your scroll view (setting the content size appropriately.)
As for hiding controls - XIB files probably won't help you there. But you can hide controls and adjust the coordinates of other controls in code. (And change the content size of your scroll view if necessary.) This might be a reason to have different controls in different subviews of your scroll view's content view.
In IB, you can create your UIScrollView at the top of the hierarchy and give it the height that you want. Then you can set your elements as you want, in a WYSIWYG way. Once you finished, you just set the size of your UIScrollView to the size you want and set it under the hierarchy of your ViewController's UIView, and finally in the code, you set the content size of your UIScrollView to the size it takes. Easy !
I would encourage you to read this http://www.uxbooth.com/blog/mobile-form-design-strategies/, it's good advice if you want to design a long form, in a user friendly way :)