We used to declare property to pass data between classes as following:
.h file (interface file)
#property (nonatomic) double topSpeed;
.m file (implementation file)
#synthesize topSpeed;
Now there is no interface class, how to pass data between .swift classes ?
Swift provides no differentiation between properties and instance variables (i.e, the underlying store for a property). To define a property, you simply declare a variable in the context of a class.
A swift class is simply a ClassName.swift file.
You declare a class and properties as
class SomeClass {
var topSpeed: Double
var aStrProperty: String
var anIntProperty: Int
//Initializers and other functions
}
You access property values via dot notation. As of Xcode6 beta 4, there also are access modifiers (public, internal and private) in Swift. By default every property is internal. See here for more information.
For more information, refer to the Swift Programming Guide:
Stored Properties and Instance Variables
If you have experience with Objective-C, you may know that it provides
two ways to store values and references as part of a class instance.
In addition to properties, you can use instance variables as a backing
store for the values stored in a property.
Swift unifies these concepts into a single property declaration. A
Swift property does not have a corresponding instance variable, and
the backing store for a property is not accessed directly. This
approach avoids confusion about how the value is accessed in different
contexts and simplifies the property’s declaration into a single,
definitive statement. All information about the property—including its
name, type, and memory management characteristics—is defined in a
single location as part of the type’s definition.
Using Properties.
From the Swift Programming Guide:
Stored Properties and Instance Variables
If you have experience with Objective-C, you may know that it provides
two ways to store values and references as part of a class instance.
In addition to properties, you can use instance variables as a backing
store for the values stored in a property.
Swift unifies these concepts into a single property declaration. A
Swift property does not have a corresponding instance variable, and
the backing store for a property is not accessed directly. This
approach avoids confusion about how the value is accessed in different
contexts and simplifies the property’s declaration into a single,
definitive statement. All information about the property—including its
name, type, and memory management characteristics—is defined in a
single location as part of the type’s definition.
Properties in Objective-C correspond to properties in Swift. There are two ways to implement properties in Objective-C and Swift:
Synthesized/auto-synthesized properties in Objective C -- these are called "stored properties" in Swift. You simply declare it with var topSpeed : Double or let topSpeed : Double = 4.2 in a class declaration, exactly as you would declare a local variable in a function body. You don't get to specify the name of the backing instance variable because, well, there are currently no instance variables in Swift. You must always use the property instead of its backing instance variable.
Manually implemented properties in Objective-C -- these are called "computed properties" in Swift. You declare them in the class declaration like var topSpeed : Double { get { getter code here } set { setter code here } } (for readwrite properties), or var topSpeed : Double { getter code here } (for readonly properties).
It sounds like at least part of your question relates to communicating a given class's interface to other classes. Like Java (and unlike C, C++, and Objective-C), Swift doesn't separate the interface from the implementation. You don't import a header file if you want to use symbols defined somewhere else. Instead, you import a module, like:
import Foundation
import MyClass
To access properties in another class, import that class.
Stored Properties and Instance Variables
If you have experience with Objective-C, you may know that it provides two ways to store values and references as part of a class instance. In addition to properties, you can use instance variables as a backing store for the values stored in a property.
Swift unifies these concepts into a single property declaration. A Swift property does not have a corresponding instance variable, and the backing store for a property is not accessed directly. This approach avoids confusion about how the value is accessed in different contexts and simplifies the property’s declaration into a single, definitive statement. All information about the property—including its name, type, and memory management characteristics—is defined in a single location as part of the type’s definition.
From the Swift Programming Book:
struct FixedLengthRange {
var firstValue: Int
let length: Int
}
var rangeOfThreeItems = FixedLengthRange(firstValue: 0, length: 3)
I say : typealias is equivalent even more in swift for #synthesize
just look at this link : https://docs.swift.org/swift-book/ReferenceManual/Declarations.html
Related
Even though the question is quite wide I am actually curious regarding one case I sow recently while using the Realm library. As I previously used the protocols(delegate) on many occasions and also imported classes using <>. And now this is the line the code I don't completely understand or don't understand at all if I am mistaking:
#property (nonatomic, strong) RLMArray <ExerciseLog *><ExerciseLog> * exerciseLogs;
I suppose that the second part of the line <ExerciseLog> * exerciseLogs is used to ensure that exerciseLogs may be an instance of any ExerciseLog that conforms to the ExerciseLog protocol, is my assumption correct?
Or simple said if the user send a different object then the expected one, the app won't crash, and that a default value will be assigned.
And this part I am guessing, the is some sort of safe casting so that the returned object confirms to the ExerciseLog.
A combination of Obj-C protocol conformance and generics. RLMArray is declared as
#interface RLMArray < RLMObjectType : RLMObject * > : NSObject<RLMCollection,NSFastEnumeration>
it has one generic argument. That's the <ExerciseLog *>.
The second part <ExerciseLog> is conformance to protocol of the given type.
By the way, that protocol is declared using RLM_ARRAY_TYPE macro. The code seems to be a bit complicated but it was probably an older way to enforce element type for arrays (RLMArray<protocolX> is not assignable to RLMArray<protocolY>).
Quoting the documentation:
Unlike an NSArray, RLMArrays hold a single type, specified by the objectClassName property. This is referred to in these docs as the “type” of the array.
When declaring an RLMArray property, the type must be marked as conforming to a protocol by the same name as the objects it should contain (see the RLM_ARRAY_TYPE macro). RLMArray properties can also use Objective-C generics if available. For example:
The angle brackets in a class interface definition indicates the protocols that your class is conforming to.
A protocol is almost like an interface in Java or C#, with the addition that methods in an Objective-C protocol can be optional.
Additionaly in Objective-C you can declare a variable, argument or instance variable to conform to several protocols as well. Example
NSObject *myVariable;
In this case the class must be NSObject or a subclass (only NSProxy and its subclasses would fail), and it must also conform to both NSCoding and UITableViewDelegate protocols.
In Java or C# this would only be possible by actually declaring said class.
What must be accomplished in the implementation of an initializer?
a. All properties need to be initialized with a value
b. All properties need to be explicitly assigned a value.
c. All non-Optional properties need to be initialized.
Sorry, that's incorrect.
Optionals need to be initialized as well.
d. The object needs to be created
What answer is correct and why?
In my opinion that is very confusingly stated question. Because what you as the developer have to do is Option c.
Take a look at this simple code example and the minimum init to be compilable
class SomeClass {
var a : AnyObject
var b : AnyObject?
var c : AnyObject!
var d = ":)"
init() {
a = ""
print("initialized")
}
}
The swift docu states
Classes and structures must set all of their stored properties to an appropriate initial value by the time an instance of that class or structure is created. Stored properties cannot be left in an indeterminate state.
You can set an initial value for a stored property within an initializer, or by assigning a default property value as part of the property’s definition. These actions are described in the following sections.
Option d. is imho non-sense since the object creation is handled by the underlying runtime environment and not via the initializer.
Now b. and a. remain with the tiny difference in wording explicitly assigned vs. initialized. I would therefore discard Option b because the b and c variable do not need any explicit value, the implicit nil is perfectly fine for the time (reading c will not work yet though)
Therefore my answer choice would be Option a. After the init method all properties need to have some specific value. Some of them explicitly in the init function, some of them implicitly.
tl;dr:
my final answer is Option a.
I have created a class RootView with two properties, declared in different ways. Now I want to know what the difference between those two declarations is?
class RootView: UIViewController {
// MARK: - Variables
var rightMenu: RightMenu = RightMenu()
let right = RightMenu()
}
Please guide me about difference between right and rightMenu?
Both are of same type, but here below are few points that will tell when you need Type Annotation and when not.
Here are few concepts.
Your rightMenu is a variable, you reassign a value of same type at alter point, where as right is a constant, you can not reassign a new value.
Swift introduced type inference concept, where if you assign a value(literals) with out providing type, it will directly determine the the type for you. So need to provide explicitly type for it. Here your both rightMenu and right are of same type.
Ideally no need to provide explicitly type if you are assigning initial value to a variable at the time of declaration.
a) var myClass: MyClass!
Here you need to provide type, because no intial value is provided and you want to assign value to it at later point.
b) var myClass = MyClass()
Here no need, because you provided a initial value and Swift compiler will automatically determine the type for it.
In Swift providing/declaring type for a variable or constant after : symbol is called Type Annotation. For more details, see Apple documentation
The only difference is the mutability of those two variables. You can change rightMenu because it's mutable. However, right is not mutable. It means that right is a constant.
From the syntax prospectives, you don't necessarily to add :RightMenu when you declare rightMenu. Like you declare right, compiler will infer the object as type of RightMenu. But, when you want only to declare something without initializing it. You probably need to use :<type>? to tell the compiler that the type of this ivar and the value might be missing.
I have noticed in many of the header documentation files in the Apple framework that define variables within brackets directly following the interface definitions like the variables a and b below:
#interface MyView : UIView {
#package
int a;
UIView b;
}
Normally I have just been declaring all variables as properties for the convenience of the synthesized methods. Can anyone tell me when it would be more efficient or more proper to declare variables under #package instead of as #properties?
#package is an access specifier, similar to how it works in Java (it allows access from any code at the same package level). But since the . syntax with Objective C objects works with properties, and not direct member access, you have to use the -> syntax instead, as if the object were a C struct, to access that variable directly.
An auto-synthesized #property instead creates a protected instance variable (prefixed with an underscore), which is read and set by the synthesized methods. Now, the overhead of using a property is negligible, compared with direct member access, so there's no real reason to stop using properties.
In your example, if you had a MyView* myview, you could set the view b directly, with myview->b = someotherview;. But this would give the class no chance to respond to the update (you would probably write the setter method so you can do something with it), nor does it ensure that the view provided is retained properly. These are the issues that properties were designed to avoid.
Why must I define variables twice in the header file? What differences are there between these variables?
The first definition is here:
#interface MyController: UIViewController
{
NSInteger selectedIndex;
}
The second definition is here:
#property (nonatomic) NSInteger selectedIndex;
What you're seeing was required in earlier versions of Objective-C,
but isn't any more.
In the first versions of Objective-C used by NeXT up until the new
runtime was introduced (with Objective-C 2.0 on Mac OS X), all
instance variables had to be declared as part of the class's structure
in its #interface. The reason was that if you subclassed a class,
the compiler needed to know the instance variable layout of the class
so it could see at what offset to put the subclass's instance
variables.
When properties were introduced, synthesized properties had to be
"backed" by an instance variable in the class's structure. Therefore
you had to declare both an instance variable and the property.
All of the above is no longer true. Newer Objective-C is less fragile
in the way it looks up instance variable offsets, which has meant a
few changes:
not all instance variables need to be in the #interface. They can now be defined in the #implementation: though not in categories due
to the possibilities of clashing and other issues.
instance variables for synthesized properties can be inferred and created based on the property definition.
you can programmatically add instance variables to classes you're creating at runtime (only before you've registered the class as
available to the system).
So, to reiterate, you only needed to declare both the instance
variable and a synthesized property in older versions of the
Objective-C language. What you're seeing is redundant and should not
be considered a "best practice".
[Source]
As others have pointed out, it is no longer necessary to declare a backing instance variable for a synthesized property in the header.
To make this a bit clearer though: What you're seeing are not two declarations of the same variable, it is one declaration of the variable and one declaration of the property.
A property is basically a set of methods (in this case selectedIndex and setSelectedIndex:) that are typically used to access instance variables. There is a difference between a property and an instance variable. The property's setter/getter could do more than just set the variable, in your example, it could also e.g. update the UI to reflect the change of the selected index or the getter could infer the index from some other variable (in this case, there might be a selection index path), etc.
Synthesizing a property simply frees you of implementing those methods yourself and provides you with default implementations that simply set the variable, but you could also implement selectedIndex and setSelectedIndex: yourself just like any other method in which case you might either need the instance variable itself or omit it altogether (in case of an inferred property).
In modern runtime you do NOT need to declare them twice. Just use:
In you .h
#property (nonatomic) NSInteger selectedIndex;
The part between the {} is the declaration of the iVar. And with your #property you declare getter and setters. In modern runtime if you just use the code above you say basicly the same (your iVar is now _selectedIndex).