Introduction to Access Control permission control in Swift

  • 2020-05-09 19:23:18
  • OfStack

If you haven't touched permission control before, let's listen to a short story:

Xiao Ming is a freshman in wudaokou institute of technology. Recently, he was a little upset because his roommate often used his hot water bottle as if it were one of his own. However, due to the affection of his classmates, he was embarrassed to say so. Until one day, he and senior small K joke.

In college collective life, most things are Shared with roommates by default. If you don't want others to take it, I can seal it for you. As long as you put the private mark on it, they will not see your things, let alone use your things.

Xiao Ming said, "wow! You know how to do magic!"

Support for permission control (Access Control) has been added to the Swift language since version 5 of Xcode 6 beta. In fact, the permission control and xiaoming's article 1, you can set the kettle is only oneself can use, or only the people in the dormitory can use, or the whole school can use.

From now on, like SHIELD director 1, you can fully control the "confidentiality level" of your own code blocks, which can only be referenced in this file, which can be used in the whole project, and you can also play a big love spirit and open source it into API, which can be used by everyone as long as you import your framework.
The three permissions are:

# # # # # private private

Use it where you write it. Whether a class, variable, constant, or function is marked private, it can only be used in the source file where it is defined, not in any other file.

# # # # # internal internal

Code blocks marked internal are accessible throughout the application (App bundle) or within the framework (framework).

# # # # # public and open

Block 1, marked public, is used to set up API, which is the most open permission available to anyone who imports the module.

If you want to add a term to all the love, oh no, you want to mark all the code blocks with permission. Thankfully, the default permissions for all code entities in swift are the most commonly used, internal. So when you're developing your own App, you probably don't have to worry about permission control at all.

But when you need to write a public API, the code block inside must be marked "invisible to it" with public, or no one else can use it.

Private (private level) has the strictest permissions and can be used to hide the details of how certain functions are implemented. By structuring your code properly, you can safely use extension and advanced features without exposing them to other files in your project.

In addition to the ability to assign permissions to an entire declaration, Swift also allows you to make certain attributes (property) more open than assignment permissions when you need them.

For example:


public class ListItem {     // ListItem This class has two properties that are exposed
    public var text: String
    public var isComplete: Bool     // The following code represents a variable UUID Is set to private , on the whole app Readable, but values can only be written in this file
    private(set) var UUID: NSUUID     public init(text: String, completed: Bool, UUID: NSUUID) {
        self.text = text
        self.isComplete = completed
        self.UUID = UUID
    }     // This section has no special tag permissions, so it is the default internal Level. Available within framework goals, but not for other goals
    func refreshIdentity() {
        self.UUID = NSUUID()
    }     public override func isEqual(object: AnyObject?) -> Bool {
        if let item = object as? ListItem {
            return self.UUID == item.UUID
        }
        return false
        }
    }

When we use the Objective-C and Swift hybrid development, we need to pay attention to:

● if you are writing an application, Xcode will generate a header file to ensure the accessibility of both, and this generated header file will contain declarations at the public and internal levels.
● if your final product is an Swift framework, only declarations marked as public will appear in the header. (because the header file of the framework is part 1 of the public Objective-C interface, only part public is available to Objective-C.)

While Swift does not recommend spreading and using a third party framework, it does support creating and sharing frameworks in the form of source files. For developers who need to write frameworks for ease of application and multiple projects, remember to mark API as public level.

If you want to learn more about access control, you can check out apple's latest The Swift Language and Using Swift with Cocoa and Objective-C official guide,
These two guides can be downloaded and updated in iBooks.


Related articles: