I've inherited Objective-C code that I'm moving to ARC. I've a number of .h files that declare a protocol and an interface that reference one another -- here's the basic pattern in the .h file
#class BasicService;
#class BasicServiceObserver;
#protocol BasicServiceObserver
-(void)UPnPEvent:(BasicService*)sender events:(NSDictionary*)events;
#end
#interface BasicService : NSObject <Events_Observer> {
<<var declarations here>>
}
-(NSUInteger)addObserver:(BasicServiceObserver*)obs;
-(NSUInteger)removeObserver:(BasicServiceObserver*)obs;
-(BOOL)isObserver:(BasicServiceObserver*)obs;
#end
and in the .m file, the BasicServiceObserver ref is flagged as a forward reference. The .m file includes the above .h file.
//Events_Observer
-(void)someEvent:(NSDictionary*)events{
BasicServiceObserver *obs = nil;
[mMutex lock];
NSEnumerator *listeners = [mObservers objectEnumerator];
while(obs = [listeners nextObject]){
[obs someEvent:self events:events]; // <-- Receiver type 'BasicServiceObserver' for instance message is a forward declaration
}
[mMutex unlock];
}
Driving me nuts. I've tried to separate the the protocol into its own .h file and import it (and remove the #class declaration). No joy there.
Any ideas on how to resolve this?
thanks!
Since BasicServiceObserver is a protocol, not a class, it should not be forward-declared in this situation at all. Declaring it as a #class misleads the compiler into thinking that there would be an #interface BasicServiceObserver somewhere when there is no such interface.
Here is how you should get this to a state where it compiles:
#class BasicService;
#protocol BasicServiceObserver
-(void)UPnPEvent:(BasicService*)sender events:(NSDictionary*)events;
#end
#interface BasicService : NSObject <Events_Observer> {
<<var declarations here>>
}
-(NSUInteger)addObserver:(id<BasicServiceObserver>)obs;
-(NSUInteger)removeObserver:(id<BasicServiceObserver>)obs;
-(BOOL)isObserver:(id<BasicServiceObserver>)obs;
#end
Similarly, in .m file
//Events_Observer
-(void)someEvent:(NSDictionary*)events{
id<BasicServiceObserver> obs = nil;
[mMutex lock];
NSEnumerator *listeners = [mObservers objectEnumerator];
while(obs = [listeners nextObject]){
[obs someEvent:self events:events]; // <-- Receiver type 'BasicServiceObserver' for instance message is a forward declaration
}
[mMutex unlock];
}
Note: Since you are cleaning up the files anyway, consider moving the variables from the <<var declarations here>> section into a class extension in the .m file. This may help you reduce the number of headers included in the .h file, and to avoid propagating through your headers the unnecessary dependencies of the implementation
As others have pointed out, a class and a protocol are not the same thing.
Sometimes you do want to define both, e.g. the system UITableView class and the UITableViewDelegateProtocol protocol.
If you are going to have both a protocol and a class, I suggest adding the word protocol to the name of the protocol:
#protocol BasicServiceObserverProtocol
-(void)UPnPEvent:(BasicService*)sender events:(NSDictionary*)events;
#end
However, it's probably better to not create a BasicServiceObserver class. Instead, make all pointers to objects to conform to that protocol be
BasicServiceObserverProtocol, as #dasblinkenlight says in his post.
Related
What's the difference between declaring a #private ivar in the header file and declaring the same ivar in the class extension without #private? As far as I understand it's the same thing.
Also, can you declare a private property in the header?
The concept is to declare in the header file only those things (methods, properties, etc) which are public. Declare all private items in the implementation file's class extension.
This provides the class users only information that is available for their use and hides all else. It also make it easier for a user of the class quickly see the functionality available to him. Writing code is all about readability and understandability to the developer.
This way a developer is free to change anything that is not exposed in the header files without making any externally visible changes.
In recent versions of Objective this is finally fully releasable via class extensions.
What's the difference between declaring a #private ivar in the header file and declaring the same ivar in the class extension without #private?
There are a few differences. In short, variables declared in the header file are visible to subclasses and class categories. Variables declared in the implementation are not.
1) Instance variables declared in a class's main #interface block are available to external class categories or extensions, even if those variables are declared #private. E.g.:
// YourClass.h
#interface YourClass : NSObject {
#private
int _yourPrivateIVar;
}
#end
// MyExtension.m
#implementation YourClass(MyExtension)
- (void)reset { _yourPrivateIVar = 0; } // This is allowed.
#end
Instance variables declared in the implementation are not available to external class categories.
2) A base class and its subclass cannot both declare the same ivar in their #interface, even if both ivars are #private. E.g., this is not allowed:
#interface Base : NSObject
{
#private
int _foo;
}
#end
#interface Subclass : Base
{
#private
int _foo; // Error: Duplicate member _foo
}
#end
If both ivars are declared in a class extension or implementation block then not only does it compile but it works as expected: both classes have their own separate _foo ivars that do not conflict with one another. On other words, both variables are truly private and separate:
#implementation Base {
int _foo;
}
#end
#implementation Subclass {
int _foo;
}
- (void)reset { _foo = 123; } // Does not affect base class's _foo
#end
Note: If the base class and subclass declare a "private" property or method with the same name it will compile without warning or error, but it will fail spectacularly at runtime as both classes unknowingly interfere with each other's private data.
I was able to see an interesting case using
Estimote nearables SDK
They have a class ESTNearable with property called zone.
// ENUM
typedef NS_ENUM(NSInteger, ESTNearableZone ) {
ESTNearableZoneUnknown = 0,
ESTNearableZoneImmediate,
ESTNearableZoneNear,
ESTNearableZoneFar,
};
// CLASS
#interface ESTNearable : NSObject <NSCopying, NSCoding>
// ...
#property (nonatomic, assign, readonly) ESTNearableZone zone;
// ...
#end
So when I try to use this method in Swift, compiler fails with that error:
As I understand there is some kind of compiler bug and for some reason it believes that I want to use old zone method from NSObject - (struct _NSZone *)zone OBJC_ARC_UNAVAILABLE; I can use other specific properties of that class without any problems.
As I use an SDK I can not change the name of the zone method. I believe I can write some kind of obj-c category, add some new method there, which will return value of original one, but I do not want to add obj-c classes in my project.
Is there any possibility to call this method from swift as I believe correct zone method will be called for class instances?
Thanks in advance!
Here I found the same question. I answered more deeply there. I could not find something more good, so I went ahead with my old assumptions.
I Added this category to Bridging Header. It worked fine.
#import <EstimoteSDK/EstimoteSDK.h>
#interface ESTNearable (Ex)
/// Solving the compiler problem that "zone" method is unavailable in Swift
#property (readonly) ESTNearableZone nearableZone;
#end
// Implementation
#implementation ESTNearable (Ex)
- (ESTNearableZone)nearableZone
{
return self.zone;
}
#end
After that I just used nearableZone method in Swift
var zone = someNearable.nearableZone
Having an Objective c base class:
#interface ObjcClass : NSObject {
NSString *aVariable_;
}
And a swift sub-class:
class SwiftClass : ObjcClass {
func init() {
// aVariable_ can't be accessed here. An Objective-c derived
// class has direct access to it's super's instance variables!
}
}
How do I access ObjcClass aVariable_ from within SwiftClass?
Great query. We have tried to hard to get this done. The only working solution I found
get value by using self.valueForKey("aVariable_")
set value using self.setValue("New Value", forKey: "aVariable_")
Hope that helps. Possible solution without altering super class.
I couldn't find a "proper" way to do this, but I needed badly for it to work. My solution was to create a simple getter method in my Objective C superclass, like this:
header file
#interface ObjcClass : NSObject {
NSString *myVariable;
}
- (NSString *)myVariable;
in the implementation file
- (NSString *)myVariable {
return myVariable;
}
I'd love to hear of a better way of doing it, but this at least works.
I've searched a lot for this.
Eventually I changed my code from:
#interface PrjRec : NSObject {
#public
NSString* name;
}
#end
To:
#interface PrjRec : NSObject {
}
#property NSString* name;
#end
similar to #JasonTyler solution.
Then I can access to my object property from Swift code with simple dot notation <object instance>.name,
But I needed to change all existing objective-c references from
<object instance>->name
To:
<object instance>.name
or
_name
if inside class unit.
I hope for a better solution too.
This worked as a pretty neat solution for me, just adding a Swift variable like:
var myInstanceVar: String {
return self.value(forKey: "myInstanceVar") as! String
}
If you are willing to have a property, then you can create the property to fit your needs.
#interface ObjcClass : NSObject {
NSString *aVariable_;
}
#property (nonatomic) NSString *aVariable_;
...
#implementation ObjcClass
#synthesize aVariable_ = aVariable_;
This allows the variable to be accessed as inst->aVariable_ or as inst.aVariable_. In the Objective C class the variable can be accessed as aVariable_ or self.aVariable_.
I seriously don't know why anyone does instance variables anymore (for one, they're private by default) vs properties. See Giorgio Calzolato's answer on this (apart from his last line about looking for a better solution - that IS the best solution :) ).
In my case I already had a property and was extra perplexed over why it didn't work. But I realized that the property had a custom time and it needed to be added into my SDK-Bridging-Header.h file.
So if your property is set to a custom type like this:
#property (nonatomic, weak) IBOutlet SDKMyCustomObject *customObject;
...then remember to add it to the bridging header.
I would like to know what's the difference between declaring my instance variables like this:
// inside the implementation file (.m)
#interface MyCustomObject()
{
id _myIvar;
}
#end
#implementation MyCustomObject
...
#end
And like this:
// inside the implementation file (.m)
#implementation MyCustomObject{
id _myIvar;
}
...
#end
From the point of view of the USE, there is not difference.
From the point of view of the declaration, the first one is a Category:
#interface MyCustomObject()
{
}
so if you have a variable with the same name in the header file, your implementation file will see this one, but other classes whose import that header file, will see the other one.
This mechanism can be really useful to assign different attributes or properties to the same var, but differencing the exposed var, from the private internal var.
This question already has answers here:
Why is there another #interface inside the.m file? [duplicate]
(6 answers)
Closed 9 years ago.
As we know, normally we used to declare our class instance variables, properties, method declarations in class header file (.h).
But we can do the same things, in .m file, using blank category.
So my question is: what should be declared in .h file and what should be declared in .m file - and why?
Regards,
Mrunal
New Edit:
Hi all,
If you refer to newly added Apple examples over developer.apple.com - they are now declaring their IBOutlets and IBActions in .m file itself and that too with property declaration. But we can achieve the same thing by declaring those references in .h file in class private member section.
Then why are they declaring those in .m file and as properties, any idea?
-Mrunal
But we can do the same things, in .m file, using blank category.
A class continuation.
Normally, you choose to declare something in the header if it is intended to be public -- used by any client. Everything else (your internals) should typically go in the class continuation.
I favor encapsulation -- Here's my approach:
variables
Belongs in the class continuation or #implementation. Exceptions are very, very rare.
properties
Typically belongs in the class continuation in practice. If you want to give subclasses the ability to override these or to make these part of the public interface, then you could declare them in the class declaration (the header file).
method declarations
More in the class continuation than in the class declaration. Again, if it is meant to be used by any client it would belong in the class declaration. Often, you won't even need a declaration in the class continuation (or class declaration) -- the definition alone is adequate if it is private.
Basically, in the header file (.h) you declare your public API, while in the implementation file (.m) you declare your private API.
Visibility in Objective-C
You can also find the answer here
It's mostly up to you.
The .h file is like the description of your class.
It's smart to only put in the .h file what's really important to be visible from the outside of the class, especially if you're working with other developers.
It will help them to understand more easily what methods/properties/variables they can use, rather than having a whole list of things they don't.
Usually you want to use blank category in .m file for declaration of private properties.
// APXCustomButton.m file
#interface APXCustomButton ()
#property (nonatomic, strong) UIColor *stateBackgroundColor;
#end
// Use the property in implementation (the same .m file)
#implementation APXCustomButton
- (void)setStyle:(APXButtonStyle)aStyle
{
UIColor *theStyleColor = ...;
self.stateBackgroundColor = theStyleColor;
}
#end
If you try to access property declared in black category outside .m file, you will receive undeclared property compiler error:
- (void)createButton
{
APXCustomButton *theCustomButton = [[APXCustomButton alloc] init];
theCustomButton.stateBackgroundColor = [UIColor greenColor]; // undeclared property error
}
In most cases, if you want add new method/properties to an existing class without subclassing, then you want declare category in .h file and implementation of declared methods in .m file
// APXSafeArray.h file
#interface NSArray (APXSafeArray)
- (id)com_APX_objectAtIndex:(NSInteger)anIndex;
#end
// APXSafeArray.m file
#implementation NSArray
- (id)com_APX_objectAtIndex:(NSInteger)anIndex
{
id theResultObject = nil;
if ((anIndex >= 0) && (anIndex < [self count]))
{
theResultObject = [self objectAtIndex:anIndex];
}
return theResultObject;
}
#end
Now you can use "com_APX_objectAtIndex:" method wherever "APXSafeArray.h" is imported.
#import "APXSafeArray.h"
...
#property (nonatomic, strong) APXSafeArray *entities;
- (void)didRequestEntityAtIndex:(NSInteger)anIndex
{
APXEntity *theREquestedEntity = [self.entities com_APX_objectAtIndex:anIndex];
...
}