I'm getting the following error
Property 'navigationController' not found on object of type
I've inherited this project and not sure what's going on.
In my m file in didSelectRowAtIndexPath I have
[self.navigationController pushViewController:nextController animated:YES];
It wasn't a problem before as I was accessing app delegate navigation controllers, which were outlets. However, I've had to move away from this approach as it's causing me problems. I've converted the rest of my project. But in this circumstance, where the project isn't using a normal table view, the navigation controller doesn't look to be available. I have this issue in 7 other views. Hoping I could have fixed this, and keep this cleaner code?
I'm really puzzled by this, I think this is occuring as SetsStyleSectionController isn't a view controller but is NSObject.
However, even with this set to UIViewController, the code runs, but doesn't push either.
Changing SetsSectionController from NSObject to UIViewController isn't available.
I'm not sure how to proceed?
I'm in the process of moving away from pushing from app delegate.
Edit: Screenshot 2 discussed below
I see a couple of issues here. You have a misunderstanding about protocols and classes, and you also have an application that interface with a protocol that while well-intentioned is actually making your life much harder than it needs to be.
The first issue you're dealing with is some troubles grokking the difference between protocols and classes, and between adopting a protocol and inheriting from a class. Which is totally fine, this stuff isn't easy. Basically, a protocol is just an interface to an object, and a class provides both an interface and an implementation. In other words, a protocol is just a list of methods that can be called, and a class is both a list of methods and the code to execute those methods. To get a more complete explanation, perhaps you'll be better off going straight to the source - Apple's "The Objective-C Programming Language" will probably help you, so please read about classes and protocols there. I think having done that you'll see why you're not having success giving your id<SetSectionController> instance a navigationController property without explicitly defining one. But do let me know if you have specific questions about this afterwards.
The problem that's harder to fix is this SetSectionController protocol. It has several issues and describing them all is outside the scope of this answer. Here's the thing - the implementation basically requires objects that implement this protocol to know which navigation controller is associated with the table view. This has been up to now provided deus ex machina by coupling them to the application's delegate, and you are right to remove this coupling. But now you have to find another way to get the right data populated into the view controller to push it on the navigation stack.
I think you should move the push logic into the view controller, and for now have the section controller provide an interface that gives the view controller the information it needs. So say the section controller has an implementation like this pseudocode:
- (void)...didSelectRow...
{
id detailsForIndexPath = self.dataForRows[indexPath.row];
DetailViewController *vc = [DetailViewController new];
vc.details = detailsForIndexPath;
[APPDELEGATE.navigationController push:vc];
}
Then I'd add a method to SetSectionController called something like -dataForRow: , the implementation of which would be like the first line of the method above. Then, in your view controller, implement ...didSelectRow... like this:
- (void)...didSelectRow...
{
id<SetSectionController> sc = self.sectionControllers[indexPath.section];
id details = [sc dataForRow:indexPath.row];
DetailViewController *vc = [DetailViewController new];
vc.details = details;
[self.navigationController push:vc];
}
If your section controller is doing anything else useful in ...didSelectRow... make sure to either move it to the view controller or forward ...didSelectRow... on to the section controller for now.
While I do appreciate trying to make complex table sections easier to manage through polymorphism, this protocol wasn't the right way to do it. It blindly copies methods out of UITableViewDelegate and UITableViewDataSource without consideration of whether those are the right questions to be asking something responsible for a single section of a single table. If you still want to use it, I think it will take some significant refactoring to get it into a shape that actually makes your life easier rather than harder. Depending on the complexity of the per-section logic deviation, I might just scrap it altogether. But that's a whole other question really. Hope this helps!
What do you mean it "isn't available"? Do you mean you don't want to/aren't allowed to subclass UIViewController, or are you getting a compiler error? From your comment on your question:
SetsSectionController.h:12:34: Cannot find protocol declaration for 'UIViewController'
you are changing the wrong thing to alter your subclass. As an example:
#import <Foundation/Foundation.h>
#protocol foo <NSObject>
- (void) bar;
#end
#interface lolcats : NSObject <foo>
#end
To change your superclass you change the class name after the colon. Ex.
#interface lolcats : NSObject <foo>
becomes
#interface lolcats : UIViewController <foo>
and you're off and running. However, if you accidentally change the protocol requirement for the protocol
#protocol foo <NSObject>
to
#protocol foo <UIViewController>
instead, or change the protocol you adhere to to <UIViewController>, you'll end up getting the EXACT error you got. You might be confused because the protocol says the object adhering to it must also adhere to the NSObject protocol, and NSObject is also a type of object. The object and protocol are separate things, and all objects inherit from NSObject, and thus inherit the protocol. Basically, it's saying "objects using this protocol must be objects."
Why did you expect this to work? The object is just a standard NSObject that states it adheres to a protocol containing a few methods. Why would it have a navigation controller property? It hasn't inherited it from anything. Regardless, based on your error, you probably just changed the wrong thing. Make sure you change the superclass class name after the colon.
Related
I am relatively new to Objective-C.
I have come to a code on the web that has something like this on rootViewController.m (this is a navigationController based app).
#interface RootViewController (CManagerDelegate) <CManagerDelegate>
#end
#interface RootViewController (PViewDelegate) <PViewDelegate>
#end
two questions:
what are these lines doing in the beginning of rootViewController.m
what are these lines doing in code? Please explain the stuff in parenthesis and between <> in this particular case.
thanks.
In one sentence: The code you posted makes the RootViewController class privately conform to some delegate protocols.
Delegate protocols are used to let a class declare the fact that it understands the messages from another class's objects. For example, a view controller can declare that it understands a gesture recognizer's delegate messages.
The fact that the class internally uses the gesture recognizer is often an implementation detail not relevant to other clients of the class. It is best not to publish this fact in the public interface but put it into the implementation (.m file).
Categories (and class extensions) let you do exactly this: Make a class conform to a protocol without changing the main #interface.
A nice and elegant solution!
Read up on Categories:
http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/objectivec/chapters/occategories.html
And Protocols:
http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/objectivec/chapters/ocProtocols.html
In fact, read all of Apple's Objective-c documentation before going any further:
http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/objectivec/Introduction/introObjectiveC.html
Good luck.
I have an XCode project I am working on that has multiple views controlled by a tabBar that is throwing multiple instances of the error:
"cannot find interface declaration for '~my sub view name~', superclass of '~my sub view name~'
These sub views were created after the original project as new files. Each has a line of code like this:
#interface meViewAndEdit : meViewAndEdit
I see no #import statements either. The project fails to build and I am not sure what i should be setting these to. Should I be referencing my App delegate as the superclass? what is missing here?
UPDATE: (updated)
I changed the interface statements for each of my header files for the views i created as follows
#interface friends : UIView
BUT, it seems that i have a new issue that i'll have to research:
"UIView" may not response to "initWithNibName.bundle"
This is now present in each of the .m files for the views I created.
still learning, thanks in advance for your input.
When declaring a class in Objective-C, you need to specify the class name, as well as the superclass. In your code #interface meViewAndEdit : meViewAndEdit, you are essentially declaring a class that is a subclass of itself. Since you are trying to create a subclass of UIView, the class declaration should look as follows: #interface meViewAndEdit : UIView.
Also, in a comment in another answer, you asked whether or not you need to #import the app delegate in every class. The answer to this is usually no, unless you specifically need to access something involving your specific app delegate class.
I will also make note that it is conventional to give classes a capitalized name. For example, it should be MeViewAndEdit, rather than meViewAndEdit. You only should keep the first letter lowercase if it is the name of a variable or function.
EDIT: The reason that you are encountering the errors in your update is that you are trying to subclass UIViewController, not UIView. On top of this, instead of subclassing either one, you are subclassing the app delegate. Change your line of code #interface subviewname : my_app_delegate to #interface subviewname : UIViewController. You are trying to create a subclass of UIViewController, not my_app_delegate.
On another conventional note, it is never good to put underscores in a class name. Always name classes in camel case like MyAppDelegate, not my_app_delegate.
You need to #include the .h header files in all classes in which you are using them.
I have just been learning iPhone apps development but I have a hard time in understanding what delegate actually means? Can anyone tell me with example what it does and how important it is? Thanks for any helps!
It's a key concept to understand conceptually so getting your head around how to think about it ahead of the technical details is important. Simply put, a delegate is a callback.
Two main scenarios to use delegates:
A class or control wants to abstract out the details on how to do work (like retrieve data).
Allow others to hook code into a pipeline.
Examples:
UITableView - a table view is just a control that knows how to render a list of cells. It handles all the heavy lifting of rendering, scrolling, etc... But, it has no idea how to load your data. So you implement a datasource delegate which has methods to get the cell data for a given row etc... That makes it easy on you. You just use the control and plug in the specifics for your data. The UITableView will do everything for you ... just answer a few specific questions for. A delegate answers those few specific questions.
A text control - you add a text control to your view and voila! you can type in it and alls good. But what if you want to do something when they start typing or when they're done typing? Well, the text control offers a delegate with methods that allow you to hook into the execution pipeline of the text control. It allows the text control to do everything for you and allows you to interject code where you need it. Many times, there's way to interject code to make a decision on whether something is allowed. The control will call back and ask, should I be able to do x? You can interject code and influence the behavior.
If you're creating a control or class, you can create your own protocol, datasource delegates etc... so your control can focus on doing what's advertised. For example, let's say you wanted to create a task control. You could:
First, create a contract. Hey, if you're going to provide data for my control, these are the questions I'm going to ask you. I'll take it from there... In this case, I'm going to ask you the number of tasks and I'm going to have you give me a task given the row number.
#protocol XXTaskBoardDelegate <NSObject>
-(NSInteger*)getTaskCount;
-(XXTask*)getTaskForRow:(NSInteger*)rowNumber;
#end
In the control or class, give the consumer a way to give us the delegate datasource class that will answer the questions the control will ask. At this point, the control is a pure control. It knows nothing about how you get your data. It's asking for an object (id) that implements a contract/protocol. id
#implementation XXTaskBoard
- (void)setDelegate:(id<XXTaskBoardDelegate>)newDelegate
{
// the control stores the delegate so it can callback and ask you questions.
}
Then, for the delegate class, in the header declare you implement that formal protocol
and in the implementation m file you provide the code.
#interface AppController : NSObject<XXTaskBoardDelegate>
{
//...
}
then, implement it in the implementation
#implementation AppController
- (NSInteger*)getTaskCount
{
return [model queryTaskCount];
}
- (XXTask*)getTaskForRow:(NSInteger*)rowNumber
{
return [[model tasks] getItem:(NSInteger*)rowNumber];
}
A delegate is an object that another class can pass messages to. In practice delegate classes have to conform to a delegate protocol.
For instance we will take a subclass of a table view controller. This is a delegate for your table view. First you define that it is a table view delegate by doing this:
MyTableViewController : UITableViewController <UITableViewDelegate>
This says that class MyTableViewController is a subclass of UITableViewController and CONFORMS to the UITableViewDelegate protocol.
Setting [tableView setDelegate:self] (or defining it as such in IB) then passes the self object to the tableview in order for the tableview to send messages to it.
The main message it sends is the didSelectRowAtIndexPath message which tells your class that the user has pressed a table view cell.
So the object that takes the click event (the table view) passes on the message that the cell has been clicked to the delegate object (which in this case is your MyTableViewController object).
Delegate protocols exist so that you can make sure that the delegate object has the necessary methods to deal with your messages. Methods in a delegate protocol can be #optional or enforced. Any methods that are optional don't have to be defined. In your MyTableViewController class the method didSelectRowAtIndexPath is optional - you don't have to have it. If the table view doesn't find the method it just won't call it.
However the cellForRowAtIndexPath is necessary and without it your app won't compile.
I hope this helps and is straightforwards for you. If you need any more info let me know.
Delegates are just way of getting callbacks from something. You pass a delegate (a pointer to an object that conforms to a protocol) to something and when it has new data for you or when an event occurs that something make a method call on the delegate.
For example, when events occur, like your app is put into the background or the app is about to terminate the UIApplication object will call your application delegate to let it know. When a CLLocationManager has a new GPS position is will call your delegate to pass it the new position. UITableViews call their delegates to get UITableViewCells to display in the table. There are many uses of delegates in iOS.
i am new to iphone development and i am going through tutorial and some sample.
i want to know what is the difference between NSObject and UIViewController class and how we will come to know which class we should use.
some are written in NSObject and some are in UIViewController.
From Wikipedia, a basic overview of object-oriented programming:
Object-oriented programming (OOP) is a
programming paradigm using "objects" –
data structures consisting of data
fields and methods together with their
interactions – to design applications
and computer programs. [...] An object-oriented program will usually contain different types of objects, each type corresponding to a particular kind of complex data to be managed or perhaps to a real-world object or concept such as a bank account, a hockey player, or a bulldozer.
In Objective-C, all Objects are based upon NSObject. Just take this at face value for now. If you want to use an Object, it's going to be based on NSObject. So, unless you're using an int or a float, you're likely using something that's based on NSObject.
NSObject in-and-of-itself, doesn't really supply any functionality. It's your 'starting place' or 'blank slate' for an Object.
You might build an Object definition which is used to represent an Animal, like this:
#interface Animal : NSObject { }
#property (assign) int age;
- (Animal*)mateWith:(Animal*)lover;
#end
In this example we've described a basic Animal. This class basically does two things; knows the age of the Animal, and can mate with another animal to produce an Animal offspring.
You'll notice in that example that we based our Object definition on NSObject.
Now, say we want to create a definition for a Human; well, a Human is, and always will be, a subset of all Animals. So, we can re-use all of the logic in the Animal class definition to create a Human definition - and we might do so like this:
#interface Human : Animal { }
- (void)lie;
#end
In this example, we've created a new definition for a type of Object called "Human". We only defined one thing: a method which gives our class the ability to lie - except we'll also get the ability to mate because we're based on "Animal", and "Animal" already describes how to mate.
Getting to your question:
UIViewController contains a BUNCH of logic for doing some very complex tasks. Most of that logic is part of the Cocoa Touch framework.
If you're making an "Animal" class, you don't need to know how to respond to user input from the screen, you don't need to know how to manage a UIView, you don't need to keep track of parentViewControllers, etc. So, basing our Animal class on UIViewController would be silly. This is when NOT to use UIViewController.
Now, if you've making a user interface screen on the iPhone, and you want to perform some routine when the user clicks on a button - then you DO need all of the UIViewController stuff, so you'd subclass that.
I can understand why, if you're not coming from an Object Oriented Programming background, you might be confused about this. It seems like most of the things you'd need to create ARE UIViewController subclasses. However, as you explore the world of OOP, you'll discover that not only are Objects something someone else wrote that you can use - but they are things you'll want to create from the ground up to accomplish things you used to do procedurally.
Best of luck on your exciting journey.
I'd highly recommend you take a trip to your local Barnes and Noble or head over to Amazon.com and pick up some books on the topic - if you have a friend who already knows OOP a good mentor is much faster than learning yourself.
Don't forget, on the iPhone, you'll have to deal with memory management as well. This is a sticking point for a lot of people - and causes a lot of headaches if you don't follow the rules. Learn them early and you'll be served well.
Hope that helped,
Cheers.
Sources:
http://en.wikipedia.org/wiki/Object-oriented_programming
UIViewController is a subclass of UIResponder which is itself a subclass of NSObject which is a root class (i.e. not a subclass of anything).
This means that any method for NSObject may be called on UIViewController, but not conversely. If you look at the UIViewController Class Reference, it has all of the properties and methods available to you if you use this class. In addition, you automatically get all of the methods for an NSObject (listed in the NSObject Class Reference).
I use a UIViewController for every view that I maintain. I almost never use an object directly as an NSObject, though I often subclass NSObject and I never subclass UIViewController. But this is just me.
I recommend you take a look at Apple's View Controller Programming Guide to see what benefits using a UIViewController offers.
NSObject means it inherits the ObjectProperties only.It doesn't have view.But UIViewcontroller is having the view itself.It can control the views also.
When you don't want a view then you can use the NSObject.If you need viewcontroller or view then you can use the UIViewController.
NSObject is the super class in obj_c and UIViewcontroller is sub class to NSObject.UIViewcontroller inherits properties from UIResponder and this class inherits from NSObject class...
Here is my dilemma. I would like to have a text box and a button. The user types in text and then presses the button. Once the button is pressed, a text message window (using MFMessageComposeViewController) comes up. I don't know how to set this up. The problem is that the TextBox will require a delegate (UITextFieldDelegate) and the MFMessageComposeViewController will require an MFMessageComposeViewControllerDelegate. How can I have a .h file that declares a view that is more than one delegate?
I'm new to iPhone programming so any help on how to have an interface view that handles more than one delegate (so that I can have multiple types of controls in my view) would be really helpful!
A delegate does not need to be a view. Indeed, in most cases it probably shouldn't be. Often you will make a controller object the delegate, although this depends a lot on what you're doing.
The delegate protocols you need (MFMessageComposeViewControllerDelegate and UITextFieldDelegate) are quite distinct, so a single object can readily implement the methods of both without any confusion. But even if you are the same delegate type for several objects, the methods will be passed a pointer to the calling object so you can decide what to do case-by-case if necessary.
If you just mean how do you declare your class as implementing both protocols, you would do this:
#interface MyDelegate : NSObject <MFMessageComposeViewControllerDelegate, UITextFieldDelegate>
{
...
}
...although this presupposes that the protocols are formally required, which I don't think is the case here. In which case such a protocol list is unnecessary.
Otherwise, I probably am not understanding your question...
EDIT: OK, it seems like what you're looking for is how to link up the delegates at runtime. This varies according to the particular class, but for MFMessageComposeViewController you do this:
MFMessageComposeViewController* composer = ...;
id<MFMessageComposeViewControllerDelegate>* delegate = ...;
composer.messageComposeDelegate = delegate;
Easy, no? In this case the protocol is required, so you'd have to include it in the interface as described previously.
In general, if an object uses a delegate for anything, it will have a property or a method to allow you to set it, which you'll find in the documentation. Eg, in this case: Properties for MFMessageComposeViewController.
Note that delegate properties are conventionally weak references, so the objects in question need to be retained somewhere in your application.