In 2015, I also went to see ObjC. At first, I felt bad about the C language and objC extension together. It was very confusing.

  1. Both are functions, and C’s and OBJC’s functions are created and used very differently, and mixed together
  2. Objc functions with parameter tags are unbearably long
  3. Even the smallest app in the first step, you have to understand the design pattern, and it starts out as a delegate

So I think objC is primitive and has not evolved with the flow and other languages to become famous, which is not true. Plus THE UIKit package does a poor job. After writing a little app, I gave up.

When Swift came out at the beginning of 2016, I had a look at it and felt much better. After all, the language seemed close to the mainstream. And there are powerful object literals like scripts, so start really learning. Compared with ObjC, Kan has less language barrier, but:

  1. UIKit function names are still labeled, still long, and you can get a feel for the first AppDelegate function: func Application (_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool
  2. You still need to understand design patterns, first of all delegate MVC. Viewcontrollers all over the place.

But I learned anyway. I wrote some notes on Github. I went through 7 or 8 books and felt too verbose, full of stuff that wasn’t directly relevant to what I was trying to learn, and lots of screenshots of storyboard-related actions. These screenshots get on my nerves. I’m a programmer. Write code, watch code, run code. Look at pictures? It’s not like you’re learning Photoshop. In 2017, I decided to pick it up, and I did it by going directly to Apple’s developer documentation. Of course, it’s hard, because this thing is for UIKit itself, it’s important to speak for itself, and there are typically very few examples of official documentation. I’ve looked at the UIKit Foundation section of this document a couple of times. Read the day to take notes, notes to ensure that there is a prepared by their own can run the case. The case must be pasted into the IDE once, and then RUN. Control by control down, and published on the nuggets. I really couldn’t understand it. I checked Google and SO and found no result, SO I printed it out and looked it over and over again.

At this time I feel inside the head is already all knowledge, to burst, must have output. I then found another App, Finb/ V2EX-Swift, a v2EX client written by swift, which is open source. I looked through several apps and found that this code was relatively simple and neat, and I was familiar with the forum I visited. Therefore, I decided to repeat what I learned from it and confirm my knowledge. In addition to clean code and simple structure, this APP also has many third-party packages. Such as pull-down control, 1Password extension, Keychain extension, Alamafire network extension and so on to develop an App almost necessary package, can be learned together. The address is here: TofJ’s personal homepage – Gold digger, before you know it, has accumulated 40 articles. Blog on the Nuggets in March, fooling 1500 followers. I have been guided by a few principles:

  1. Just focus on what you’re saying, not what’s relevant to your immediate concern
  2. The code sticks to the IDE, overwrites AppDelegate.swift, and then you can RUN, guaranteed to RUN, without having to scramble through your article
  3. Stick to code, not storyboards. With SB, directly into the screenshot party, operator, a picture too much detail, but read, there is no content. I’m not against using SB for design, but I’m definitely against using SB to learn UI design from UIKit

I read the Finb/ V2EX-Swift code and did some refactoring of my own:

  1. The idea is to extract common code, move it around and put it in a more appropriate place, and encapsulate simple basic classes, such as TableView, which encapsulates the most commonly used controls.
  2. Of course, I’m always opposed to using a delegate, but instead want to convert it to a property-method-Event mode, so the bottom layer of encapsulation is of course still delegate, and the top layer introduces events whenever possible.
  3. In some cases, ViewController code may need to be extracted into a separate project for validation in order to fully understand. This practice, let me suffer a lot. So you take out the ViewController, and then its sisters-in-law come along, and they’re all coupled. To make it easier for me to do this in the future, I used the message mechanism to break up all of the viewControllers’ coupling to each other, all through a central class, through message send and receive processing into pure star coupling. This is where I put my work. 1000 copy/fin. The code here is based on Finb’s contribution, thanks for sharing. This is code that I want to make easier to read, and easier to break up, divide and conquer.

Swift’s learning continues. I wanted to make a framework for it, with which Swift works as well as C#.