I'm trying to write a protocol to do UnitTest by making a double for GIDSignIn in GoogleSignIn framework.
GIDSignIn is written in Objective-C and I'd like to extract delegate and presentingViewController from GIDSignIn
#property(nonatomic, weak) id<GIDSignInDelegate> delegate;
#property(nonatomic, weak) UIViewController *presentingViewController;
However, when I wrote the protocol below, I got warnings saying about different optionality. I would like to know how I can write my protocol silencing these warnings.
Related
I am using XCTestKit for unit testing in my app using Objective-C.
I need to test the default values of textfields on my screen but the IBOutlets are declared under .m file.
Is there any way to access those variables, or any other approach to test the values in UnitTest classes.
Let's say your .m file has something like
#interface MyClass ()
#property (nonatomic, strong) IBOutlet UILabel *myLabel;
#end
One approach is to expose this in your test file like this by copying and pasting to your test file, but giving the category a name:
#interface MyClass (Testing)
#property (nonatomic, strong) IBOutlet UILabel *myLabel;
#end
The advantage of this approach is it keeps the outlet hidden from your -public interface.
The disadvantage is that the duplication means if you change anything about the property declaration, you have to remember to repeat it in your test file.
Another approach is to move your outlet from your .m to your .h.
The advantage of this approach is that it acknowledges that testing is a valid client of your API, and avoids duplication.
The disadvantage of this approach is that you will have more in your API than you want all clients to know.
I prefer the second approach. What I do then is soften the disadvantage by not treating the class interface as the "interface for everybody". Instead, I split things off into protocols, exposing only what particular clients need for their interactions alone.
I'm extending the NameAndPassword example (https://github.com/skycocker/NameAndPassword) and I need to acces IOBluetooth methods in this implementation file: https://github.com/skycocker/NameAndPassword/blob/master/NameAndPasswordPlugin.m
The interface looks like this:
#interface EXNameAndPassword : SFAuthorizationPluginView
How do I make it inherit from CBCentralManagerDelegate like in appdelegate:
#interface AppDelegate : NSObject <CBCentralManagerDelegate, CBPeripheralDelegate>
I need EXNameAndPassword to inherit both from SFAuthorizationPluginView and CBCentralManagerDelegate and stuff. I believe this is quite easy, I'm just an obj-c beginner. I read about composition but I can't get it to work.
What I have currently is
#interface EXNameAndPassword : SFAuthorizationPluginView <CBCentralManagerDelegate, CBPeripheralDelegate>
but I keep getting warnings about properties non synthesized -- I didn't have to synthesize them in my project which didn't require SFAuthorizationPluginView inheritance, therefore I guess I'm doing something wrong.
the "properties non synthesised" warning is related to properties defined in a protocol.
In a class #properties are automatically #synthesized in the implementation, but in a protocol, it is the conforming class's responsibility to synthesize, so add:
#synthesize protocolPropertyName = _protocolPropertyName;
in EXNameAndPassword.m
I got the problem.
#interface EXNameAndPassword : SFAuthorizationPluginView <CBCentralManagerDelegate, CBPeripheralDelegate>
is perfectly fine, I just had to disable architectures other than x86_64 in build settings.
Source: http://www.cocoabuilder.com/archive/cocoa/198573-property-problem.html
I have two protocols declared in my project. The first one I wrote is named SSSelectingCategory.h
#import <Foundation/Foundation.h>
#protocol SSSelectingCategory <NSObject>
#required
#property (nonatomic, strong) SSCategory *selectedCategory;
#end
The second one is SSSelectingIcon.h
#import <Foundation/Foundation.h>
#protocol SSSelectingIcon <NSObject>
#required
#property (nonatomic, strong) SSIcon *selectedIcon;
#end
The strange thing is that the first protocol compiles without any error or warning, while the second one is throwing the Unknown type name 'SSIcon'.
I know the answer to this problem is to use a forward-class declaration in my second protocol like this:
#import <Foundation/Foundation.h>
#class SSIcon;
#protocol SSSelectingIcon <NSObject>
#required
#property (nonatomic, strong) SSIcon *selectedIcon;
#end
But now this makes me think the SSSelectingCategory.h protocol shouldn't have compiled at all in the first place, as I didn't put any explicit #import or forward-class declaration of any sort.
I could quiet the compiler and go on coding, but I want to understand if there's something weird going on with Xcode or if I'm missing some fine point, as both protocols are really simple. Could there be a problem with the SSCategory and/or SSIcon classes, as they're both NSManagedObjects and there's a relationship connecting the two?
The compiler compiles the .m files, which in turn include the .h files.
So I assume that in the .m file where "SSSelectingCategory.h" is included, SSCategory is defined before, so that the compiler has no problem compiling the protocol.
If, on the other hand, "SSSelectingIcon.h" is included without having defined SSIcon before, the compiler would abort with an error there.
In any case, it makes sense to include the required interfaces in the .h file (or forward declare the required classes), because that enables code-completion in Xcode.
My xcode version is 4.2.
When I use property to generate getter/setter methods.
Here is the code:
#interface NewSolutionViewController : UIViewController
#property(nonatomic, weak) NSString a;
There is no issue exist. However when I turn into basic data type
#interface NewSolutionViewController : UIViewController
#property(nonatomic, weak) int a;
My program crashed. Do you guys know the reason?
A basic data type is not an object, and hence does not need to be declared weak.
Use
#property (nonatomic, assign) int a;
to directly assign to the variable.
The problem is that an int is not an NSObject.
Elaborating a bit...
NSObject is the root class of most Objective-C class hierarchies. Read up on Apple's Objects, Classes, and Messaging tutorial.
int is a basic machine type. It doesn't have methods, like an object, so it doesn't respond to messages.
int doesn't respond to retain - you probably want to put an assign in the property declaration for that one.
This question already has answers here:
Compiler gives warning on performSelectorOnMainThread:#selector(delegateMethod)
(4 answers)
Closed 10 years ago.
Xcode 4 is giving me compiler warnings on the performSelectorOnMainThread:withObject:waitUntilDone: message sent to my delegate and I don't get it.
My delegate is declared like:
#property (nonatomic, assign) id <AccountFeedbackDelegate> delegate;
And then eventually executed on the main thread:
[self.delegate performSelectorOnMainThread:#selector(didChangeCloudStatus) withObject:nil waitUntilDone:NO];
Yet Xcode persists on giving me:
warning: Semantic Issue: Method '-performSelectorOnMainThread:withObject:waitUntilDone:' not found (return type defaults to 'id')
Of course the code compiles and runs fine, but I don't like the warning. When I redeclare the delegate like this, the warning vanishes, but I don't like the workaround:
#property (nonatomic, assign) NSObject <AccountFeedbackDelegate> *delegate;
What am I missing? What did I do wrong?
Cheers,
EP
performSelectorOnMainThread:withObject:waitUntilDone: is declared in a category on NSObject in NSThread.h. Since your variable is of type id, the compiler cannot be certain that it can respond to a message defined for NSObject. And unlike with plain id variables, the compiler warns you about this when your variable is declared id <SomeProtocol>.
So you should indeed declare your delegate as NSObject <AccountFeedbackDelegate>.
PS: The "standard" way to get rid of this kind of warning by declaring the protocol as #protocol AccountFeedbackDelegate <NSObject> won't work here because performSelectorOnMainThread:withObject:waitUntilDone: is not declared in the NSObject protocol.