| |
Swift is indeed a very powerful language, it is very simple to use the various features powerful, but for now, the feeling is not enough maturity, so commercial projects using OC is relatively stable behavior. It seems at WWDC 2015's Swift and Objective-C Interoperability session, the first part of the video is mainly to explain the rules of interaction between the OC and swift, then later talked about part of the new language features OC, which several features, Apple developers staff at WWDC said, to enhance the readability of the code is very large, so this feature from the swift introduction of the OC, the personal feeling is to provide support for the migration to the swift follow-up, the most important of these characteristics in iOS the SDK and comprehensive use and is compatible with low version, these features can be introduced in the current work.
The first half of the article before the record some of the modern Objective-C syntax, later explained the new features introduced in WWDC 2015, detailed recommendations to watch WWDC 2015 videos.
instancetype
This aspect can refer to my previous summary of a blog, the distinction between id, NSObject *, id, instancetype of
Properties
Instead of using the Properties instance variable has many advantages:
Auto synthesized getters and setters. Use @property declaration attributes can automatically generate getter and setter methods.
Better declaration of intent of a set of methods. A series of declarations on the property ratio method code is much clearer.
Property keywords that express additional information about behavior. Property use some other key sub-instance variables can express some information can not be expressed, for example, assign, weak, atomic, and so on.
Property has a very simple method of naming names getter method is the name of the property, the name of the setter method is set before the property name with the prefix (hump method). You can specify the name of getter getter by keyword through yet.
Property in a statement when the need can not remember these are properties of:
init method
copy method, mutableCopy method
A class factory method
Initializes an action and return a BOOL results-based approach
A method that explicitly changes internal state as a side effect of a getter
Enumration Marcos
Use NS_ENUM to define enumeration to define the options to use NS_OPTIONS. These two macros can improve Xcode code completion, and made clear that the enumeration type and size options.
Object Initialization
For compatibility may be swift, OC added designated initializer initialization method and convenience initializers initialization method:
designated initializer: responsible for calling the superclass initialization method and initialize its instance variables initialization method
convenience initializers: non-designated initializer are called designated initializer. These are generally internal implementation initializer calls another initializer, but after the final series of chained calls eventually call one designated initializer method to initialize behavior.
Achieve a designated initializer method is very simple and can be realized through NS_DESIGNATED_INITIALIZER macro, but the use of designated initializer, there will be some restrictions on the rules, with the swift of these rules are very similar.
WWDC 2015
Nullability
Nullability feature is used to indicate the Objective-C / C pointer is for nil. Obviously, using this feature more clearly express the intention of the API, and can enhance the compiler's static checking, there is little you can increase the availability of these API in the swift. If you use the words Xcode 7, you may notice this feature in the iOS SDK has been used a lot. This screenshot below illustrates the Nullability usage.
OC is how to introduce this feature and let the low version of iOS support it? Apple called Audited Regions, which is below the area between the two macros, NS_ASSUME_NONNULL_BEGIN ... NS_ASSUME_NONNULL_END.
Audited Regions on which the pointer do some default assumptions, Single-level pointer is considered to be the nonnull, NSError ** pointer to be considered in each of the pointer level above all nullable. So we only need to specify those nullable or null_unspecified scene within Audited Regions.
Use Nullability pointers in C, then the OC in different places that need to use the nullability qualifier in front to add double underline, and you want nullability qualifier written on the back pointer.
Lightweight Generics
This lightweight generics, on the one hand will increase the readability of the code, so that API is becoming clearer. On the other hand, can make the compiler will help us to do some type checking, find some potential errors, Type Safety achieve results.
Daily usage is mainly for two sets of classes, NSArray and NSDictionary, detailed usage can refer to the official use of the SDK. At the same time, we can in our own code to use the generics lightweight, custom class, category, extension, and so on.
Category / Extension of syntax
WWDC also stressed the point is, Lightweight Generics are forward-compatible, and will not change the OC of runtime, while not causing any impact on the generated code.
__kindof
In OC, our code will be extensive use of id this feature, this feature will bring with it a lot of very convenient features, but it has a flaw, we often need to be cast. Xcode 7 has a new feature, __ kindof, "Kindof" types express "some kind of X", with __kind modified variable represents a class or subclass of this class.
When we put this class or subclass other variables assigned to this variable, the compiler will default to help us perform type checking and type conversion work, so we do not need to write some casts such a code. An example of the simplest is the application of the UITableView, cellForRowAtIndexPath: variable returns using this modification, we will no longer need to write any of the cast, for example, CustomCell * cell = [tableview cellForRowAtIndexPath: indexPath];
At the same time, we can Kindof types and lightweight generics combine features such as official
About id type
After reading the above new features, you'll find the usual development, you really need that much id it? In most cases, we can use a more accurate representation of the type, so to avoid some of the problems such as type safety and also makes your code more clear. The following look at alternative scenarios official id specified:
In return "self" approach, instead use id instancetype
Most Typed Collections Collections can become a place of id
__kindof X * to indicate "some subclass of X", instead of using id, can reduce type casts such code
id represents any type of conforms to SomeProtocol
The circumstances under which id it? Only those you sure you want to represent "an object of any type" when the re-use id, otherwise, try to use a different syntax instead id. |
|
|
|