IOS development-Explanation of Singleton mode and ios development

IOS development-Explanation of Singleton mode and ios development

Nowadays, there are a lot of people writing Singleton mode on the Internet. There are a lot of basic things, but there are also a lot of versions. It is inevitable that new people will feel a little dazzled. I am not busy with the latest version. I also want to write my own experiences.

Before looking down, we need to understand that we need to use the singleton mode under what circumstances? The Singleton mode is generally used when a class can only have one instance, or when only one class needs to be defined, it is also best to define it as a singleton when it is used repeatedly. (For example, it is very appropriate to use the singleton mode to control tools such as video players and audio players)

Before creating a Singleton, we also need to know that we are creating a singleton. What is our ultimate goal?

Purpose of Singleton mode:

1. encapsulate a shared resource

2. Provide a fixed instance Creation Method

3. provides a standard instance access interface

 

Now, let's get started. To standardize the process, we need to know the specific steps for creating a singleton?

To create a singleton class in iOS, three steps are required.

1. Create a static instance for the Singleton we want to create, initialize it, and set it to nil;

2. In the following instance constructor, check whether the static Instance declared in step 1 is nil. If it is true, create a new instance and return the instance of this instance;

3. Reload all methods involving allocation, and reload allocWithZone, copyWithZone, release, and autorelease, in this way, even if you use the alloc and init methods to create the class elsewhere, no new instance will be generated;

 

Creation of Singleton Mode

Assume that the singleton mode of creating a PlayViewController is used as an example:

1First, create a static instance

1StaticPlayViewController * PlayManager = nil;

 

2And then add a class method for it.

1StaticPlayViewController * PlayManager = nil;

2 + (PlayViewController *) defaultManager {

3 @ synchronized (self ){

4If(PlayManager = nil ){

5 [[selfClass] Alloc] init];

6}

7}

8ReturnPlayManager;

9}

Summary:

A. the keyword @ synchronized is used to ensure the thread-level security of our single instance. It can be used in multithreading mode.

B. static variable PlayManager is used to store the pointer of a Singleton, and forces all accesses to this variable to use class method + (id) defaultManager, in pair + (id) defaultManager creates an instance when it is called for the first time.

C. The above Code uses [[self class] alloc] instead of [PlayViewController alloc]. In general, these two statements produce the same effect, however, this is done here to make better use of the Nature of OOP. [self class] can dynamically find and determine the type of the class to facilitate subclass of the class.

 

3The created Singleton cannot be a singleton in the true sense, because it does not have the Singleton, therefore, we also need to use some methods to avoid repeated creation of a single instance. That is to say, when you create an object using the alloc method instead of using the + (id) defaultManager, an object instance is generated, this conflicts with the idea that we only wanted to create a singleton. What should we do?

We can see that in method + (PlayViewController *) defaultManager, the creation and access of a single instance are only solved, however, the Code in other places cannot be restricted to use the alloc method to create more instances. Therefore, we need to reload all methods that involve allocation. These methods include + (id) alloc, + (id) allocWithZone, and-(id) copyWithZone.

1 + (id) alloc

2 {

3 @ synchronized (self ){

4If(PlayManager = nil ){

5 PlayManager = [super alloc];

6}

7ReturnPlayManager;

8}

9}

 

1 + (id) allocWithZone :( NSZone *) zone

2 {

3 @ synchronized (self ){

4If(PlayManager = nil ){

5 PlayManager = [super allocWithZone: zone];

6}

7 return PlayManager;

8}

9}

 

1-(id) copyWithZone :( NSZone *) zone

2 {

3ReturnSelf;

4}

Summary:

In many cases, we find that the allocWithZone method is not overloaded in some Singleton instances, but the allocWithZone method is simply overloaded. Why?

The overload of allocWithZone is a comprehensive method. When using the alloc method, the alloc method itself calls the allocWithZone method. AllocWithZone does not call the alloc method.

Therefore, you do not need to rewrite alloc in many cases. You can simply rewrite allocWithZone. (That is, you only need to define an allocWithZone)

 

The above code can only be used correctly in ARC. If MRC contains retain, copy, release, and autorelease, these methods will change the reference count, we all need to override these methods.

1-(id) retain

2 {

3ReturnSelf;

4} 

 

1-(id) copy

2 {

3ReturnSelf;

4}

 

 

1-(oneway void) release

2 {

3

4}

 

1-(id) autorelease

2 {

3 return self;

4}

 

1-(NSUInteger) retainCount

2 {

3 return 1;

4}

 

1-(id) init

2 {

3 @ synchronized (self ){

4 [super init]; // usually put some variables to be initialized.

5 return self;

6}

7}

Now, the creation of a singleton is complete.

Thank you for reading this article. If you find anything inappropriate, please leave a message to point out the problem !!!