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.
Related
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.
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.
So I have a "main" View linked with my main .h/.m ViewController files.
In a process of the application, a second View is called that overlays part of my main View in a "popup" style.
I'm wondering if it's a good idea to use the original main ViewController .h/.m files for both the main View, and the second View? If not, I'm genuinely interested in why that is not to be considered a good idea. If this is in-fact a standard practice, what is the cleanest way to do so?
It's typically good practice for your view controller to "control" what comes on and off the displayed view its responsible for. If you are just presenting something very simple, it would be fine leaving it (the code) in your view controller - an example of this might be a background view with a different color.
If however, your view has many responsibilities, such as responding to touch events, you may want to create a subclass of UIView and put your code in that file. Then back in your original view controller, you would simply import that subclass and instantiate the view and present it (add subview) when needed.
Using a common pattern like delegation, your subclassed UIView would control it's own logic and perhaps via delegation, send messages back to the view controller when needed for items like dismiss, or save or any number of functions it might do. A common example of this is UITableView.
hope that helps
I am new to iOS development, with a couple of years of Android experience. I started directly with XCode 5 and the Storyboard paradigm. I like the visual approach to sketching out the flow of an app, but IMHO, it does not really force component reuse, or maybe I do not know how to do it.
I have an actual problem, which is the following: Instead of the typical master-detail approach, I have a situation, in which clicking on a TableView cell forces a push to another TableView, which looks the same and behaves the same way. There are two specific types of a TableViewCell that I want to reuse across the whole application, so I can't just duplicate the first TableViewController several times. I need changes in one type of TableViewCell to be affected everywhere, same for the look and behaviour of the Tableview. Sort of like reusing a component, you get the picture I hope.
I tried creating a custom TableView and TableViewCell in a separate xib file, connecting it to a custom controller class. Yet, when I want to reuse that controller class in the storyboard, I can't make a segue from the cell to the next one, because only view controllers are displayed, but no views inside.
Maybe, I am doing it all wrong. Perhaps, I should make a single controller, and force it to seque to itself if possible, no idea.
What would you do?
You can do programatic Segue from the didselected.....
#import "someVC.h"
Then when you want to Segue to the new VC
// Create a VC and remember to set the Storyboard ID of someVC (example someVCID)
someVC *newView = [self.storyboard instantiateViewControllerWithIdentifier:#"someVCID"];
// Can't remember how this works but you can change the Transition method
// newView.modalTransitionStyle = UIModalTransition;
// If you want to pass data, setup someArray in the someVC .h with #property (nonatomic, strong) NSArray *someArray;
newView.someArray = MyLocalArray;
// Animated or not
[self presentViewController:newView animated:NO completion:nil];
If what you're trying to do is performing a segue on the same UITableView you can check this answer by Rob
I'll report what it contains for completeness:
If you're using dynamic cell prototypes, you obviously can do a segue
from the table view cell to the controller without any problem.
When you make your segue, you end up with:
But let's imagine for a second that there's some reason that doesn't
work for you, e.g. you could not have a segue from the cell (for
example, you need to invoke segue from didSelectRowAtIndexPath, not
upon selecting the cell). In this case, you couldn't use that previous
technique.
There are a couple of options in this case:
As pointed out by Chris, if only supporting iOS 6 and above, use the above technique, but (a) make sure your
didSelectRowAtIndexPath uses self for the sender and then have
shouldPerformSegueWithIdentifier only allow the segue if the sender
== self (thus when the sender is the table view cell, it will be canceled);
Perhaps even easier, just don't define a segue at all and have your didSelectRowAtIndexPath manually
instantiateViewControllerWithIdentifier and then push/present
that view controller as appropriate; or
You can use the following, kludgy work-around: In short, add a button to your view controller (drag it down to the bar at the
bottom), where it won't show up on the view, but you can use its
segues. So first, drag the rounded button to the controller's bar at
the bottom of the scene:
Now you can make a segue from that button to your view controller:
And thus, you end up with the self-referential segue again:
You must give that segue an identifier, so you can invoke it
programmatically via performSegueWithIdentifier, but it works. Not
the most elegant of solutions, but I think it's better than having an
extra scene on your storyboard.
None of these are ideal, but you have lots of options.
well.. in iOs think about it differently, if i were you i would create multiple ViewController, even if they're almost the same, and create a custom cell class, and make this cell take a configuration block.
Now for each ViewController (( or TableViewController )), you reuse your same custom UITableViewCell and just pass it what's slightly different for each case, and moreover you can also create a BaseTableViewController that will have the general configuration, and in each ViewController pass the custom changes you need.
Think about it, when you look at your storyboard you'll be able to see all your workflow, and when something goes wrong you'll be able to debug, if you have are gonna use what you suggested, debugging will be a real pain i imagine.
Anyway, try it out, and ask more if you need further clarification.
I have a storyboard with a navigation controller that leads to an UIVIewController that I want to reuse. That UIVIewController has a ParentUIViewController that has all the basic functionalities for all the UIVIewControllers that I am reusing.
Currently I am copying and pasting (meh) and then I change the class of the UIViewController to the ChildUIVIewController that I want to use (ChildUIViewController extends ParentUIViewController).
But this sounds like a bad solution. Everytime I want to change the ParentViewController visually I need to update, manually, all other ChildViewControllers.
I have tried to create a xib for the ParentViewController but the xib isn't loaded because I need a xib with the name of the ChildViewController. I have created it and then said the class is the ParentViewController but it crashes in the segue.
EDIT
I have created an example of the status of my problem
https://github.com/tiagoalmeida/storyboardexample
Note that the ParentViewController has a set of logic way more complicated that is not illustrated there. Also note that I am also using a TableView. I hope that this can illustrate the problem.
Keep the logic on the parentViewController and the UI Part on the child UIViewControllers. If you need to create a new UIViewController, you will create a child that will have a corresponding XIB (or get rid of XIBs and create the interface by hand).
Have you considered looping back into the same UIViewController via a "phantom button"?
Have a look at this: UIStoryboard Power Drill, Batteries included
Essentially you can drag a Bar Button Item into the little black bar under the View Controller in Storyboard (the 1 with View Controller, First Responder, and Exit icons; sorry, I don't recall what this is called exactly), then you can control+drag from that button back into the UIViewController for a Push segue. This should create a loop segue in your Storyboard. All you need to do next is give that segue an identifier, programmatically call it from your code using [self performSegueWithIdentifier:], then implement -(void)prepareForSegue: and use [segue destinationViewController] to conditionally set the title and perhaps some flags so you can identify when to use different kinds of fetches (or other code variations) in the same Class code.