The AppDelegate.h file contains the following at the top of the line:
#interface AppDelegate : UIResponder <UIApplicationDelegate>
The current class is AppDelegate which is a subclass of UIResponder. What is the relationship of UIApplicationDelegate with the current class?
It declares that the class conforms to the UIApplicationDelegate protocol.
An Objective-C protocol is similar to a Java interface: it can declare method signatures but it can't provide method implementations.
The compiler will warn you if your #implementation is missing any of the #required methods of the protocol. Xcode will autocomplete any of the methods (#required or #optional) of the protocol.
You can declare conformance to multiple protocols by separating them with commas. Example:
#interface ViewController : UIViewController <UITableViewDataSource, UITableViewDelegate>
Read Cocoa Core Competencies: Protocol and Programming with Objective-C: Working with Protocols.
This mean that your class implement UIApplicationDelegate protocol. Here you have something about protocols : https://developer.apple.com/library/ios/documentation/general/conceptual/devpedia-cocoacore/Protocol.html
You must implement a required methods from implemented protocol into your class, if you want to have class fully accordance with the protocol.
Related
I am very new to Swift and so I may phrase things weirdly here. Apologies!
I've got the following (simplified) protocol in Objective C:
#protocol OtherProtocol <NSObject>
#optional
...
#end
I would like to create a class in Swift (4.2) that adheres to this protocol, so I defined my class like:
class MyClass : OtherProtocol {
}
Naturally, XCode will complain because my class doesn't have the correct methods.
It looks like I need to implement a bunch of NSObject methods in addition to those defined in OtherProtocol. When XCode adds in the missing method stubs from NSObject, there's one in particular giving issues:
func `self`() -> Self {
...
}
The problem with this method is Method cannot be an implementation of an #objc requirement because its result type cannot be represented in Objective-C.
I'd like the quickest way out of this, as I won't end up using any of those standard NSObject functions anyways. Any thoughts?
Actually, there is no need to implement NSObject's methods.
To be able to subclass/inherit from Objective-C classes/protocols you just need to inherit from NSObject. This is to make sure that your Swift class can be used in Objective-C environment as well. Also, Swift structs can't adopt Objective-C protocols, as there is no such type in Obj-C
This should work
class MyClass: NSObject, OtherProtocol {
}
Im trying to implement Pushwoosh into my game its very simple guide but I'm running into this issue here:
Your AppDelegate implementation should look like this:
#implementation AppDelegate <PushNotificationDelegate>
in line 20.
This means that your AppDelegate conforms to PushNotificationDelegate protocol.
Read up on protocols. Basically, a protocol is a list of methods and/or properties that an object must (or may, in the case of #optional properties) have. You read NSObject<PushNotificationDelegate> in that error message as "any NSObject subclass that declares that it implements the methods in the PushNotificationDelegate protocol".
To declare your class conforms to a protocol, you write the name of the protocol(s) in between < and > at the end of one of its #interface or #implementation lines.
The compiler reads each source file separately, and all the headers you #import from that source file (read up on "compilation units" if you want to learn more). So if you write the <PushNotificationDelegate> bit in the .m file, only code in the .m file knows about it, because other .m files only see what you wrote in the header.
In your case, the AppDelegate.m source file should see that, but maybe you have another source file in which you set the same type of delegate that only includes the header for AppDelegate and thus can't see it?
Anyway, if you read this error message with this knowledge, you'll see that PushNotificationManager.delegate is declared as NSObject<PushNotificationDelegate>, and that's what your AppDelegate has to be to be able to assign it to that property. And the error correctly says that an AppDelegate may be an NSObject, but not a PushNotificationDelegate.
The advantage of declaring that your class conforms to a protocol is that the compiler will print an error message if you forget to implement a required method.
For my case, I need to conform the protocol in the header file to silent the warning. I don't know what I'm doing.
#import <UIKit/UIKit.h>
#import "BaseAppDelegate.h"
#import <Pushwoosh/PushNotificationManager.h>
#interface ChildAppDelegate : BaseAppDelegate <UIApplicationDelegate, PushNotificationDelegate>
#end
I have something like this:
#protocol MyProtocol <NSObject>
- (void)oneMethod;
#end
.
#interface BaseClassWithProtocol : NSObject <MyProtocol>
#end
.
#interface ChildClassWithProtocol : BaseClassWithProtocol
#end
BaseClassWithProtocol has implemented oneMethod, and I want to show warning if ChildClassWithProtocol doesn't call super in its oneMethod implementation.
But I don't know where should I write __attribute__((objc_requires_super)).
Writing it in protocol is not supported while redefining oneMethod in .h looks stupid.
So is there any standard way which can deal with the problem?
The requirement to call super is imposed by BaseClassWithProtocol. It's not part of the protocol. Surely, some class could implement MyProtocol however it wants without that requirement being imposed. That's the nature of protocols. They impose interface, not implementation.
So, redeclaring the method in BaseClassWithProtocol with the attribute seems perfectly sensible to me. Not sure why it "looks stupid".
Protocols aren't meant to give warnings for your diverse implementations. They only warn you whether you agree to include the required methods in your implementation or not. But how you implement the methods, that's up-to your Base class that adopts the protocol. That is, you should have your necessary functionalities in your .h or .m files.
Consider this way:
You have a method in your protocol where you want to have a warning for the super calls. Now you adopt the protocol in a class which is the sub-class of NSObject. But the NSObject class doesn't conform to the protocol you are defining. Would you now supposed to get the warning for your class? According to your requirements, you should get that warning. But this isn't the case. You would practically never get that warning by this procedure.
Any object which assign to Custom protocol reference, is always be Confirm by NSObject Protocol directly or By superclasses. So Why should I do this?
I really don't know, whether I got you right.
If you meant that a custom protocol always confirms to the NSObject protocol, there is a pretty simply reason for it. It is a little bit weird:
If you type a reference to id the compiler accepts every message to that he has seen while compiling the translation unit ("class", "module", the file you compile).
If you type an object reference to id<protocol>, the compiler only accepts messages that are declared inside the protocol. But this is never enough!
#protocol MyProtocol
#optional
- (void)doItOrNot;
#end
The only message you can send is -doItOrNot. So the compilation of such code will fail:
id<MyProtocol> ref = …;
if ([ref respondsToSelector:#selector(doItOrNot)]) // <- Error -respondsToSelector is not declared in the protocol.
…
By adding the NSObject protocol to your protocol you import some fundamental declarations. (Including MM for MRC.)
It sounds like you might be trying to ask about using the NSObject protocol, since every class has NSObject as an ancestor.
The answer, then, is that it's not true that every object is derived from NSObject. Most are, but NSProxy is an example of one that's not. The methods in the NSObject protocol are what any instance of the NSObject class is expected to implement, so by implementing the NSObject protocol, NSProxy is able to provide the same behaviors that any class derived from NSObject (class) has.
For example, you can use methods like -isEqual and -hash with instances of NSProxy.
If you're creating a subclass of the NSObject class, there's no need to declare that your class implements the NSObject protocol because the NSObject class already does that for you.
Also, just as you can declare that a class adopts a protocol with:
#interface MyClass <SomeProtocol>
you can also declare that a protocol adopts another protocol:
#interface MyProtocol <SomeProtocol>
Since, as explained above, not every class is a subclass of NSObject (the class), having MyProtocol adopt NSObject (the protocol) guarantees that you can call NSObject methods. If you want to specify that a method takes any kind of object that adopts YourProtocol, you can do that by specifying the type as id<YourProtocol>. However, if YourProtocol isn't declared to adopt the NSObject protocol, you can't be certain that it's safe to call NSObject methods like -isEqual, and you can't even check that it's safe using -respondsToSelector: or -isKindOfClass: because those methods themselves are part of the NSObject protocol.
Cocoa defines an NSObject protocol that mirrors the NSObject class and instance methods. By declaring that your custom protocol implements the NSObject protocol, you give the compiler a hint that all of the NSObject methods will be implemented by an instance that implements your custom protocol.
If you don't include the NSObject protocol, you'll get warnings when you try to call any of the NSObject methods for instance respondsToSelector: on the object.
You don't have to. But the problem is that a lot of the core functionality of NSObject — indeed, all the core functionality necessary for NSObject to function as a base class — is declared in the NSObject protocol. (This strange architecture is so that both NSObject and NSProxy can be base classes: they both adopt the NSObject protocol.)
Now, if you declare an object's type as id<MyDelegate>, the only messages you can send that object are MyDelegate messages. That's fine, usually; but what if you want to send it, say, the respondsToSelector: message? That method is declared in the NSObject protocol, not in the MyDelegate protocol. So the compiler will stop you.
There are two solutions. Either declare the object's type as NSObject<MyDelegate>, or make MyDelegate adopt the NSObject protocol. Either way, the compiler is now satisfied, and you can send this object the respondsToSelector: message.
I am actually a newby at xcode. I can make out a few things be myself but have questions about what some things do and why they are put there. I have tried to read many e-books, watched tutorials, but they never go into the basics, alway just say "Add this, Click here etc"
Could someone give me some answers to a few questions please.
Ok, I know an ios app is mostly made out of Views, views are controlled by controllers. Each controller has a header (.h) file and a module?class? file (.m). The .h file contains the declarations of variables and functions used in the .m file.
The whole app is controlled by a master "controller" called the "delegate".
Definitions in .h file may be for example an action IBAction or IBLabel or something.
What raises questions for me is for example these lines:
#class FlipsideViewController;
#protocol FlipsideViewControllerDelegate
- (void)flipsideViewControllerDidFinish:(FlipsideViewController *)controller;
#end
#interface FlipsideViewController : UIViewController
#property (nonatomic, assign) id <FlipsideViewControllerDelegate> delegate;
- (IBAction)done:(id)sender;
and why are sometimes in another view controller the delegate class loaded
#class MainViewController;
what does the following do, meaning what is the #interface declaration?
#interface flipAppDelegate : NSObject <UIApplicationDelegate>
what is
nonatomic, retain
sorry for asking really stupid questions, but every tutorial just skips these things.
I can follow a youtube video or a manual, but it doesn't teach me a lot...
Let me try to answer your questions, one at a time.
what is the #interface declaration?
The interface declares a class. By declaring a class, I mean it specifies the instance variables and private/public methods that it contains. Again, the header file only contains the declaration of the methods, and the implementation/body of the methods lies in the module class. So, here-
#interface FlipsideViewController : UIViewController
The class FlipsideViewController derives from/subclasses/extends UIViewController. i.e Is a type of UIViewController but adds its own features.
Similarly
#interface flipAppDelegate : NSObject <UIApplicationDelegate>
Subclasses NSObject and implements the UIApplicationDelegate protocol. A protocol is essentially a set of methods that a class promises to implement (although there can be optional methods).
why are sometimes in another view controller the delegate class loaded
The delegate pattern allows a class to delegate its work to another class that implements the delegate protocol. So, here, FlipsideViewController keeps an instance of the delegate object, so that its flipsideViewControllerDidFinish: can be called.
what is nonatomic, retain
It means that when you set a value to your instance variable, the value's refcount will be incremented and set to your variable. Also, it will not happen as an atomic operation. You need atomic only in a multi-threaded environment.
#synthesize is simply a shortcut to generate getters and setters for your variables.
You really need to read the Objective-C Programming Language from Apple. It's pretty brief, and runs down the basics of the architecture, concepts, and syntax.
To address, briefly, some specifics:
The #class directive is used to declare the name of a class without importing it's header file. It is often used in a .h file declaring a protocol, because a protocol has no implementation, it doesn't need to import the interfaces of other classes (their .h files).
A protocol is a way of declaring what methods and properties a class should have in order to "implement" the protocol.
#interface is used in an interface file (.h) to declare a class, meaning to describe the methods and properties it will have, the protocols it will implement, and the superclasses from which it will inherit. In your example, the class will be called flipAppDelegate, which inherits all of the methods and properties of the NSObject class, and which implements the UIApplicationDelegate protocol.
In your class (.m) file, you will define (with all your code) all of the methods and properties that you declared in your interface file. You include the methods and properties you declared yourself, and from the protocols you implement.
#synthesize is used in a class implementation file (.m) to "synthesize" --- that is, automatically create the code for --- all the properties you declared in your interface (.h) file. Since properties normally just need basic accessors (a "getter" that just returns the current value, and a "setter" that just sets the current value), using #synthesize is a shortcut to let the compiler create the variable to store the value, the getter method, and the setter method for you automatically.
Xcode = An IDE (Integrated Development Environment)
Objective-C = A Language
Cocoa Touch, Media FrameWork, Core FrameWork = Frameworks used in developing for iOS
I'd highly recommend starting by learning Objective-C. At least with a primer first:
https://developer.apple.com/library/ios/#referencelibrary/GettingStarted/Learning_Objective-C_A_Primer/_index.html
There's a wealth of tutorials and videos available from Apple for developers you might want to start on the developer portal.