I have a UIView that contains some controls etc... This UIView also contains a scrollview that will house some content in a UITableView.
I have gotten everything working fine except I can't get the data from my fetchedResultsController to populate the table.
Does my main View need to be a UITableViewController? Currently I have it as a UIViewController, since the UIView is the 'master' view.
As per OP's request, my comment as an answer:
UITableViewController is nothing more than a convenience class that implements the respective data source and delegate protocols on a normal UIViewController, so that won't matter. If you want some more concrete help, you'll have to post some code so people have an idea of what may be going on.
There are two protocols that your controller needs to adopt to make a UITableView work. One is the UITableViewDelegate, and one is the UITableViewDataSource. Make sure that you're hooking up both using setDelegate and setDataSource. In most simple examples, a single controller adopts both protocols.
Failing that, I suggest that you put breakpoints in your protocol implementation methods to ensure they're all getting fired. If not, there's a problem somewhere else, and we'd need to know more about your particular situation...
Related
I am using Swift with Parse.com. I have a bridging header so I presume that I can use objective-C within the swift project, but I get errors sometimes, so I want to make sure that I am using the two languages correctly within the same project.
I remain unclear how I can use tableView to load information from Parse instead of using the tableViewController for added customization. I would like to be able to use the needed methods within the view controller that contains the tableView object, and reload that information to populate that element.
I need to an update on the requirements of proper classes and if I need to subclass, and how. I have generated my own class for the view controller and connected the tableView object, but I remain unclear how I can call the methods from a normal tableviewcontroller, or if I can simply place the needed methods within the view controller. I am learning about the PFClasses and which ones are needed for the functions that are required.
I currently remain unclear about the communication of the delegates, datasource, and other related items in this arrangement. I am completing project. I am still new to objective-C and have not memorized all of the methods and such, so I am still learning.
It is possible to use a plain UIViewController and have a manual UITableView instead of using a UITableViewController. If you do this, you need to make sure that your UIViewController implements the UITableViewDataSource and UITableViewDelegate protocols.
If you are using IB, you also need to make sure you hook up your custom UITableView class to the proper outlets; or you can create your views in code. That's up to you.
Now for parse specific data, what you can do is you can process your parse.com data in a variety of ways; in response to a UI gesture, when the table loads, or in the background. Either way, once you have the parse data loaded, you just need to make sure your UITableView responds correctly in numberOfRows and cellForRowAtIndexPath.
If you get started and have specific questions, feel free to ask more. But in short, yes, it is possible. I actually prefer this over using UITableViewController because it gives me more flexibility. I in general to not use IB.
I've been following the guide in the following (StackOverflow question), which has been very helpful, and by completing the steps I've managed to successfully have a UITableView with a separate controller and delegate/datasource.
However, even though everything is working, I'm unable to reference or change anything instance of the UITableview.
For example: let's say the UIViewController for the table is TableViewController and the separate delegate/datasource class is TableDelegate. I have everything hooked up in interface builder as in the previous SO question. In TableDelegate.m, within viewDidLoad, I put the following:
self.navigationItem.leftBarButtonItem = self.editButtonItem;
And nothing changes in the UITableView as it should. This includes pushing UIViewControllers, which also has no effect as if the code wasn't even there, although when I NSLog(), it appears it is being run.
The odd part, however, is that even though that doesn't work, if I set the table's alpha property to 0, it works.
Thanks for any help in advance, let me know if you need any more information to solve the problem.
From your comments, it looks like both TableViewController and TableDelegate are subclasses of UIViewController. If this is the case, make sure both are being added to the navigation stack by pushing them onto a UINavigationController or adding them to a UITabBarController: otherwise, viewDidLoad may not be called.
As an aside, I don't think it's a good idea to have your UITableViewDataSource be a UIViewController subclass when you've already got a UITableViewController to handle that table view.
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 mean... could I also just create a plain old UIViewController and then set up a UITableView myself, plus an NSFetchedResultsController?
How much do UITableViewController and NSFetchedResultsController interact with eachother? As far as I see it, UITableViewController is NOT by default already adopting the NSFetchedResultsControllerDelegate protocol. It almost looks like if UITableViewController has been developed without knowing about NSFetchedResultsController. Probably they even did that before developing FRC. Anyways, just a raw guess because the UITableViewController lacks of mentioning FRC at all.
So the only thing I see in UITableViewController is that it is already the delegate for a UITableView by adopting the protocol, and it sets up the UITableView instance for me and assigns it internally to it's tableView property. Is that the whole magic of UITableViewController?
(note: the nsfetchedresultscontrolle tag is not a typo. SO has a limit for the num of chars...too bad for that missing r, that's why I avoided this tag in my other buch of questions like the plague)
Yes, you can do that. Your view controller is not required to subclass UITableViewController. However, NSFetchedResultsController is designed to go with a table view. If your UI does not have a table view at all then a NSFetchedResultsController is probably the wrong answer.
I want to create an application which combines a chat feature. My question is this: how can I have a UITextField that is always visible in the same view as a UITableView?
The obvious solution would be to create my own UIView having a UITableView and a UITextField below it, however the UITableViewController doesn't seem to like me doing that as it expects the connected "view" outlet to be a UITableView, essentially destroying my plans.
Anyone with an idea?
Don't use UITableViewController. After all, it's just a standard controller with a full-screen UITableView. You can roll your own easily.
Use a standard UIViewController and have it implement UITableViewDelegate and UITableViewDataSource protocols (you don't need to implement every method -- just the required ones). Then give it a UITableView as an iVar and set the delegate and dataSource to self. Size it so it only takes half the screen and your other views take the other part. You can lay out the whole thing in IB or create and position view+table manually.
I would suggest sticking a regular view in between your controller and your smaller "half-views". That has usually cleared things up for me, or at least exposed what the problem might be.
If you don't need functionality that UITableViewController provided, than you can just use
UIViewController with <UITableViewDataSource, UITableViewDelegate> protocols.
So, your main viewController will accept any type of views.