I have thought of different ways of declaring private variables. I want to know whether there are any differences between them.
First way:
//In .h file
#interface DataExtract : NSObject
{
#private
double test;
}
Second way:
//In .m file. test is not declared in .h file
static double test;
Third way:
//In .m file. test is not declared in .h file
double test;
Any help would be much appreciated. Thank you.
All of them are not a good solution if you want an ivar.
I would even tend to only use properties with autogenerated ivars in an class extension in the implementation file only one line (#synthesize is automatically generated in Objective-C 3.0).
First way:
Yes this is an ivar, but you shouldn't declare it in the header file, if you declare it #private, then use the #implementation {...} block. In the implementation block you don't need to declare it #private, because it defaults to #protected, but in the implementation block it is not visible for subclasses
Second way:
That is a variable only visible in the translation unit, here the .m file itself. It is not global for the whole app. The value is persistent for every instance of your class, so it is no ivar (instance variable).
Third way:
That is also no ivar, it is a variable which defaults to extern, because you did not write static. That means it is in the global symbol table and can be used in other translation units /files if they #import/#include the .m file.
Your second and third examples are not instance variables, but global variables (with differing scope) and the same value will be shared across the entire process.
You can declare a private #interface in the .m file.
//DataExtract.m
#interface DataExtract ()
//your variables
#end
#implementation DataExtract
#end
For more info you can go here
Is there a reason you want to use just an instance variable, instead of a property?
You can declare a private property like so:
// Private Interface in .m file
#interface DataExtract()
#property (nonatomic) double test;
#end
Edit:
If you do want to use a private ivar, instead of a property, you could do it like so:
// Private Interface in .m file
#interface DataExtract() {
double test;
}
#end
Related
From all code I've seen, almost always is used something like this for property scope definition:
Class extension
/*We declare the class extension*/
#interface MyClass ()
#property (nonatomic, retain) Type *aPrivateProperty;
- (void)aPrivateMethod;
#end
/*
We can use the main implementation block to implement our properties
and methods declared in the class extension.
*/
#implementation MyClass
/*Therefore we can use synthesize ;-)*/
#synthesize aPrivateProperty;
- (void)aPrivateMethod {
//Some code there
}
#end
But this is (from what I've seen) rarely used:
#interface MyClass : NSObject {
iVar *aProtectedIVar;
#public
iVar *aPublicIVar;
iVar *aSecondPublicIVar;
#protected
iVar *aSecondProtectedIVar;
#private
iVar *aPrivateIVAr;
}
#end
Why modifiers like #private, #protected and #public are not used so much in Objective-C if they are available?
Access modifiers for instance variables are rarely used because they expose more information about the structure of your object than you may wish to allow others to see. An exposure of a public variable is binding on all future implementations to have the same variable. Property, on the other hand, hides the variable, letting you change your mind later on, and compute result instead of storing it.
Property access is highly optimized in Objective-C, so there is virtually no run-time hit for exposing a property instead of a variable. Since you gain flexibility for free by switching to property, exposing variables with #public is rarely used.
I was interested why class extension, (like from example above) is used more often than #private modifier
Because class extension lets you place private properties with your .m file, rather than your .h header file. Headers included from other .m files create compile-time dependencies, which are easily avoided by placing implementation details into class extensions.
You can declare a global variable in three places.
If you declare this in .h is public:
#property (nonatomic, strong) NSString *publicString;
Instead if you declare the same in .m is private there are no need for the second way.
I just learned, that I must declare instance variables and properties in a header file in Objective-C. So now i want to add instance variables to my XCTestCase subclass — but it turns out, XCTestCases come without header files.
How do i declare instance variables in my test cases?
You don't have to declare them in the header file at all. Instance variables and properties are commonly added within a private category in the implementation file:
#interface MyClass () {
BOOL _someVar;
}
#property NSString *someOtherVar;
- (void)_aPrivateMethod:(id)something;
#end
#implementation MyClass
...
#end
I am very new to Objective-C programming, and I have a question that has always puzzled me: why do you have to declare your variables in the header file, like this?
#interface MyViewController : UIViewController
{
NSString *myString;
}
Why not just declare them here (in the .m file):
#implementation MyViewController
- (void)viewDidLoad
{
NSString *myString;
}
The first declaration is a instance variable available to all instance methods. The second is local to the one method.
However it is possible to declare instance variables in the .m file:
#implementation MyViewController {
NSString *myString;
}
In fact this is the preferred way to declare instance variables that do not need to be exposed. Only declare things in the .h file that need to be available to other classes.
There are two different questions going on here.
To put it simply, the header file (.h) is a public gateway for everything else to see what your class is about without having to know anything about your implementation. Your header file should contain everything that you would want other classes to know about (i.e. public methods, properties).
You could easily declare things in the implementation file but then other classes would not know about them.
Secondly, in the example you provided you have put NSString *myString; in the viewDidLoad method. This means that such a variable would be only available in the scope of that method. Nothing else would be able to access it.
I'm sure my confusion here is just a result of being stuck in a "Java mindset" and not understanding how Obj-C differs in this case.
In Java, I can declare a variable in a class, like this, and each instance of that class will have it's own:
MyClass {
String myVar;
MyClass() {
// constructor
}
}
In Obj-C I tried to do the same thing by declaring a variable only in the .m file like this:
#import "MyClass.h"
#implementation MyClass
NSString *testVar;
#end
My expectation here was that this variable has a scope limited to this class. So I created a second class (identical):
#import "MySecondClass.h"
#implementation MySecondClass
NSString *testVar;
#end
What I'm seeing (and has me baffled) is that changing the variable in one class, affects the value seen in the other class. In fact, if I set a breakpoint, and then "Jump to Definition" of the variable, it takes me to th
I've created an extremely small Xcode project that demonstrates the problem here.
Change this:
#implementation MyClass
NSString *testVar;
#end
to:
#implementation MyClass {
NSString *testVar;
}
// methods go here
#end
and you'll get what you expected.
As you had it, you are actually creating a global variable. The two global variables were combined into one by the linker which is why both changed when you set one. The variable in curly braces will be a proper (and private) instance variable.
Edit: After being downvoted for no apparent reason, I thought I'd point out the "old" way of doing things, and the new way.
The old way:
SomeClass.h
#interface SomeClass : UIViewController <UITextFieldDelegate> {
UITextField *_textField;
BOOL _someBool;
}
#property (nonatomic, assign) BOOL someBool;
// a few method declarations
#end
SomeClass.m
#implementation SomeClass
#synthesize someBool = _someBool;
// the method implementations
#end
Now the new and improved way with the modern Objective-C compiler:
SomeClass.h
#interface SomeClass : UIViewController
#property (nonatomic, assign) BOOL someBool;
// a few method declarations
#end
SomeClass.m
#interface SomeClass () <UITextFieldDelegate>
#end
#implementation SomeClass {
UITextField *_textField;
}
// the method implementations
#end
The new way has several advantages. The primary advantage is that none of the implementation specific details about the class appear in the .h file. A client has no need to know what delegates the implementation needs. The client has no need to know what ivars I use. Now, if the implementation needs a new ivar or it needs to use a new protocol, the .h file doesn't change. This mean less code gets recompiled. It cleaner and much more efficient. It also makes for easier editing. When I'm editing the .m file and realize I need a new ivar, make the change in the same .m file I'm already editing. No need to swap back and forth.
Also note the implementation no longer needs an ivar or #synthesize for the property.
What you probably want (unless you're using a very old OS and compiler) is to just use property syntax. I.e.:
#interface MyClass : NSObject
// method declarations here ...
#property (copy) NSString* myVar;
// ... or here.
#end
This will do what you intended to do. This will implicitly synthesize an instance variable and a getter/setter pair for this variable. If you manually wanted to create the instance variable (you generally don't need that unless you need your code to work on very old MacOS versions), this is what the above code does under the hood to create the ivar:
#interface MyClass : NSObject
{
NSString* _myVar;
}
// method declarations here.
#end
Note the curly braces, which tell the compiler that this is not just a global variable somewhere in between the methods, but actually an instance variable that belongs to this object.
If you are creating the property only for internal use and don't want clients of your class to mess with it, you can hide this away a little bit in everything but the oldest ObjC compilers by using a class extension which "continues" the class declaration from the header, but can be placed separate from it (so usually in your implementation file). A class extension looks like a category without a name:
#interface MyClass ()
#property (copy) NSString* myVar;
#end
And you can either put your property declaration in there, or even ivar declarations (again wrapped in curly brackets). You can even declare the same property as readonly in the class interface, and then re-declare it identical, but as readwrite in the extension, so that clients only read it, but your code can change it.
Note that, if you didn't use ARC (that is, you've switched off the default of Automatic Reference Counting), you would have to set all your properties to nil in your dealloc method (unless they're set to weak or assign of course).
NB - All the above are #interface sections. Your actual code will go in separate #implementation sections. This is so you can have header files (.h) you can hand off to your class's clients that just contain the portions you intend them to use, and hide away implementation details in the implementation file (.m) where you can change them without having to worry someone might have accidentally used them and you'll break other code.
PS - Note that NSStrings and other objects that you want the immutable flavor of, but that also exist in a mutable flavor (i.e. NSMutableString) should always be copy properties, because that will turn an NSMutableString into an NSString so that nobody on the outside can change the mutable string underneath you. For all other object types, you generally use strong (or retain if not ARC). For your class's owner (e.g. its delegate) you usually use weak (or assign if not ARC).
In Java
MyClass {
String myVar;
MyClass() {
// constructor
}
}
In Objective-c
MyClass.h
#interface MyClass : NSObject{
NSString* str; // Declaration
}
#end
MyClass.m
#implementation MyClass
-(void)initializieTheString
{
//Defination
}
#end
In objective-c, you define the variable as private by doing like so
MyClass.h
#interface MyClass : NSObject{
NSString* _myTestVar; // Declaration
}
#end
and refer to it in the implementation class by doing like so
MyClass.m
#import "MyClass.h";
#implementation MyClass
-(void)initializieTheString
{
_myTestVar= #"foo"; //Initialization
}
#end
I've come across Objective-C code that declares a variable right below the #implementation line in a .m file and not in the #interface block of the .h file. It then proceeds to use it like a private ivar. I haven't been able to find documentation about declaring variables this way and would like to know the impact.
Example:
.h
#interface MyClass {
#private
int _myPrivInt1;
}
#end
.m
#implementation
int _myPrivInt2;
#end
Questions:
What is the technical difference between these two variables?
Is it the same as declaring an ivar in the .h #interface block using the #private modifier or is it more like a C global variable?
Are there any implications when declaring a variable this way?
Should it be avoided?
Is there a term for declaring variables like _myPrivInt2 that would have made my googling a bit more successful?
You must declare instance variables in interface block.
#implementation
int _myPrivInt2;
#end
Declaring variable this way you do not actually declare iVar for your class. _myPrivInt2 will be a global variable and can be accessed from any part of your code using extern declaration:
// SomeOtherFile.m
extern int _myPrivInt2;
...
_myPrivInt2 = 1000;
You can check - your _myPrivInt2 variable will be equal 1000 after code in SomeOtherFile.m executes.
You can also specify static linkage specifier to your _myPrivInt2 so it will be accessible inside current translation unit only
#implementation
static int _myPrivInt2; // It cannot be accessed in other files now
#end