|
It looks like there is a misconception on the meaning of suspend().
Let me start by saying that Breeze applications should be coded to be asynchronous. Threads are a precious resource and if they are blocked too long they can quickly become exhausted. The result is code that is slightly more complex but much more scalable.
In your case, any code that should be executed only after a media operation completes should be invoked from a MediaListener class. Your code might do something like the following.
- In callIntercepted
- Create an instance of a class called something like PromptAndCollectListener
- Store a reference to the Call object in this listener
- Store any other relevant state in this listener
- Pass your listener to the promptAndCollect operation along with other relevant parameters
- optionally invoke suspend() (see below for more information on this)
- The promptAndCollect operation will now execute. As soon as the relevant messages are sent to the media server, the container thread is freed up to handle other calls.
- Eventually, your PromptAndCollectListener will be invoked.
- In the digitsCollected callback, you will have code to operate based on the user's input.
- Create an instance of a class called something like PlayListener
- Store a reference to the Call object in this listener
- Store any other relevant state in this listener
- Pass your listener to the play operation along with other relevant parameters
- The play operation will now execute. Again, the container thread will be freed up as soon as relevant messages are sent to the media server.
- Eventually, your PlayListener will be invoked.
- In the playCompleted callback, you would then invoke the record() operation.
If you have multiple play or prompt and collect operations, you'd probably want to have multiple implementations of MediaListener to handle the appropriate logic for each of those operation instances. Does that all make sense?
Now, back to the meaning of suspend(). The default action after all of the application code executes in callIntercepted is to allow the call to proceed. The thinking here is that the platform should "do no harm". Unless explicitly directed otherwise, we're going to let this call go on to its intended recipient (assume it's a call intercept snap-in rather than a callable snap-in). suspend() allows the snap-in writer to override this behavior. It tells the platform "I'm not ready to let this call proceed yet, I'll be back to you very soon". It turns out that invoking a media operation automatically invokes suspend() under the covers. That means that suspend() would only need to be invoked in a small subset of cases.
|
