macOS NStimer, NSThread, or both?

[csmithmaui]

Hello,
I have an Cocoa touch application I am trying to write and I thought that I would use a separate thread for part of it but after reading the Thread Programming Guide and thinking through it I am confused.

My program needs to play a sound and then wait for a user to respond with a certain action(key press or sound). I will make a determination on what to do next based on their response or lack of response. I need to give them a certain amount of time to react(~5sec) before I play the next sound. I will be going through a series of these iterations and then the series will be done.

I am confused by this because my threads in the past never needed to wait for anything except a variable to be set or function to return before they could continue making decisions in sequence.

I can play sounds and add a timer to the runloop to listen for a sound but how to order a whole sequence of play sound-wait for sound to finish-determine user response-play next sound is not clicking for me. It doesn't make sense because when I add a timer to the loop, it immediately would continue to the next instruction. I basically need to block or something until an answer from my method. But when you use a timer you don't return a value to the point where you called the function, right? Anyway, I know that I am missing something fundamental here and I was hoping someone more knowledgeable than myself could help me out.

Thanks for any help!

 

[lee1210]

I won't be much help with the cocoa part of this, but it might assist those who can to state more clearly the task you need to perform. This sequence of events being repeated in a loop should not affect the approach as far as I can tell.
Will you be processing anything in the background while waiting for input? If not, a single thread should be fine. If you need a separate thread for anything it might be accepting audio input, as I don't know how cocoa handles this.

What is the exact sequence of one iteration? From what I can tell, it's:
Play a sound, prompting the user for input.
Read input from the keyboard or audio device.
If no input, or no usable input, is received in N seconds, proceed.

If this is right, it seems like an NSTimer would do the trick. The method fired could just set a flag that your input can check at regular intervals. When input is received, the timer can be killed to prevent it from firing.

-Lee

 

[garethlewis2]

To get you up and running, you shouldn't worry about running an extra thread. You should make a text box, or something that can accept keyboard input an InitialFirstResponder. You will need to override some methods that make the class you have actually behave like an initial first responder and then it will automatically respond when key-presses are invoked.

You can then keep the 5 second timer in NSTimer.

Aaron Hillegrass's book contains a similar style application for teaching people to type. It will display a letter and wait for a small amount of time before displaying the next character, if they type in the correct character, the program moves to the next character, if not, the screen flashes and a beep occurs.

After getting this working, you might decide that a text panel, is ugly and what something slightly more fancy, you might still be able to use the Initial First Responder, but I really don't know, this type of program is not something I am ever likely to write