I'm developing an iPhone app for iOS 5.1. I built a UIViewController which has a UITableView with a UISearchDisplayController and other views, all somehow related to the table. The UIVIewController is the delegate and the datasource of the table, and makes some customizations (graphical and business-related) to the table and search display controller. So far, everything was OK.
The problem is that now I want to put this same table (maybe with a different sublist of elements, of the same type) in different controllers (different screens of the app). I tried to add the tableView of my controller as a subview in other controllers, but it doesn't work. I tried to rebuild my table as a subclass of UIView (instead of UIViewController) and add it as a subview, but it neither worked (it loaded the view from a NIB file, but all its properties, including the IBOutlets, where nil or 0x000000).
After searching a lot, I didn't find any example of how to reuse a tableview in different controllers. Any hint? Any example? Should I build it as a UIViewController or as a UIView? Which class should be the delegate of the table and searchdisplay, keeping in mind that most of the logic I want to reuse is the code in the delegates?
Thank you all in advance
Wouldn't the easiest solution be to create your own Datasource class (maybe as a singleton) and then reuse this with the other controller? This way, your way of getting and managing the data is abstracted from the way of displaying it. Just the way it should be.
This is what MVC is all about.
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 have created Storyboard with several views calling each other, now I need to create the code
I notice that XCode didn't created .h and .m controller files for each View from storyboard.
Should I create them manually?
Should I keep only one controller? (or few depending of separation of concerns on MVC)
Is there a pattern for developing this?
thanks
The usual approach is one view controller pr. screen full of content. You can imagine having one view controller for a tableview, with any sort of content, and then another view controller that presents that content in a new screen full of content if a row is pressed.
Normally when you have subviews inside of your view controllers, you wire them up in interfacebuilder. Then for instance if you want to populate a view that has a uiimageview and a uiactivityindicatorview inside it, you can control their behavior and how their populated from the view controllers code. You could also if you want something very generic and you feel that one view will probably take up a lot of code in your view controller, create a uiview subclass for it, and then set the class in interface builder.
Did this help? Please let me know if you need more clarification.
It's entirely up to you whether you have a ViewController for each view. If you have many views I would recommend it. Even if you have 2 or 3 views you probably still should. Things can get really confusing when each view has a different task but all have similar IBOutlets.
TLDR; Personally, I would say it was good practice to have a ViewController for each view if each view has a separate task.
I have a regular custom UIViewController that loads a regular iPhone-screen-sized XIB. But I have a subview in the XIB that consists of a few components (UILabel, UITextField, UIButton) that I'd like to factor into a separate XIB, and move the logic controlling these components out of the UIViewController, possibly to a custom UIView object that would load the custom XIB.
I've searched Apple documentation without much luck, and searched for an answer here, but I can't seem to find a clean way of creating a custom UIView, instantiating it in a XIB, and dropping it into another XIB. Is there a clean way of moving this view into it's own XIB and the logic controlling it out of the custom UIViewController, so I can use it on multiple screens of my app?
(I'm not married to the idea of putting this functionality into a custom UIView, it just seemed like the obvious way of doing it to me. I'm open to any clean way of factoring this into it's own component.)
If you want to know about multiple views in xib u can go through this
Multiple Views within one XIB - iPhone SDK
This may help you.
If you want to create a view in xib without view controller go through this
Using a xib file without initializing a view controller
I think this should be useful
Being new to Xcode and Objective-C I find it hard to get my head around the Interface builder and Objective-C when doing things that are following the basic pattern. I have created a subclass of UIViewController that I want to instantiate several times to make a grid with each row being controlled by an instance of this class. So there will be one root view controller (with navigation etc) that should include/genereate all the instances of the custom sub-viewcontroller.
Now what would be the best way to do this? All examples I can find are about navigation, where one view should replace another, but I want to have all the viewcontrollers visible on the same "page". Do I need to create a nib file for the custom controller at all? I have also been thinking about using the UITableView somehow but inserting my custom viewcontroller in every row.
Any help greatly appreciated!
Apple's documentation recommends using one view controller per screen. It is possible to decompose your interface and use multiple view controllers on one screen if you have a good reason to do it, but Apple hasn't really designed their frameworks to support this, so you'll run into pitfalls if you don't know what you're doing.
In this case, I question whether each row of your grid really needs its own view controller. I find it hard to imagine a case where this would be the best choice, although it's hard to say for sure without knowing more about your app. Some things to consider:
What is your custom controller doing? Is it mostly changing the visual appearance of its corresponding grid row? If so, perhaps it would be more appropriate to subclass the UIView itself.
If this object is really behaving as a controller and not a view, consider implementing it as a subclass of NSObject rather than subclassing UIViewController. The UIViewController for your screen can capture events and delegate them to the appropriate custom controller object, or your custom views can capture their own events and notify their associated controllers of those events directly using a delegate pattern.
If you're sure you have a valid reason to implement these objects as UIViewController subclasses, check out my answer to this question.
I've got a Table view and it's the child of the View ( see the IB hierarchy ) :
I want to start customizing the tableCells, so I assume I'll have to add a tableViewController . Where would I start in this instance ? the TableViewcontroller can't be a child of the MainViewController, can it ?
Cheers,
You would need to add a table view controller at the top level.
Then drag connections from the table to the controller of datasource and delegate
Then drag connections from the controller to the view for "view"
Then change the class of the controller you added (it's the last tab in the inspector) to your custom UITableViewController class (if you don't subclass it it does nothing)
Then make sure that you somehow retain the controller when the nib is loaded. Easiest way is with an IBOutlet in the file's owner.
Sorry if this is a bit general, but the specifics would consume pages. I don't recommend this approach unless you have some experience with this and know what most of the above means, in which case it's possible and sometimes desirable to do this, and good job if you do.
The easiest method, if you just want a simple table view, no special circumstances, is to use the File>New File>UITableViewController with xib for user interface, then go from there with the file it makes, but that isn't your question, so I have answered as best I can.
It would be easier to build a tableViewController class with a table inside that and add the tableViewController to the view instead of reverse-engineering it. The tableViewController will have all your delegate and datasource functions for your table fairly mapped out so you can move whatever you already have into those functions.
As for custom tableViewCells, here's a great tutorial from pragmaticstudio.com on how to do so. He walks you through all the aspects of building a tableViewController and also how to customize your cells in IB.