IOS prevents UIButton consecutive clicks causing multiple requests for problems!

In the project, many logic requests need to use the UIButton to do the click event to carry on the related jump or the data request and so on. Can be said to be the most commonly used in the project of a control, but some details of the processing or we should pay more attention to, for example, we say today the continuous click UIButton caused the data request many times the problem, perhaps this problem online has a lot of relevant information, after all, this is not difficult. It's just a few methods, the first way is by using runtime, Set UIButton0.5 seconds will not be repeated clicks, the second is to cancel each click before the operation, the third is set to not be clicked after the state, through the UIButton enabled properties to set.

In my opinion, I prefer the second approach because it does not affect a fluent problem of interface interaction, but in some cases it needs a third way to implement it. As for the first method, it may sound high-end atmospheric grade, but I say "hehe", pure is fraught. If we do a Web request by clicking on a UIButton click event, can you guarantee that you will be able to receive the return results of the network request within runtime time? If it is bad in the network situation, it is likely to cause your request is sent n times, and then finally get to n results, if you are through Addobjectsfromarray and other methods to add data, it is likely to lead to the problem of adding data duplication.

There is also a situation where I create a websocket link, and then need to click on the UIButton to switch to the server to send different data requests, if I use the first method will lead to repeatedly send data requests to the server, and then receive more than n the same data, If the data is more, it will cause the cotton phenomenon directly when you do the UI refresh. Although the middle may interval the runtime time which you set, but still cannot avoid. As for the third approach, which avoids this problem, it can lead to the problem of switching UI interfaces, because you have to wait until you receive the results returned by the server before you can click on a different UIButton to switch the interface. In this case we need to use the second method.

But in some cases, if I have to wait for the return result of the server to respond to an event, I have to use a third method, and if you use the second method, you will always be stuck in a loop when you click the UIButton event continuously until your finger leaves the screen to respond. Will undoubtedly increase the client CPU service pressure.

As for when to use runtime to solve the problems caused by UIButton continuous clicks, I suggest that we use caution. Don't be misled by repetitive blogs and articles. After all, is the best for their own!