When the whole world is talking about Swift open source - 2015 Objective-C new features

Overview

Since the launch and open source of Swift 2.0 at WWDC 2015, everyone's enthusiasm for Swift has once again risen. While I envy my friends in startups who talk about the new features of Swift, there are also many developers like me who still need to stick to the Objective-C language at work. This year's WWDC introduced several new features of the Objective-C language, and they were also discussed in the topic of "Working with Swift", which further highlighted the marginalization of this language. However, it is still great to have new features. Next, this article will introduce the following three major new features:

Nullability

Lightweight Generics *

__kindof

Nullability

However, Nullability is not a new feature, and it has been supported since the previous version of llvm 6.1 (Xcode 6.3). This simplified version of Optional, without the support of ? and ! syntax sugar in Swift, is very verbose in Objective-C:

 @property (nonatomic, strong, nonnull) Sark *sark;
 @property (nonatomic, copy, readonly, nullable) NSArray *friends;
 + (nullable NSString *)friendWithName:(nonnull NSString *)name;

If it is used to modify a variable, double underscores are added in front of it. It is even more weird to put it in a block. For example, a start method of a Request can be written as:

 - ( void )startWithCompletionBlock:(nullable void (^)(NSError * __nullable error))block;

In addition to these two, there is also a null_resettable to indicate that the setter is nullable, but the getter is nonnull. It is very confusing. The most intuitive example is the view property in UIViewController:

 @property (null_resettable, nonatomic, strong) UIView *view;

It can be set to nil, but calling the getter will trigger -loadView to create and return a non-nil view.

From iOS9 SDK, we can find that all APIs in the header files have added Nullability related modifiers. If you want to understand the usage of this feature, you can just look through a few system header files. There are only a few nullable interfaces, so in order to avoid writing a lot of nonnull, Foundation also provides a pair of macros. The objects in them are added with nonnull modifiers by default. You only need to point out the nullable ones. The jargon is called Audited Regions:

 NS_ASSUME_NONNULL_BEGIN
 @interface Sark : NSObject
 @property (nonatomic, copy, nullable) NSString *workingCompany;
 @property (nonatomic, copy) NSArray *friends;
 - (nullable NSString *)gayFriend;
 @end  
 NS_ASSUME_NONNULL_END

Nullability provides type checking for null values ​​at the compiler level, and gives a warning when the type does not match, so that developers can find potential problems immediately. However, I think the greater significance lies in being able to describe the interface more clearly. It is an agreement between the caller and the callee, which is clearer than any number of document descriptions. For example:

 + (nullable instancetype)URLWithString:(NSString *)URLString;

By adding nullable in front of this NSURL API, it is more explicitly pointed out that this interface may fail to be created due to an error in the URLString format, so null detection is naturally taken into account when using it.

Not only objects in properties and methods, but also local objects and even C pointers can use double underscore modifiers, which means that Nullability can be used wherever the const keyword can be used.

So Nullability in general is, ugly to write, but comfortable to use - -

Lightweight Generics

Lightweight Generics Lightweight generics, lightweight because this is a pure compiler syntax support (llvm 7.0), like Nullability, without the help of any objc runtime upgrade, that is, this new syntax can be used on Xcode 7 and is fully backward compatible (lower iOS versions)

Containers with Generics

This is undoubtedly the most significant improvement this time. With generics, we can finally specify the type of objects in the container class:

 NSArray<NSString *> *strings = @[@ "sun" , @ "yuan" ];
 NSDictionary<NSString *, NSNumber *> *mapping = @{@ "a" : @1 , @ "b" : @2 };

After the return value id is replaced with a specific type, the touching code prompt also appears:

If you add the wrong object to a generic container, the compiler will be unhappy:

A series of commonly used container types in the system have added generic support, even NSEnumerator is supported, which is a very nice improvement. Like Nullability, I think the biggest significance is to enrich the interface description information, compare the following two writing methods:

 @property (readonly) NSArray *imageURLs;
 @property (readonly) NSArray<NSURL *> *imageURLs;

