I have this Custom subclass of UIViewController where I've built an UICollectionView.
I am conforming to a CollectionViewDelegates and CollectionViewDataSource in that UIViewController.
Then Xcode asks me to put all the stubs that are needed. There is a lot of stubs. When I worked with Swift, I've added few stubs that I needed like numbersOfItemsInSection or didSelectRowAt. Now I've got over 10. To be completely honest, at this stage I would not even know what is the functionality of most of them. I will figure that out, but my main question is, do I need to use all of them? Or can I just delete them and forget about them right now? Some of them are:
didUpdateFocusInContext
viewWillTransitionToSize
systemLayoutFittingSizeDidChangeForChildContentContainer
etc.
Right click the delegate name in the .h file and jump to the definition. You require all methods not explicitly marked as #optional
I didn't check it for your example but here is a generic one
#protocol MyProtocol
- (void)requiredMethod;
#optional
- (void)anOptionalMethod;
- (void)anotherOptionalMethod;
#required
- (void)anotherRequiredMethod;
#end
Related
Xcode has a new "fix-it" feature for automatically implementing protocol methods. Here is an example:
MFMessageComposeViewControllerDelegate has only a single method. However, when I click "fix" button, Xcode creates MANY irrelevant method stubs:
I haven't added any new other protocols, it's just as follows:
#interface TUDiscoverInviteViewController ()<CNContactPickerDelegate, MFMessageComposeViewControllerDelegate>
#end
My view controller only derives from UITableViewController. Where are those method stubs coming from and how can I prevent this behavior?
I'm on Xcode 9.2.
UITableViewController conforms to UITableViewDataSource and UITableViewDelegate, so you get those method stubs too.
I don't see a way to get Xcode to only generate stubs for one protocol, except by temporarily removing the other protocols and changing your base class.
If you use AppCode, then you can use AppCode's Code > Generate > Implement Methods interface to select which members you want stubs for:
I have two classes. Both these classes are delegates of each other. This gives me error like "Can not find protocol declaration". After searching on net, I came to the conclusion that, this is the case of cyclic dependency.
To break this dependency the solution they have suggested is to define protocol in another header file. I could not find any tutorial on how to do this and how will it affect my code?
I have a example for you..
#class ClassA;
#class ClassAController;
#protocol CreateClassADelegate
-(void)CreateClassA:(ClassAController *)sender didCreateClassA:(ClassA *)ClassAObj;
-(void)CreateClassACancel:(TSInputController *)sender;
#end
Check #Toro's answer in this previous SO question
UIViewController calling each other's delegate
In case you are using XCode 4 you just creating new file as always, the difference is that you need to choose Objective-C protocol in Cocoa Touch section rather then Objective-C class or UIViewController subclass.
Other approach you may use is to create new Objective-C class and then just delete the .m file manualy and change #interface to #protocol in .h file.
For every object that can have a delegate, there is a corresponding protocol, that declares the messages that the object can send it's delegates. The delegate implements methods from the protocol for events it is interested in.
How can one view the protocol in order to find out what functionality needs to be implemented?
Protocols in Objective-C are non-essential, but they are useful; Protocols are usually declared in header (.h) files:
#protocol MyAwesomeProtocol
-(void)thisMethodIsRequired;
#optional
-(void)theseMethodsAreOptional;
#end
... and are usually used in a couple of places:
1: In an instance variable declaration:
#class Foo : Bar
{
id<MyAwesomeProtocol> someIvar;
}
#end
2: In property declarations:
#class Foo : Bar
{ }
#property (assign) id<MyAwesomeProtocol> someProperty;
#end
3: In code (Try to avoid this, but it's legal):
if(...)
{
[(id<MyAwesomeProtocol>)obj foo];
}
If you're using Xcode, you can always command-click a protocol that appears anywhere in your code to jump to the header where that protocol is defined. This is true even of Apple's protocols, since header files are not compiled. Also, the documentation available through Xcode provides additional insight on what methods are required or optional.
Since you can define optional protocol methods, you should always check to see if your delegate -respondsToSelector:#selector(isThisMethodImplemented:), since the language doesn't do this for you.
Also, if you're using Xcode, you can option-click a class in your code to bring up the quick documentation panel, which has an option to go to the full documentation for the class of the object you clicked on.
You can either look at the documentation or view the corresponding header file by Command-clicking the protocol in Xcode (Command-doubleclick in Xcode 3).
Check out the doc the delegate property, it is almost all the time defined is id type and which protocol it is conforming to : id <TheProtocolYouLookFor>.
If not, read down the description and you will find more information about the protocol. Protocol names are also links in general.
I've been working on a pet project for a few weeks now, and starting to think that it may get used by myself and a few friends. At present, it's really just a pile of Objective-C classes in an XCode project with a main() I've been using to test various features. Going forward it seems easiest to use this library in projects if I package it up as .dylib file. As I've found with other languages, doing this as an afterthought is a nuisance that ideally is farmed out to the lowest rung. :)
I'm very new to the Objective-C/Xcode world, but according to Apple's "Dynamic Library Programming Topics", I'm under the impression that it's really just a matter of rejigging my interface files to be of the format:
#protocol Person
- (void)setName:(NSString*)name;
- (NSString*)name;
#end
#interface Person : NSObject <Person> {
#private
NSString* _person_name;
}
#end
(taken from referenced Apple doc).
Where: I'm defining a protocol that contains the methods I wish to include for the classes to be contained in the .dylib, and then defining an interface that subclasses NSObject implementing the aforementioned protocol and declaring ivars in here.
A few questions:
Am I able to omit methods from the protocol that I don't wish to "EXPORT" to the dylib?
If I have subclasses of a class within the dylib, do I create another protocol for the subclass, and make the superclass of the newly created class implement that protocol? For instance, if I were subclassing person:
#protocol CatPerson
/* any additional methods for CatPerson not in Person */
- (void) protractClaws;
- (void) retractClaws;
#end
#interface CatPerson : Person <CatPerson> {
#private
/* any additional ivars for CatPerson not in Person */
NSNumber *clawCount;
}
It's likely a very trivial question, but I'm trying to figure out everything I'll need to do before I go thru the gnashing of teeth of moving all the classes to a .dylib.
Project->New Target… select "dylib" in the panel that you get. Make it the current target. control-click on the groups & files tableview header, check "target membership". Check the boxes next to the files you want included in your dylib.
When you have an UIViewController and UITableViewController classes and you wanted to let these two do some common stuff in their - (void)viewDidLoad how could you achieve this in Objective-C without actually duplicating your code?
I tried to create MyUIViewController inheriting UIViewController and implement viewDidLoad in there. This perfectly works with UIViewController classes obviously, but won't work in UITableViewController, since I can't simply replace #interface MyTableViewController : UITableViewController with #interface MyTableViewController : MyUIViewController.
I believe this topic is about "multiple inheritance" in Objective-C language, but other than figuring out what's different in Objective-C, I'd really like to know how to do guys do such thing?
This thread has some good information. One of your main options is to make a class with that shared functionality and hold it as an instance variable, then forward messages to it in forwardInvocation.