I watched the WWDC tutorial on using storyboards, and can see the benefit if you're using tableviews, but I can't quite see how you would use them otherwise.
For example, if I am using a MKMapView, and I present a pin, and a callout for that pin, if I want to go to my next view controller, as far as I know, I have to go to the next detail view controller in code and cannot use a storyboard or segue in this scenario. Or am I mistaken and there are some added benefit in presenting view controllers through storyboards when you aren't using UITableViews? Thanks.
Segues work when triggered by UI elements other than table cells.
They also work when requested in code. For example, create a segue between two controllers (not views or controls) and it can be invoked from code anywhere in the source controller using performSegueWithIdentifier:(NSString *)identifier sender:(id)sender.
Related
What is the best implementation of a tableview in Model View Controller?
I'm developing my app without storyboard, all programmatically .
Is it possible to implement a TableView in a UIView? I tried it, but If I implement the TableView in a view, when the controller recives a button action, I can't modify or access to the tableView of the View...
After that, I tried to implement the tableView in a ViewController and it works perfectly, but I don't know if this is a good implementation because I found the same problem when I wanted to implement a TextView/TextField with a Piker, for example.
My goal was to had a clean code of viewController with a views and controllers (of buttons etc) and now I find myself with a uiviewController with the view and multiples components when I wanted the components were in the corresponding views.
Thank you very much!
It is all possible, and the problems you are running into are not because of it being something that you should not do, but that it is something that inherently works slightly differently than before. To answer your question directly, I would implement the tableView as the modal view controller directly, either as a UITableViewController or a UIViewController that inherits the table views delegate and datasource (this method being chosen if you don't want the table view to use up the entirety of the modal view controller's space).
TableViews are simple to use, but understanding every detail of how they work will make you far stronger and able to use them in any of these scenarios. I am not going to write you a guide on their use, butcontinue studying them before you declare that anything "can not be done".
Knowing what classes to implement the delegate methods becomes very important during these different scenarios. It is often easiest to use textfields delegate's implementation in UITableViewCell's subclass rather than in the UIViewController they are in. This allows for a more modular creation.
I find that working with the storyboard allows for a much quicker learning curve, and also a time saver. The one excuse I will give you for working without a storyboard is if you have an extremely slow computer.
I am new in developing iOS apps. I am trying to develop a multiple views app. My doubt is how to manage a multiple views app with View Controller, I mean, I do not want to use Navigation Controller nor Tab Controller.
My idea is to show a first View to choose the language, and after this, I want to show some different profiles in a table view. When you choose the profile, you get into a menu where you have some different functionalities (Once in this menu, I might use Navigation Controller).
My problem is that I don't know how to manage these two first views. I don't know if I have to declare them in the appDelegate, or if I can do it nesting one to other, I mean, I do the first view, and when I pressed the button, I declare the new view. Once in the new view, when I pressed a row in the table view, I make the another view.
I know it is a little bit confusing, so I hope you could understand it quite well.
EDIT:
I want to clarify that I am not using storyboards. My main doubt is what to do with all de view controllers, Do I have to declare all of them in the appDelegate? or Can I declare each view in every controller?
If you are using storyboards, you can use Segue's to navigate between the views, so you would show your first view, then you could tie a button to the next view (by control dragging in storyboard). If you want to transition programmatically you can use the performSegueWithIdentifier method. You could use the same approach to get from your tableViewController to your next viewController by using the performSegueWithIdentifier method from within the tableViewController's didSelectRowAtIndexPath delegate method (i.e. when a user taps a cell).
That should get you started. Good luck!
EDIT:
You really should be using storyboards. It's the way to do things these days. If you refuse, then the best approach is to create a container view controller that manages your "children" view controllers. You can find information on doing this, as well as the methods needed to present/remove child view controllers here:
Custom Container View Controllers
You can use navigation controller with "hidden" property.
self.navController.navigationBarHidden = YES;
If you want to have two different views and transition between them, you will want to use UIViewControllers presented modally. Here is Apple's Guide to this.
In an iPad application I have a tab Controller containing several view controllers. One of these view Controller (call it MainViewController) needs 2 table views side by side.
So I wrote 2 UITableViewController subclasses and from MainViewController, I alloc/init both subclasses of UITableViewController, and add the tableview from each to the MainViewController's view.
This means that UITableViewController subclasses's views are subviews of MainViewController's view.
This answer: https://stackoverflow.com/a/7684648/191463 says that doing that is incorrect and it seems Apple are starting to cut down on it.
I really do not want to have to put all the code from both UITableViewControllers in MainViewController, as it will make it much harder to read and in future could create duplicate code, if I want to use one of the tableview elsewhere in the app by itself.
Is this actually a problem, if it is how do I do it properly?
Apple isn't cutting down on it. This is the only way to create custom container view controllers prior to iOS 5. Apple actually listened to the developers and made it easier to do this sort of thing in iOS 5 with child and parent view controller methods, not to mention they made it so it worked hierarchically.
In most cases, this wouldn't actually be a problem in terms of applications crashing or performance or anything. It can be a problem in some cases, because let's say you have a child view controller. You add the view controller's view to your root view controller. Prior to iOS 5, child view controllers were things like navigation controller view controllers, tab bar controller view controllers, and modal view controllers. What happens when you have a button that calls [self.parentViewController dismissModalViewControllerAnimated:YES];? Technically, the view controller isn't being presented as a modal view controller, you added the view to the root view controller view.
In iOS5, you're able to add child view controllers to view controllers and are able to transition from one child view controller to another.
Now even if your view controller doesn't have a different parent, adding a "root" view controller to another root view controller isn't the best way to do it (especially since you don't get access to the parent view controller unless you explicitly create a parentViewController pointer in the child view controller). So in the end, Apple just made it easier and more decoupled.
It is OK to do it so long you take the responsibility of managing the viewController life cycle events
initWithNibName...
loadView:
viewDidLoad:...
.
.
viewDidUnload..
dealloc
memoryWarnings
orientation changes
So if you create a custom "container view controller" it becomes your responsibility to call all these methods on child viewControllers at the appropriate time. Think of it as "If you were to implement UITabBarController" what all will you have to manage regarding the children ??"
It quickly gets complex. Adding another viewController's view as subview is childs play.
iOS 5 does some of this stuff for you by specifying parent child relationship, however I still haven't seen any sample code anywhere yet to point to.
I'd say it is not incorrect or wrong to create view controller containers, especially when Apple engineers do that themselves. UITabBarController, UINavigationController or UISplitViewController - they are all view controller containers. More over many great apps with unique UX do that more common than you think. However the real issue is that it's quite hard to do it the right way, so e.g. view lifecycle, memory management and rotation handling is done properly along the hierarchy of views. Fortunately Apple guys did a decent job and iOS5 introduced lots of functionalities regarding controller containers:
UIViewController class reference
View Controller Programming Guide for iOS
If you're interested how above problems had to be addressed before iOS5, read these two very good blog posts:
Writing high-quality view controller containers
Using view controllers wisely
In iOS5 using storyboard feature I want to create a custom container which will have 2 ViewControllers embedded in it. For Example, embed Table view controller as well as a view controller both in one ViewController.
That is, one view controller will have 2 relationship:
to table view controller
to view controller which in turn will have 4 UIImage view Or UIButton in it
Is creating this type of relationship possible using storyboard's drag drop feature only & not programmatically?
,You should only have one view controller to control the scene. However, this viewController might have two other view controllers that control particular subviews on your scene. To do this you create properties in your scene viewController, in your case one for your tableViewController and one for your view. I like to keep things together so I make both these viewControllers outlets and create them in interface builder. To create them in interface builder pull in an Object from the Object library and set its type to the relevant viewController. Hook it up to the appropriate outlet you just created in your scene's viewController - Note: this is important otherwise the viewController will be released if you are using ARC and crash your app. Then hook these viewControllers up to the view you want them to control and you are done.
Alternatively you can instantiate and hop up your viewControllers in your scenes viewController should you prefer to do this.
Hope this helps.
Edit: On reflection this is not a good idea and actually goes against the HIG you should maintain only one ViewController for each screen of content and instead try to create a suitable view class and have the single view controller deal with the interactions between the various views.
There is a way to do it that isn't too hacky. It is described at the following URL for UITabBarControllers, which you could use the first view controller in the list control the first subview, and the second one control the other. Or, you can probably adapt the code to work with UISplitViewController.
http://bartlettpublishing.com/site/bartpub/blog/3/entry/351
Basically, it works by replacing the tabbarcontroller at runtime after iOS has finished configuring it.
I'm trying to add multiple views inside a UITabBarController. Currently my object hierarchy looks like this: UITabBarController -> UIViewController* -> UIView*. As a more concrete example, the first view controller for my UITabBarController is a UIViewController, and that has three subviews, which are controlled by a UISegmentedControl. Depending on what segment is selected, I push the corresponding view to the front.
I understand that I can use a UINavigationController to manage my three views; however, the data I wish to present is not really hierarchical.
Are there examples of container controllers other than UITabBarController or UINavigationController that I can use for this case? Or is there another approach I should use (I'm currently managing views manually).
Thanks!
Custom view controllers are covered in the View Controller Programming Guide.
If you wanted to change your layout to use the UINavigationController you could remove the segmented control view and have the first view be a table view inside a nav controller. The table would have the three options the segmented control had and tapping on them would push the view associated with that option. This way you've created a hierarchical view layout rather than using the segmented control, which is typically used to toggle functionality rather than control views.
If you choose to do this, these two guide sections would be a good place to start.
There's not really any supporting framework for this - usually you have to manage switching out views in a switched container view yourself.
One approach I have taken in the past is to maintain an array of ViewControllers for each switching view, and take the viewController.view to add as a subview of your switched container view. Then I write code around the switching of the view controllers to call viewWillAppear and viewWillDisappear on the contained view controllers as they are swapped in and out, that makes things much simpler since you can treat them totally separately.
You can write that class kind of generically and then re-use it.