This is a very simple simple question, and I believe the answer is “yes, it’s a best practice,” but I just wanted to ask the question.
When creating new views in your storyboard in Xcode, is it a good idea to create individual custom view controller files to handle each view specifically?
Meaning, if I create a new view called “login quiz,” should I create a “loginQuizViewController” that will handle all the code I write for that view?
Short answer:
Yes, each storyboard scene generally has a unique view controller class associated with it. A view controller has a root view, which in turn may have many subviews below that, and each subview might have further subviews. This collection of views is collectively known as the “view hierarchy”.
Long answer:
Yes, each storyboard “scene” has a view controller associated with it. And generally this view controller class is a particular UIViewController subclass which is unique to that particular Interface Builder scene. But you don’t necessarily have to have a view controller subclass and might, for example, use one of the existing classes (e.g. this is not uncommon for navigation controller scenes or tab bar controller scenes).
But if you have any custom logic associated with a particular storyboard scene, then, yes, you would generally have a unique view controller subclass for that particular scene.
Two minor clarifications:
You refer to the “quiz view”.
That’s fine for colloquial purposes, but for the sake of clarity, when we’re talking about everything for this quiz, it’s really a complex hierarchy of views, not just a one.
A single “quiz” scene will be associated with a unique view controller class, and the instance of that view controller class will have a single “root view” (identified with the view property), but that view will have a whole bunch of subviews (e.g. image views, buttons, labels, etc.), and some of those may have subviews of their own.
So one storyboard scene has its own unique view controller class, but is associated with a whole hierarchy of views.
We often think of a scene, and its associated view controller, as representing everything you might see at any given point in time, but it’s not always a one-to-one relationship. Sometimes what you see is composed of several storyboard scenes and their respective view controllers.
For example, if you are using a navigation controller, the navigation controller takes care of the navigation bar at the top, and your view controller might take care of everything under the navigation bar. What is visible on screen is composed of these two view controllers.
Or, in a more extreme example, we can define our own view controller containers. In the example below, when we present A, we can define the bottom half of the screen to be managed by a completely separate scene, B, which has its own view controller:
In this case, both A and B have their own IB scenes and their own respective view controllers. Achieve this by adding a “container view” to the A scene (the light blue UIView in the above screen snapshot).
But the main point is that what you see on screen may be captured by a single storyboard scene and view controller, or it might be composed of several.
A view controller can and probably will contain multiple views apart from the root view it has. That means that usually a view controller owns one ore more views that are subview's of it's own root view. Those views are often also controlled by the same view controller.
When coming from the storyboard most items you see are actually representations of view controllers (others are placeholders). "Login Quiz" sounds like a screen in conceptual terms, so (without knowing your details) it would probably make sense to create a LoginQuizViewController.
Related
I am producing an application written in swift in Xcode, I have reached a point in development in which I need to be capable of instancing views. Ideally I would alter the hierarchy of my program to contain a 'Main' or 'Parent' view, the main view would be responsible for displaying the views given to it.
Instancing other view controllers and passing the instance to the main view would be my goal, however, i am inexperienced with Xcode and swift, I am unsure how to go about including a main view without altering my entire storyboard hierarchy.
Here is an image to give a visual description of the current structure.
The intention is to alter the hierarchy to include a main/ parent / master view, the view would be an empty display item which will display all views as and when needed, ideally I would keep the tab control method.
Mainly and most importantly the view will allow instances of view controllers to be displayed, closed and refreshed without impacting other aspects of the app.
Code seems irrelevant here as my views are handled by the storyboard. Something which would be really helpful to me here would be a brief explanation of how I can handle instancing with the new hierarchy.
Thank you in advance for any help regarding this matter
A view controller can serve as a custom parent view controller of one or more child view controllers, displaying their views in any desired manner within its own view's interface.
You can instantiate a view controller in any desired manner. If you wish to pluck a view controller instance out of the storyboard (because you have already designed its view there), call:
https://developer.apple.com/documentation/uikit/uistoryboard/1616214-instantiateviewcontroller
Your view controller in the storyboard will need to have a storyboard ID string so that you can identify it.
After you've plucked a view controller from the storyboard in that way, to display its view in your interface, you must do the following dance:
The parent calls https://developer.apple.com/documentation/uikit/uiviewcontroller/1621394-addchild
The parent captures the view controller's view and sticks it into the interface as a subview of the parent's own view.
The parent calls https://developer.apple.com/documentation/uikit/uiviewcontroller/1621405-didmove
The two view controllers now stand in a legal parent-child relationship and both view controllers will work properly. They can even refer to one another.
If you wish to remove the child view controller's view from the interface, you must reverse the dance:
The parent calls https://developer.apple.com/documentation/uikit/uiviewcontroller/1621381-willmove with a nil parameter
The parent removes the child view controller's view from the interface
The parent calls https://developer.apple.com/documentation/uikit/uiviewcontroller/1621425-removefromparent
Please read "Implementing a Container View Controller" on the main view controller docs page:
https://developer.apple.com/documentation/uikit/uiviewcontroller
For now I have a single login view controller that hide and adds subviews dynamically based on user interaction. Is it better to have multiple UIViews with one view controller, or multiple view controllers?
The benefit of having children UIViewControllers would be if you needed to care about the view lifecycle in any of the children. For instance, if in some of your subviews (child views) you needed to know if it appeared to trigger some logic, then it would be good to use children UIViewControllers.
Another reason might be, if you wanted to use view controller transitions within your custom container, as described by Apple in the UIViewController class reference:
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIViewController_Class/index.html#//apple_ref/occ/instm/UIViewController/transitionFromViewController:toViewController:duration:options:animations:completion:
But, to me it doesn't sound like you would need this, it sounds like you would just show/hide your views, or otherwise animate them.
But if your views don't care about any of that, and just need to render UI elements, I'd say using children UIViewControllers adds additional complexity without much benefit.
This is under the assumption that either way, all your views are living on the single UIViewController's view. If you are pushing and popping view controllers inside a UINavigationController, or presenting ViewControllers modally, you definitely should use UIViewControllers for that.
Also, you definitely shouldn't put all your view code inside that single view controller. You should use subclasses of UIView, or some other mechanism of making sure you separate your components.
For example you might have:
LoginViewController - organizes and hides and shows the individual views
SignInView - shows the sign in form
RegisterView - shows the register form
...etc
Of course its better to have multiple view controllers for many reasons:
Each view controller has its own code/logic/functionality.
Better for memory management. Once you're done from a view controller, system will automatically deallocates it from memory. Using multiple views will be overload in your system when some views are not used.
Better organisation for your project. You will just present/dismiss/push/pop view controllers and pass data between each other. Instead you will deal with horrible logic for hiding and showing UIViews.
Using one view controller will have a massive amount of code which in long term the project will be an impossible mission to manage.
Having multiple view controllers is better in the sense that you would have more ease at coding them individually. Also Navigation will be good which is good for User Experience.
Memory Management will be efficient.
The MVC architecture(Model View Controller) will instead become Massive View Controller which will be a headache while debugging.
Check out this answer for more clarity. I think you are confused between ViewController and View.
Check out the accepted answer of this question in the link. Hope it helps.
About viewController's "viewDidLoad" and "viewWillAppear" methods
Let's say I have two pages with two UIViewControllers, UIViewController1 & UIViewController2.
If I want to show a UIViewController2 on top of UIViewController1 I have three options:
using UINavigationController pushViewController.
using presentViewController.
addSubView : UIViewController1.view.addSubView(UIViewController2.view)
If I need to a transition between my views, I prefer the third option because it gives me much more control over the views.
Is there any difference between these three options in terms of performance?
Before iOS 6 you were not supposed to do option 3. View controllers were meant to control the entire screen. In iOS 6 Apple added support for parent and child view controllers. You could make another view controller your child and add it's content views to yours.
If you are going to use option 3 then that's what you need to do. If you don't you will have a variety of problems.
There is even support for parent/child view controller built into storyboards. You can add a container view to a view controller, and then control drag from the container view onto another view controller's scene. When you do that the system creates an "embed segue" that sets up the child view controller inside the container view and wires up the parent/child relationship for you.
Your first 2 options are for when you want the new view controller to replace, or at least cover, the first view controller. Option 3 is for when you want a region of your screen to be managed by another view controller.
Option 3 (using a child view controller) does mean that both view controllers will be active and in memory at the same time, so you can't release the covered view controller's data storage while it's inactive like you can in a push or modal presentation. However unless your view controllers hold and present huge data structures this isn't much of a concern. In both a push and a modal presentation the covered view controller sticks around in memory anyway, waiting to be uncovered. You have to take special steps in order to free any memory while a view controller's view is covered and then reallocate it when it is displayed again - something that is unusual.
Just for two view controllers, it will not create major difference. UINavigationController is mainly used to maintain navigation stack.
But as you are having just two view controllers, you can use alternate way also.
If you are looking for transitions with NavigationController, you can use UIView Transitions for customisation of push pop animation.
Please refer following links for UIView Transitions
https://www.objc.io/issues/12-animations/custom-container-view-controller-transitions/
http://www.raywenderlich.com/86521/how-to-make-a-view-controller-transition-animation-like-in-the-ping-app
https://www.captechconsulting.com/blogs/ios-7-tutorial-series-custom-navigation-transitions--more
http://applidium.github.io/ADTransitionController/
I am creating an ipad application, I two view controllers the size screen of an iphone 5 and I would like to show both of them on the ipad screen, as two distinct UIViewControllers though. Is there a way to do it?
I have tried to alloc the second viewcnotrller in the viewdidload of the first, but what I notice is that it alloc the first and the second, but the first is not accessible any more (it looks just like a still image).
You can do it very easily in the storyboard. Just add 2 container views (next to the regular UIViews in the object list) to your controller's view, and size them how you want. You will automatically get 2 view controllers connected to the container views by an embed segue. Just change the class of these 2 controllers to your custom classes, and you should be good to go. If you need to get a reference to these controllers from the main controller, you can get it from the childViewControllers property. Your main controller (assuming it's the initial controller) and the 2 child controllers will all be instantiated at start up with no code necessary.
Check out view controller containment, in which you have a container view controller, which then can load one or more children view controllers. Also see the relevant section in the View Controller Programming Guide. Also see the WWDC 2011 session, Implementing UIViewController Containment.
When using custom container view controller, I don't quite understand why the presenting view controller needs to specify the from, because being the container class, it should already know what's in the view hierarchy, no?
transitionFromViewController:toViewController:duration:options:animations:completion:
Container view controllers sometimes need to put the views of the contained controllers into specific subviews of their own view. (For example, a SplitViewController reimplementation might have left and right positioning views holding the master and detail controller views respectively.) Providing the fromViewController tells UIViewController where in the view hierarchy the new controller's view should be inserted, and also which specific view should be removed after the animation.
(contrary to another answer, the frames of the views aren't set for you at all. You do that, before the call, and in the animation block. The "Creating Custom Container View Controllers" system guide in the docs has a pretty good example.)
As it happens, actually using transitionFromViewController:... appears to be optional. You can manage your view hierarchy manually, with or without animations, and it works fine. I'm still forming my opinions, but I think I prefer to do it manually, to more easily handle cases where one of the VCs is nil.
This is done this way to allow you to have a view controller that has views with viewControllers in it. The from defines the originating view controller and gives the system the ability to position the animations appropriately.
Imaging you had a view with 4 views in it like tiles. the main view controller can consecutively call this on its "child" view controllers and with the from -> to specification, it won't make the assumption that the caller is the from viewController.