I am trying to create a class that is similar in functionality to the UITabBarController, but with some fundamentally different functionality. It is called a dropdownViewController and has a primary content view with a UITabBar-like interface at the top of the screen that allows for other UIViewControllers to be modally presented and dismissed over this primary viewController.
I would like this class to be able to be set up using the storyboard to some extent, and I have created a custom Segue that connects my dropDownViewController class with each of its child viewControllers.
My current solution is to assign identifiers to each of the Segues that are then stored in array within the dropdownViewController. I can call the segues programmatically using the performSegueWithIdentifer: method, but this solution isn't as flexible or intuitive as I would like to to be.
Right now, all the custom Segues that I have setup are connected to the "manual" triggered segue in the storyboard connections panel for the dropdownViewController. (I would put screenshots but this is my first post)
However, I want to mimic the functionality of the UITabBarController class, which has an alternate triggered segue in the storyboard connections panel called viewControllers that each of its child views are assigned to. Unless there are some compile-time macros handling these story board interactions, I assume that the UITabBarController uses these connections to determine what it's view controllers are. However, I can't figure out how to setup this functionality with my own class
After searching around for a solution, it seems likely that this is functionality Apple kept for its own use and is limited to their own classes as a feature in Xcode, but if anyone has solutions or ideas it would be greatly appreciated.
I haven't tried this, but I think you should be able to do it with your own custom segues. In the perform method, you would just add the destination view controller to the source view controller's (DropDownViewController) array of view controllers. In the DropDownViewController's viewDidLoad method (or maybe in an initializer or awakeFromNib, not sure which is most appropriate), you would execute all these segues so that they run right after the controller is loaded like is done for a tab bar controller.
Related
I have a ProductDescription ViewController that gets called from a ProductTable UITableView that I have placed in many ViewControllers.
It doesn't seem very efficient to ctrl+drag a segue for each tableView in the Storyboard, as I have approx 20 of them.
How does one do this programmatically?
You have several options within UIKit to programmatically show a view controller without using a segue:
Push a view controller onto the navigation stack:
pushViewController:animated:
showViewController:sender:
Present a view controller modally:
presentViewController:animated:completion:
The real answer here is to use storyboard references. You shouldn't have the same thing in twenty different spots all trying to link to the same view controller to the point of asking this question.
So, let's create Product.storyboard, a storyboard which simply has two view controllers:
ProductTableViewController
ProductDescriptionViewController
And the appropriate segue between the two controllers.
Now, everywhere else in any of your other storyboards that want to use these controllers with this relationship, simply add a storyboard reference, add a container view controller, and add an embed segue between the container view and the appropriate view controller in the product storyboard.
You can accomplish this same effect even without using storyboard references. Ultimately, the main point is to use container views and make embed segues from everywhere you need this relationship to the first of these two controllers, and then there's just a single relationship created between the two product view controllers.
How should I go about creating a View for the storyboard programmatically? I want to access the labels from the first ViewController object made(automatically to call the IBAction methods of VC). I know that this first object of VC is the one linked to the view in the storyboard(?) and I need to change a label form another file, besides VC. I'm pretty sure the only way to do so would be to access the VC object that is linked to the view, or create one and not go with the default one that is created. If not, how would I go about accessing the labels of the view from another file?
You don't create storyboard objects programmatically. A storyboard is very basically an XML file Xcode uses to call different view controllers. The biggest advantage of using storyboards over NIBs is you can layout transitions or segues, and the advantage of NIBs or storyboards over initiating view controllers by code is obviously the visual interface. So your question doesn't really make sense.
If you want to reference a particular view controller's label from your storyboard you need to create a pointer to that view controller first, but changing it programmatically doesn't make sense because that's what storyboard is for.
That said you may just need to go look for your class name in your view controller's Identity Inspector in storyboard and then edit your label programmatically through an IBOutlet property.
What I need to do is basically build a container(view controller) that can change its child view controller dynamically and also set it's initial view controller dynamically.
I never used the Embed segue before so I thought I'll give it a shot.
However, using it seems to allow me to change the child view controller dynamically using a custom segue between the children view controllers but the initial view controllers seem to be fixed to the one I dragged the segue to in the StoryBoard(The custom segue here would be something alone these lines).
I know I can achieve what i'm looking for by creating x custom segue (where x is the number of children VCs I need) from the container view controller directly to the children and just calling these segues in code based on my needs.
But if that's the only way, what's the reason for using the "Embed" segue, is it only for really simple scenario's ?
An embed segue is not just for really simple scenarii. It can get pretty complicated. A major purpose is to cleanly separate code related to different concerns, that may still coexist on the same screen, into different view controllers. For instance, you could have an authentication controller and a preferences controller, both embedded into a single profile controller.
Please clear some confusions regarding UIViewController
I found this article Abusing UIViewController and here are the links link1 & link2
and summarised points
This is author's (and Apple’s) advice In a nutshell:
One (and only one) view controller should be responsible for a whole hierarchy (or screenful) of UIViews.
Mostly, you should only use one view controller per screen. Essentially the rootViewController of the current UIWindow should be the only UIViewController with a visible view.
Each different screen should have a different view controller i.e. one controller should not control more than one screen.
You should NOT nest custom UIViewControllers within a view hierarchy.
If more than one UIViewController hangs off the application’s UIWindow, only one of these will get the messages for changes in orientation. The other(s) will NOT get these messages.
Nested UIViewControllers are not guaranteed, or likely, to receive messages for changes in orientation or lifecycle messages such as viewDidAppear:, viewWillAppear:, viewDidDisappear: and viewWillDisappear: even though they inherit from UIViewController. Only the topmost UIViewController is certain to get these messages.
Please clear point number 2 and 3
because when we use UINavigationController or UITabBarController we use multiple subclasses of UIViewController. And ios device has only one screen.....
This article Abusing UIViewController highlight apple suggestion
Note: If you want to divide a view hierarchy into multiple subareas
and manage each one separately, use generic controller objects (custom
objects descending from NSObject) instead of view controller objects
to manage each subarea. Then use a single view controller object to
manage the generic controller objects.
and in apple docs under heading of Coordinating Efforts Between View Controllers apple saying
Few iOS apps show only a single screenful of content. Instead, they
show some content when first launched and then show and hide other
content in response to user actions. These transitions provide a
single unified user interface that display a lot of content, just not
all at once.....
My requirement is NOT to use any container or modal or popover, I want to do manual management, I have two view controllers VC1 & VC2. VC1 is the root view controller now I want to switch/transit/move to VC2 what should I do?
VC1 should be the only subclass of UIViewController and VC2 should be the subclass of NSObject to manage a particular view in VC1 hierarchy?(the show hide thing by apple doc).
VC2 can also be the subclass of UIViewController, I just remove VC1 from root view and add VC2 as root view?
or what is the correct way?
Container view controllers (like UINavigationController) allow working around the one-VC-per-screen rule. Since iOS 5, developers have been able and allowed to write our own container controllers (which aren't actually much different from normal VCs). Generally this means that writing non-VC controller objects is less necessary than it used to be.
In your situation, where you want to replace the root view controller, your option 2 makes more sense. Use VCs where you can, and non-VC controller objects only when you can't. Since you're replacing the whole screen's content, just switching the UIWindow rootViewController makes the most sense (edit: alternately, many devs would just use a navigation controller to present the second view, because it's simple and convenient).
In my app, I wanted to show a table in the "full screen," so I created a subclass of UITableViewController. When I want to show the table, I just instantiate it and use pushViewController:animated:. Now I've decided that I actually want to show it as a modal, so I want to give it a navigation bar with a "Done" button. I believe this means that I now need to make this a UIViewController subclass instead of a UITableViewController subclass, since it will now be more than just a table. I'm not really sure if this is something that can be done, though; I've created an xib, but Xcode doesn't seem to want to let me use that xib to create IBOutlets in the .h file, so I don't think the two are "connected."
I ran into this problem once before and worked around it by just creating a new UIViewController subclass and xib and just copy-and-pasting all the stuff I needed from the UITableViewController subclass's files into the new subclass's files. I knew then as I know now that that was a hacky and unpleasant solution, though. Does anyone know how something like this can be done properly?
Also, to avoid this problem in the future, should I just never make top-level views like this in the future and just make sure everything I use pushViewController:animated: or presentModalViewController:animated: with is a UIViewController subclass? Or is it safe to do what I've been doing?
Several things you mention in your question indicate some misunderstandings. First, if you're pushing you table view controller, then it has to be embedded in a navigation controller, and thus will have a navigation bar -- you can add a done button to this bar, if that's all you're trying to change. No need to refactor your code.
If you want to use a UIViewController instead of a table view controller, you should be able to hook up your nib. Did you change the class of the files owner in the nib to your UIViewController class? After you do that, you should be able to hook up the outlets.
There's nothing "hacky" about copying and pasting code from a table view controller into a view controller. I do this all the time, rather than writing out all those files.
I'm not sure what you're asking in the last question. How you get your table view on the screen (pushing or presenting) has nothing to do with whether what you're showing is a table view controller or a view controller. You should use the one that best fits your needs.