It is easy to understand what is stored in the array below, avoiding the confusion of NSString and NSURL.

Custom generic classes

It is more interesting to customize a generic class than to use the system's generic container. There is no documentation yet, but it does not stop us from writing test code. Suppose we want to customize a Stack container class:

 @interface Stack<ObjectType> : NSObject
 - ( void )pushObject:(ObjectType)object;
 - (ObjectType)popObject;
 @property (nonatomic, readonly) NSArray<ObjectType> *allObjects;
 @end  

This ObjectType is a placeholder for the incoming type. It can only be defined on @interface (class declaration, class extension, Category). If you like to use T, that's fine. This type is valid in the scope between @interface and @end. It can be used as an input parameter, an output parameter, or even a generic type for internal NSArray properties. It should be said that everything is in line with expectations. We can also add type restrictions to ObjectType, for example:

 // Generics that only accept NSNumber *  
 @interface Stack<ObjectType: NSNumber *> : NSObject
 // Only accept generic types that conform to the NSCopying protocol  
 @interface Stack<ObjectType: id<NSCopying>> : NSObject

If nothing is added, it means that any type (id) is accepted; when the type does not meet the requirements, the compiler will generate an error.

Instantiate a Stack and everything works fine:

For generics with multiple parameters, separate them with commas. Everything else is the same. You can refer to the header file of NSDictionary.

Covariance and Contravariance

When classes support generics, their Types change. For example, the following three objects all look like Stacks, but they actually belong to three different Types:

 Stack *stack; // Stack *  
 Stack<NSString *> *stringStack; // Stack<NSString *>  
 Stack<NSMutableString *> *mutableStringStack; // Stack<NSMutableString *>  

When two of these types are converted, the compiler needs to know which conversions are allowed and which are prohibited. For example, by default:

We can see that Stack without specifying a generic type can be converted to any generic type, but after specifying a generic type, two different types cannot be forced to convert. If you want to actively control the conversion relationship, you need to use the generic covariance and contravariance modifiers:

__covariant - covariance, subtypes can be forced to parent types (Liskov Substitution Principle)

__contravariant - contravariance, the parent type can be forced to the child type (WTF?)

Covariance:

 @interface Stack < __covariant ObjectType > : NSObject

Effect:

Inversion:

 @interface Stack<__contravariant ObjectType> : NSObject

Effect:

Covariance is very easy to understand. For example, the generic type of NSArray uses a covariance modifier, but I haven't thought of any practical usage scenarios for contravariance.

__kindof

The __kindof modifier is still very practical. It solves a long-standing pain point. Take this method of the original UITableView as an example:

 - (id)dequeueReusableCellWithIdentifier:(NSString *)identifier;

When using it, you will basically use a pointer to a UITableViewCell subtype to receive the return value. Therefore, in order to save developers from the pain of writing explicit casts every time, this API defines the return value as an id type. This API actually means returning an instance of a UITableViewCell or a UITableViewCell subclass, so the new __kindof keyword solves this problem:

 - (__kindof UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier;

This not only clearly indicates the return value, but also saves the user from having to write a forced conversion. Taking another example with generics, the subviews property of UIView is modified to:

 @property (nonatomic, readonly, copy) NSArray<__kindof UIView *> *subviews;

This way, there will be no warnings when writing the following code:

 UIButton *button = view.subviews.lastObject;

Where to go

With the new features introduced above and historical updates such as instancetype, the type detection and type inference of the ancient language Objective-C have finally made progress. Now there are fewer and fewer id types in both interfaces and code, and more potential type errors can be discovered by the compiler's static checking.

At the same time, I personally feel that the new version of Xcode has also strengthened the detection of inheritance chain constructors. The NS_DESIGNATED_INITIALIZER macro is not a new face. It can be used to mark designated constructors and convenience constructors like Swift.

Finally, here is a piece of code that uses all the new features. Swift is the development trend. If you still want to write Objective-C code for the time being, using all the new features may make your migration to the new language more painless.