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...
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'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.
Can any one differentiate when do we use Delegation over category and vice versa. I am clear over this.
Thanks
Category allows to add new methods or overwrite existing methods on a class, thus allows to extend a class without subclassing. Adding methods is the most useful aim, overwriting can go really wrong if you do not know exactly what the class being extended does.
It is more a language feature not a pattern, it works on each class.
Delegate is a pattern not a language feature, the class that is supposed to used must be coded for it, otherwise it won't work.
Usually a delegate will be required to implement a protocol known by the class that is going to receive the delegate. The class will then use the delegate to do stuff it was coded for, some of the most common are sending notifications, using a part of a strategy pattern, that is asking question in certain part of code to make decisions based on the concrete delegate's implementation, letting delegate execute an action or any combination of them.
For example UIApplicationDelegate is a notification (application:didFinishLaunchingWithOptions:) and action (application:openURL:sourceApplication:annotation:) protocol, UITextFieldDelegate is notification (textFieldDidBeginEditing:) and strategy (textField:shouldChangeCharactersInRange:replacementString:).
Actually I can imagine using category to implement delegating in all this cases I stated above: sending notifications, doing actions, taking part in a strategy. But it would require you to very very good know what to extended class is doing, probably to have it code, otherwise you can very easily break the class or be broken by changed class implementation. So this usage would be in my opinion highly wrong.
category: Adds methods to an existing class.
delegate: Modifies behavior of another object by allowing some other object, the delegate, to participate in the object's operation.
Say you've got an iOS application with three tables. Even though they're configured the same way, those tables each may behave differently if they have different delegates.
You can't do that with a category because a category applies equally to all instances of the class it extends. On the other hand, if you want to extend the UITableView class to add some new capability, you need a category*. Delegates are instance-specific and limited to the role envisioned for them by the designer of the delegating class.
*or a subclass, of course.
Categories are used when you need to extend the class without creating a subclass, for example when you need to add a method named isURL to the NSString you can make use of categories as follows, here we not creating a subclass, instead we are extending the implementation.
#interface NSString (Utilities)
- (BOOL) isURL;
#end
Delegates are similar to callback functions,
In my app there are numerous view controllers which have their own purposes. However, underneath they do share some need for common maintenance work that could use the same method code instead of each having its own copy of the code, literally pasted in.
Is there a way to share the code of these common methods ? I see two possibilities:
1) either one copy of code truly shared in memory as in a special maintenance object of methods
or
2) written once in a block of code but allocated many times as needed by each view.
Which of these is the correct path or what is the correct path, and HOW would it be implemented in the most simple manner ?
Kindness pls, new coder in the room.
Thanks.
-Ric
Note: This is an old question/answer reflective of Apple practices at the time, and answered for a new coder looking for a simple solution they can understand (as requested in the question). There are better and more testable ways to achieve this, using composition.
The best way to achieve what you want is to create a common parent class for your view controllers. So instead of inheriting directly from UIViewController, each of your custom classes will inherit from SomeFeatureViewController (where SomeFeature describes the common feature provided), this class inherits from UIViewController. Now, each of your actual view controllers will inherit from SomeFeatureViewController and any common methods (also any common instance variables used by these methods) can be placed in this parent class.
#interface SomeFeatureViewController : UIViewController
{
int common_iVars;
}
- (void)commonMethods;
#end
#interface ActualViewController : SomeFeatureViewController
{
int specific_iVars;
}
- (void)specificMethods;
#end
The way I see it you should do a class with all the common methods and then subclass it. Say you have MyCommonViewController : UIViewController and then for each different view controller do MySpecificVIewController : MyCommonViewController
As well stated by jhabbott, a subclass of UIViewController is one good solution.
If that's not an option (e.g. you can't change the class hierarchy), another option is to create a category on UIViewController to add the methods and properties you need. This will make your methods available on every UIViewController, including all the standard subclasses, without any extra work on your part. With this solution you cannot directly add ivars, although you can fake it up well enough using associative references.
Well, what I ended up doing was to create a Singleton object and put all my common methods there. This meant that all my View Controllers could utilize the common methods of the Singleton. Maybe this is a bit too open if the project was being developed by a team of programmers but as it is just me I know that all the controllers have similar requirements in processing. So the Singleton approach seemed to work.
It also fit the project because at the time of the question all the View Controllers had been created and to make them a subclass of a parent class seemed to be a retrofit, though I agree that if part of an initial design, it may be a better approach. I do thank the 3 who gave the time to answer.
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.