[TOC]

Also published in the Swift component development specification

Swift component development specification

Recently wrote some thoughts on Swift related components within the company

1. Engineering specifications

1.1 Component Project Creation

Build the project using pod lib create (see appendix for details)

Swift language component development is different from OC version development, the introduction of Module concept, especially the use of ** access rights ** keywords: open > public > internal > filePrivate > private

Use the built-in command to create a project, during the code test, to avoid some improper use of access rights, use problems exposed in advance. For example, the function uses the internal permission, but cannot access the framewoek after it is generated

1.2 Library import

By default, it is necessary to import the library used, which undoubtedly increases a lot of repeated work. In the past, OC component project realized global import by PCH file, while Swift introduced the concept of Module, so PCH cannot be used any more.

The solution

  1. Build the project name-bridge-header. h file
  2. Introduce framewok, such as Bowling for Swift, via #import

Where Bowling is the package name and Bowling- swift. h is automatically generated by framwwork and is located under the Bowling. Framework /Header file

1.3 Unit Test

1.3.1 necessity

Testing is using documentation

For component users, you can read unit tests to see how the functionality is used

Improve productivity

A mechanism for finding bugs early and providing feedback to Dev quickly; Especially a small change, quick verification

Improve code structure design

Unit tests can serve as a design tool that helps developers think about the structure of their code and make it more testable

1.3.2 using

XCTestCase [Unit Testing]

Third-party Framework Quick

1.4 Evolution of Thinking

Design first: Analysis -> Research -> Design -> Architecture -> Split implementation

2. Programming paradigms spanning: Object-oriented programming -> Protocol-oriented (interface) programming

2. Coding specifications

2.1 Naming conventions for class names

Since Swift introduced the concept of Modul, there is no need to add prefix before the class name, it is only used between Swift, if there are conflicts of class name, method name and so on, Modul can be used. Formal access. When OC calls Swift, Swift can modify the symbol name exposed to OC via @objc()

2.2 External Access Rights

Use open > Public > Internal > filePrivate > private correctly

3. Document specifications

3.1 Document directory Structure

  1. Introduction [1.1 Description, 1.2 Features]
  2. Quick introduction [2.1 System Requirements 2.2 Installation (including at least CocoaPods Installation)]
  3. Usage [3.1 Basic Usage 3.2 Advanced Features….]

Acknowledgements (optional, which frameworks to refer to, which code to port, etc.)

3.2 Writing Specifications

  1. Title: numeric label +.(dot) + (space) + title content, e.g. 2. Quick introduction

The appendix

1. The pod lib command is used in detail

For example, to create TestPro components, open a terminal, CD to a specified directory, and run the pod lib create TestPro command

Wait for TestPro Template to be configured

// Automatic execution
Cloning `https://github.com/CocoaPods/pod-template.git` into `TestPro`.
Configuring TestPro template.
Copy the code

What platform do you want to use?? [ iOS / macOS ]

iOS

What language do you want to use?? [ Swift / ObjC ]

Swift

Would you like to include a demo application with your library? [ Yes / No ]

Yes

If you choose Quick Which testing frameworks to develop the functional template, will you use them? [ Quick / None ]

Quick

Yes Would you like to do view based testing? [ Yes / No ]

Yes

The final generated project directory is as follows: