I have subclassed UIViewController to provide common functionality for all UIViewControllers (for example I'm overriding viewDidLoad method). My app uses a bunch of view controllers that are arranged inside tab bar controller and in navigation controllers. Everything is OK, except the fact I have one UITableViewController. I would like to subclass not it but my custom MyUIViewController. I'm able to get the table working by implementing data source and delegate protocols:
#interface MaschinenTableViewController : MyUIViewController <UITableViewDataSource, UITableViewDelegate>
However in this case, I do not have an access to UITableViewController properties. For example, I cannot change the behavior of table row selection because self is MyUIViewController not UITableViewController:
self.clearsSelectionOnViewWillAppear = YES;
Are there any workarounds for accessing those properties?
In this case you will need to add a UITableView variable to the header and set it up appropriately in viewDidLoad, and add it to your view. From this point it will work as a UITableViewController will (as essentially that's all it does!)
Take a look at my article here which takes this approach.
You could also subclass UITableViewController as MyUITableViewController, implementing the behavior you want, and then put a MyUITableViewController as variable to your MyUIViewController.
Did the same as Simon Lee mentioned using the delegate.
But without storing the index anywhere, at the end of didSelectRowAtIndexPath method called the deselectRowAtIndexPath. Worked for me no issues so far.
Related
I have created an UIView in my iPhone app. I want to handle something when user closes or opens when UIView is present as current screen. I thought, i can do this under viewWillAppear:. But, viewWillAppear: is not called in UIView. Does it work only on UIViewController? How can i handle viewWillAppear: or viewDidAppear: for an UIView?
Update: UIView what I created everything through program, not in .xib.
Please advise.
Thanks!
From your message I infer that you wrote your viewWillAppear: method on the UIView class. As you suspect, that method is part of [UIViewController]1, not [UIView]2 therefore it only gets called on the UIViewController.
You should connect the property view of the UIViewController to the UIView object in the interface builder and then implement that method in the UIViewController.
If your view is created in response to an user action,
Update for your update:
You should tag the views either in code (view.tag=1) or IB.
Then you can do if (self.window.rootViewController.view.tag == 1) { ... } from your delegate (assuming you are looking for the view of the controller who is the rootController, otherwise post more details).
It's even better if you define constants on one place instead writing 1 as a literal.
These delegate methods are called every time the superview is presented to the screen and should be implemented in the UIViewControllers.
The gotcha is that these methods aren't called when subviews are presented on the screen, so your superview-view-controller will have to respond to these events accordingly.
You can find more information in this post here.
If you study the documentation for UIView and UIViewController what you will find is -(void)viewWillAppear:animated: is a method of UIViewController and not of UIView, so in order to use it, it must be implemented by subclassing UIViewController. Generally for best practice if you want to follow MVC, any functionality that does not pertain to the view itself should be delegated to the view controller and not be in the body of your UIView subclass.
Create a new view controller with xib file, and then link your custom view class to the view in your xib file.
UITableViewController seems to always hijack the View link in IB. So, if I put UITableView in a UIView and link up the View to that UIView, it still doesn't work. Only the UITableView is shown.
What I'd like to do is use a UITableViewController and put some labels on top of the uiTableView that can be hidden.. Like loading.. and No results found.
The only solution I have come up with is to resort to using UIViewController and then adding a UITableView link to the class and link it up in IB.
Am I missing something here?
It's fine to use a UIViewController, make it implement the table view datasource and delegate protocols, and then hook a UITableView up to it. It's also fine to have the controller's main view be a container UIView, and have a UITableView as a subview of that.
And yes, this is probably the best way to add some kind of overlay view, such as a message label. So I think you're on the right track.
You should also be able to do this using a UITableViewController, instead of a UIViewController that explicitly implements the table view protocols. I've had success with this. I'm not sure what you mean when you say that UITableViewController "hijacks" the view outlet in IB.
It really isn't a big deal either way. UITableViewController doesn't do much other than implement those protocols, provide a different default loadView method, and call [tableView reloadData] by default on viewWillAppear:. If you do those things yourself, you'll be fine.
EDIT 2: I now think the best soluton is to create ListeningView.h that just includes a ListeningView protocol, instead of subclassing ListeningView (since we can't do multiple inheritance in Obj-C). Then, you still need ListeningViewController as well.
EDIT: Ok, I figured out what the approved idiom is here. I should subclass UIViewController to create ResponderViewController, which will loop through its subviews for ResponderViews when it appears/disappears. Then, any viewController that has responderViews should inherit from ResponderViewController.
=======
UIViewControllers have viewWillAppear, viewDidDisappear, etc. delegate methods.
I would like to create a UIView subclass that can be added to a viewController's view, and when that UIViewController apears or disappears, a delegate function is called.
I could easily do this by putting function calls in the UIViewController viewWillAppear/viewWillDisappear delegate functions, but how can I encapsulate this behavior in the UIView?
I wouldn't do that if I were you. All that sort of behavior should not be controlled by a view; that's just was controllers are for.
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.
I have a relatively simple app. I have a fullscreen UIView subclass (musicGridView) that the user interacts with, and a UIScrollView subclass (scrollView) that loads this class in, as well as a ViewController and mainWindow.xib.
Right now, I have a viewController instance loaded in the nib, which is of type myViewController. The nib also has instance of myUIView, which the myViewController is pointed to.
In AppDelegate, I do this:
[window addSubview:scrollView];
[scrollView addSubview: viewController.view];
scrollView.musicGridView = (MusicGridView*) viewController.view;
which I think is wrong. Ideally, the appDelegate doesn't have an instance of scrollView.
In scrollView's AwakeFromNib class, I do the initialization on the scrollView.
The way I think it should go, is load the [window addSubview:viewController.view] in appDelegate, and then point the viewController to an instance of scrollView instead of musicGridView. Then, in scrollView awakeFromNib add a subview of musicGridView.
Eventually, I want to create another view owned by scrollView that is actually a side TabBar (which isn't possible with the given API's) that the user can scroll to the left to reach.
So I guess amongst other MVC stuff, the question is, should the viewController point to the scrollView, which contains all other content UIView subclasses, including musicGridView?
It sounds like you are not using Interface Builder to design your UI. Since this is a new project, I would suggest doing that. You should not have to write any code like this at all. You will however need to describe your outlets and actions.
The two most important things you need to know when dealing with IB are the IBOutlet and IBAction keywords.
Sample class header:
#interface MyClass : NSObject {
IBOutlet UIScrollView* myScrollView;
}
- (IBAction) doWork;
#end
Now you can wire these two things up using Interface Builder by dragging sources to destinations with your mouse. YouTube has lots of tutorial videos on IB if you need a better description of how to do this.
I'm someone who doesn't use Interface Builder for UI design; in my experience, you need to go either all-IB, or all-programmatic. To solve your particular problem, I think you need your musicGridView to be an instance or extension of UIScrollView.
This can be done in your custom viewController's loadView method - simply initialize it to a UIScrollView (and add things to it), instead of a plain old UIView.
However, as described above, this approach isn't compatible with an IB-centric approach, as is confirmed in the UIViewController Class Reference
All subclasses of UIViewController
should implement the loadView method
to set the view property unless you
load your view from a nib file.