I'm looking for a good example on how to populate a UITableView with a class that will also push data to multiple detailed view controllers. One would just be a simple "about" page, the other a mapview. Does anyone have a good example of this or know if it can be done?
This can certainly be done! Although you'll have to explain me what you mean by "pushing" data to view controllers.
Usually, you'll have a class implementing the UITableViewDataSource Protocol to supply data to a UITableView.
Another (or the same!) class would implement the UITableViewDelegate Protocol to tell the table view how to behave and how to look.
Make sure to go through this guide about programming table view in iOS for an overview of the process.
This whole delegation pattern (discussed here) is also useful to work with MKMapView.
For a start, you can look into this example from the iOS Developer Library : https://developer.apple.com/library/ios/#samplecode/CurrentAddress/Introduction/Intro.html
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 using the example shown in the Pulltorefresh library. They have implemented it to fit a TableViewController class. But mine is a UIViewController, and i am adding a TableView in it.
I found a SO answer that shows a workaround for this. Can someone tell me how to implement it as described in the SO answer. Here's the link for the answer
That answer is not talking about using the library you are referencing. They are talking about how you would go about creating a UIScrollView with the "pull to refresh" functionality.
It shouldn't be that hard to transition the code to a UIViewController. Just change the code to subclass UIViewController and setup a UITableView property on the view controller (and make sure to set the data source & delegate of the UITableView to the view controller). There might be more to it but these are the basics. If you ask a more specific question about how to transition it to a UIViewController then maybe I (or someone else) can help more.
maybe you could try a different library?
I've used this one in the past, and it worked great!
http://cocoacontrols.com/platforms/ios/controls/egotableviewpullrefresh
Edit:
Here is the exact tutorial I used. He does exactly what you want. Adds the pull to refresh to a UITableView that is contained in a UIViewController!
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 would like to subclass the UINavigationController to get some more freedom in regards to the appearance of the controller.
I have some graphics for the different parts, bars, buttons, text etc.
Looking at the UINavigationController header file I get little help, I don't know where to start out.
I have never subclassed/overridden a UIKit component before, it seems it is a bit like playing Sherlock Holmes.
What is the approach?
How do I know what to override to get a a specific piece of graphics "injected" the correct place?
Do I need to subclass UINavigationBar, UIBarButtonItem etc. etc to get the complete customized look?
How do I know if something is off limits in regards to being approved by Apple?
Hope someone can point me in the right direction, I have only been able to find examples of changing small parts of the controller, not a full customization by subclassing.
Am I going about this the wrong way?
Thanks:)
Now you can subclass UINavigationController, see updated documentation:
The UINavigationController class implements a specialized view controller that manages the navigation of hierarchical content. This navigation interface makes it possible to present your data efficiently and also makes it easier for the user to navigate that content. This class is generally used as-is but may be subclassed in iOS 6 and later.
UINavigationController Class Reference
You should NOT extend UINavigationController.
As of iOS 6, this information is outdated. From the Xcode 5 docs:
You generally use this class as-is but in iOS 6 and later you may subclass to customize the class behavior.
Original outdated information follows:
From the documentation:
The UINavigationController class implements a specialized view controller that manages the navigation of hierarchical content. This class is not intended for subclassing. Instead, you use instances of it as-is in situations where you want your application’s user interface to reflect the hierarchical nature of your content.
You may want to consider creating categories or subclassing your UINavigationBar and potentially creating custom UIButtons that you use to create UIBarButtonItems.
Whenever you deal with a UI component that extends from UIView what you should consider doing is subclassing and overriding
- (void)drawRect:(CGRect)rect
There are plenty of examples here on stackoverflow or on Apple's official documentation site.
Can someone explain to me the advantages of a UITableViewController over a UITableView? Generally, I use the controller but the basic table view seems a lot more flexible.
I always use UITableView. I never use UITableViewController.
Using UITableViewController is confusing. Each controller is supposed to do one screen except container controllers.
Well, UITableViewController is a controller and most of the time, a tableView is simply not the only thing there.
If you look at documentation:
http://developer.apple.com/library/ios/#documentation/uikit/reference/UITableViewController_Class/Reference/Reference.html
UITableViewController provide very little new interface compared to UITableView. None of which is essential.
– initWithStyle:
(duh? I initiate my tableView in nib and I customized a lot anyway)
Getting the Table View
tableView property
(the original tableView)
Configuring the Table Behavior
clearsSelectionOnViewWillAppear property
(okay, just put some code on ViewWillAppear)
Refreshing the Table View
refreshControl property
[tableView reload]?
So you see,
So unless you want your code to look neater (and not much more), there is no reason to use UITableViewController, that I know of.
I don't think you understand your own question.
The UITableViewController is a controller.
The UITableView is a view.
One isn't better than the other, they're completely different objects, used for completely different things.
I'd spend some time learning the Model-View-Controller pattern so prevalent throuought Cocoa and the iPhone SDK.
The Model-View-Controller Design Pattern
The idea is that ViewControllers hold a tree of subviews (and sub viewcontrollers) and manages dispatching events to/from its subviews. For example, you might have a view that holds an image, and that view lives in a view controller that handles orientation changes and memory warnings, etc.
This is one thing I find very confusing about Cocoa: Apple's implementation of MVC (or at least the terminology they use) is questionable. In Cocoa, most views are themselves actually acting in some capacity as controllers insofar as the MVC pattern defines them (just look at UITableView--most of its methods are actually controller methods). Therefore you have Apple's additional concept of a view controller on top of what is already to some extent a controller. The fact that you don't even need to use UITableViewController at all (even with data binding) basically proves that the view is acting as its own controller. In MVC, you can't have a view bound to a model without a controller (that's the whole point of the controller in MVC).
It appears to Apple's developers, that a "view controller" (e.g. UITableViewController) is really more of a slightly higher-level helper/manager class that manages the more low-level UITableView class and enables a few key additional capabilities that pertain more to how the table view interfaces with the general UI of the app.
Additionally, it appears that Apple intends for a view controller to actually be more of a screen controller, recommending only one view controller per screen (presumably meaning you can't nest view controllers). I maintain that calling this concept a view controller is a misnomer.
Please don't hesitate to correct me on this anyone, I'm still very new to Obj-C/Cocoa myself.
UITableView is a view and UITableViewController is a controller that has UITableView as its root view.
So, by using UITableViewController:
You have one root view that is UITableView itself. So it takes less memory than UITableView with a UIView as parent view in its controller.
It provides you with a ready-to-use template, if you needed a controller and a UITableView as its main display view.
Static table views are only valid when embedded in UITableViewController instances.
The link above returns a "Page Not Found." For some reason, even the corrected link returns a "Page Not Found" when hyperlinked (perhaps Apple doesn't allow linking into their developer site).
To find the relevant information, go to Apple's Developer Connection (http://developer.apple.com/index.html) and search on "cocoa model-view-controller design pattern".
In the table of results, select the "Cocoa Fundamentals Guide: Cocoa Design Patterns." On that page scroll down the Table of Contents on the left side until you see the item "The Model-View-Controller Design Pattern." Select that item to read more details about that particular design pattern.