when we need to wait for an asynchronous result to execute the code down, write the callback is cumbersome, the function is relatively simple, you can insert the following red part of the code.
-(Ibaction) Start: (ID) sender
{
pagestillloading = YES;
[Nsthread detachnewthreadselector: @selector (loadpageinbackground:) totarget:self Withobject:nil];
[Progress Sethidden:no];
while (pagestillloading) {
[Nsrunloop Currentrunloop] Runmode:nsdefaultrunloopmode beforedate:[nsdate Distantfuture]];
}
[Progress Sethidden:yes];
}
whenThe Loadpageinbackground method is finished before letting Pagestillloading=no hide the progress bar.
Why is that? See the following principle:
1. What is Nsrunloop?
We will often see this code:
-(Ibaction) Start: (ID) sender
{
pagestillloading = YES;
[Nsthread detachnewthreadselector: @selector (loadpageinbackground:) totarget:self Withobject:nil];
[Progress Sethidden:no];
while (pagestillloading) {
[Nsrunloop Currentrunloop] Runmode:nsdefaultrunloopmode beforedate:[nsdate Distantfuture]];
}
[Progress Sethidden:yes];
}
This code is magical, because he will "pause" the code to run, and the program will not be affected because there is a while loop. After [progress Sethidden:no] execution, the entire function would like to pause the same in the loop, and so on loadpageinbackground inside the operation has been completed before let [Progress Sethidden:yes] run. This is an introduction, and the logic is clear. If you don't, you'll need to call [progress Sethidden:yes] in the loadpageinbackground where the load is done, and it looks like the code is not compact and error prone.
So what exactly is Nsrunloop? In fact, the essence of Nsrunloop is a processing mode of message mechanism. If you have a certain understanding of VC + + programming, in Windows, there is a series of very important functions sendmessage,postmessage,getmessage, these are the APIs for message delivery processing. But when you go into the programming world of cocoa, I don't know if you're too fast and too hasty to overlook this very important issue, cocoa doesn't mention any API for message processing, and developers never have to care about the message delivery process, as if everything was natural, As natural as nature? In cocoa you no longer have to define a macro such as wm_commad_xxx to identify a message, nor do you have to deal with specific messages in switch-case. Is there no message mechanism in cocoa? The answer is no, but Apple has adopted a more sophisticated pattern in designing message processing, which is runloop.
2. How Nsrunloop Works
Let's take a look at the specific working principle of nsrunloop, first of all the official documents provided by the statement, look at the picture:
All the "messages" are added to the Nsrunloop, where the messages are divided into "input source" and "Timer source" and check in the loop if there is an event that needs to happen, and then call the corresponding function if necessary. For a clearer explanation, we will compare VC + + and iOS message processing.
VC + + After all initialization is complete, the program begins to cycle (the code is intercepted from the slides of the MFC programming course for the user Sir):
int Apientry WinMain (hinstance hinstance,hinstance hprevinstance,lpstr lpcmdline,int ncmdshow) {
...
while (GetMessage (&msg, NULL, 0, 0)) {
if (! TranslateAccelerator (Msg.hwnd, hacceltable, &msg)) {
TranslateMessage (&MSG);
DispatchMessage (&MSG);
}
}
}
You can see that the message is distributed after GetMessage, and the main function in iOS just calls Uiapplicationmain, so we can mind guessing that uiapplicationmain will enter a situation after initialization is complete:
int Uiapplicationmain (...) {
...
while (running) {
[Nsrunloop Currentrunloop] Runmode:nsdefaultrunloopmode beforedate:[nsdate Distantfuture]];
}
...
}
So in the Uiapplicationmain is also in constant processing Runloop is the program did not quit. I said just now. Nsrunloop is a more sophisticated message processing mode, he is clever in the message processing process is better abstracted and encapsulated, so that you do not have to deal with some very trivial and low-level specific message processing, in Nsrunloop each message is packaged in the input source, or timer source, invokes the handler of the corresponding object contained in it when it needs to be processed. So for the outside developer, what you feel is to add Source/timer to the Runloop and then, when appropriate, something like [Receiver action] happens. Even when you don't feel the first half of the process, you just feel a function call to one of your objects. For example, when UIView is touched, it is called with touchesbegan/touchesmoved and so on, and you might think, "Damn, I don't know where I was told there was a touch message, and these handlers were called!" "So, the message is there, just Runloop has helped you do it!" To prove my point, I intercepted a call stack of debug Touchesbegan, with a picture of the truth:
Now I would like to take a look at the example of the "Pause" code, do you have a more in-depth understanding of it?
IOS wait condition met and then down execution but not master card thread Nsrunloop