Several tips for Swift development

As the saying goes, the best way to master a technology is to use it to make something, so the actual combat during this period has allowed me to have a deeper understanding of Swift and accumulate some usage skills. Today I will share one: how to correctly define a class variable (and class constant).

The Swift language is a little bit difficult to adapt to for developers who come from static or dynamic languages. The solutions to many problems cannot be done with the familiar methods.

How to correctly define a class variable (and class constant)

Swift supports using class func to modify a "class method", but you cannot use "class var" and "class let" to specify class variables and class constants. Once you try to do this, Xcode will prompt you: Class variable not yet supported. What a pity...

However, from this tip, we can see that the support of class variables is only a matter of time. So how can we achieve this goal at this stage? We can't use ugly workarounds. There is a way. I learned from Apple's official examples how to define a class-level constant and variable, that is, using struct.

Take a demo and you will understand:

 class MyClass {
 struct Constants {
 static let name = "MyClass"   
 }
 struct Variables {
 static var age = 0   
 }
 }

Then when calling, you can call like this: MyClass.Constants.name and MyClass.Variables.age

Although there is a layer of Constants and Variables in the middle, I think this is also good. It is equivalent to having a prefix. When you look at the code directly, you can know whether it is a constant or a variable. If you don't like this method, you can also use the form of computed property to simulate the call of real class variables (constants). For example:

 extension MyClass {
 class var name: String {
 get {
 return Constants.name
 }
 }
 class var age: Int {
 get {
 return Variables.age
 }
 set {
            Variables.age = newValue
 }
 }
 }

After defining this method, you can directly use MyClass.name and MyClass.age to access class constants or modify class variables.

This method is syntactically compatible with class variables and class constants that will be supported in the future, but it requires you to write a lot of getters and setters yourself, which is a bit troublesome. You can decide whether to use this method based on your needs.

You can paste the demo code in the "swift" command line tool to practice. The effect is just as we want, constants are not allowed to be modified, but variables can be modified, and all these operations are performed on MyClass without instantiation.

Although it is still a bit cumbersome to use Swift to do some common tasks, as a young language, it can indeed be used to write truly usable apps in production environments. With further development, I believe it will get better and better.

PS: Now I just want SourceKitService to crash less often...

Using Optional to avoid abnormal pointer problems

I recently encountered a problem while developing with Swift. Simply put, the system returned an abnormal pointer (pointing to the address 0x0000, generating a KERN_INVALID_ADDRESS exception) where a non-nil value should be returned, causing the App to crash. This is a bug in iOS UIKit.

This problem needs to be solved by upgrading the SDK, but before the SDK is upgraded, we can solve it through a small workaround. The whole process is as follows:

The biggest difference between the Swift version of the iOS API and the Objective-C API is that you need to read the Objective-C API documentation to know whether a system return value may be nil.

For example, UIDataSourceModelAssociation is a protocol used to restore the position of UITableView and UICollectionView. It has two methods, one of which is:

 1   
     
 - (NSString *)modelIdentifierForElementAtIndexPath:(NSIndexPath *)idx inView:(UIView *)view 
 
 Just looking at the Objective-C method, you don’t know whether the idx returned by the system may be nil, but when you look at the Swift version, it is very obvious:
 1   
     
 func modelIdentifierForElementAtIndexPath(_ idx: NSIndexPath, inView view: UIView) -> String 
 
 Like inView, idx has no ? and !, so they are not Optional, so the value cannot be nil. If idx and inView may be nil, then it should be modified with ! to warn developers that this value may be nil, please use it with caution.
 1   
     
 func modelIdentifierForElementAtIndexPath(_ idx: NSIndexPath!, inView view: UIView!)

Swift is a more thorough API-documentation expression than Objective-C, and I really like it after coding for a while.

However, it is precisely because the system framework has not evolved completely that these APIs may still return nil values, but because the APIs are marked as not returning nil, a swift_dynamicCastClassUnconditional exception will occur, causing the App to crash.

The following figure shows that the modelIdentifierForElementAtIndexPath method should return a value, but it returns an object pointing to 0x0000000000000000. Then Swift fails to wrap the value and crashes.

So how do we avoid App crashes caused by this problem? In fact, it is very simple. You only need to manually wrap the 0x0000 object with Optional and then check whether it is nil. Then the problem will not occur. For example, the following code:

 let optionalIdx = Optional(idx)
 if optionalIdx == nil {
 return   "Do something"  
 }

I was also very troubled when I first encountered this problem, but then it suddenly occurred to me that I could use Optional to wrap this abnormal pointer and then check whether it was nil. I tried it and it worked. So the problem was solved.

Fortunately, there aren’t enough of these pitfalls to drive me crazy, and I can continue writing happily in Swift…

How to design network requests with Swift thinking

Recently, when I was developing apps with Swift, my biggest experience was that I gradually started to think in a "Swift way". Looking back at the beginning when I used Swift, I just applied its syntax, and my mind was still thinking in Objective-C.

During this period, as I mastered the basic features of Swift, I began to consciously learn and try some features that are unique to Swift, which is called "Swift thinking". Swift has many proprietary patterns (not available in Objective-C). Today I will start with a very simple example, which is:

How to design network requests using Swift thinking.

Anyone who has worked on network applications should know that when we make a network request, there are usually two results: one is failure, returning an error, and the other is success, returning a result. Of course, there are more complicated situations along the way, such as: 1. Failure of the network request itself (such as network timeout); 2. Internal result failure returned by the API end (such as incorrect password). We will not break it down here.

In traditional Objective-C projects, there are several ways to handle this exception, mainly:

Directly judge NSError

 NSError *error = nil;
 id result = [API doSomething:&error];
 if (error != nil) {
 NSLog( "Oh Error!" )
 }

This method is too straightforward and will usually block the current thread, so it is not recommended. The following two methods are commonly used:

Handle it through success and failure blocks

 [API doSomethingWithSuccess:^(id result) {
 NSLog(@ "Seems good" )
 } failure:^(NSError *error) {
 NSLog(@ "Oh Error!" )
 }];

This is relatively better. Through the Block and internal implementation, the current thread can be processed without blocking. The corresponding Block handles the corresponding situation: success or failure. However, this design still has a flaw, because it handles the results in different Blocks. If I need to handle the success or failure in a unified way, I need to call them separately, which is not very intuitive. Therefore, we have a third mode.

Handled by a unified completionHander block

 [API doSomethingWithCompletionHandler:^(id result, NSError *error) {
 if result != nil {
        NSLog(@ "Seems good" )
 }
 if error != nil {
 NSLog(@ "Oh Error!" )
 }
 }];

This unified handling of success results and error failures through CompletionHandler should be the first design, including the system's own API design. It is particularly suitable for the need to handle all situations in one Block.

Swift-style network request processing

I have briefly listed three common network request processing methods in Objective-C. They look pretty good. So what is the Swift mode like? Can it be better? I think so.

Swift has a great enum mechanism, all enumeration cases can be of any type, and can be of different types. This means that we can wrap a result-type enum in Swift, for example:

 enum Result {
 case Error(NSError)
 case Value(JSON)
    init(_ e: NSError?, _ v: JSON) {
 if let ex = e {
            self = Result.Error(ex)
 } else {
            self = Result.Value(v)
 }
 }
 }

This is my real-world code, used in my Weibo client.

The code is very simple. I defined an enum object called "Result", which will wrap two situations. One is Value, which is a JSON value when the network request is successful; the second is Error, which is an NSError value. When the network request fails, it contains specific error information.

In this way, we successfully package the two possible situations of a network request into a Result object. This object is either a successful result or a failed error. There will never be a result and an error at the same time. Therefore, our network request processing code can be designed more simply like this:

 API.doSomethingWithCompletionHandler({ (result) -> Void in
 switch (result) {
 case let .Error(e):
 NSLog( "Oh Error!" )
 case let .Value(json):
 NSLog( "Seems good" )
 }
 })

Does it look like the second mode of Objective-C? Or does it look like the third mode? Let's call it a hybrid mode. Let me briefly explain the advantages of this mode:

First, by using the Switch conditional judgment mode, we can reduce many errors and ensure that there will be no problems with conditional branch judgment; second, we are still only processing our request result in a Closure (here we use Swift terminology instead of Objective-C Block), so we can do some other unified processing of the results before and after to ensure the unity of our logic.

This is what I think is the benefit of the Swift model.

After transforming my project through this model, I feel that the code has become neater, the logic is clearer, and there will be no lost error handling. Of course, I only use a simplified version of Swift mode network processing. For a more powerful example, you can refer to the Result object of the swiftz project, which uses the Generic feature of Swift, so that it can wrap any value (not just JSON), thereby greatly enhancing the scalability: https://github.com/typelift/swiftz/blob/master/swiftz_core/swiftz_core/Result.swift#L12

I am still in the process of transforming the project with Swift thinking. At present, this model should still have room for improvement. I hope to have more discussions and exchanges with you about this.