In an event-driven environment, how should a “cancel” function abort all further events?

Question

In my iOS app, things are mostly driven by events.

1. The user presses a button
2. The app listens for an external device to be connected to the iOS device
3. Once the device is detected (is connected), an asynchronous call is made to a web service (to check for user authenticity)
4. The web service returns the user's authenticity (such as a boolean)
5. Another asynchronous web service is called for a stage 2 authenticity
6. Result is returned

My question is: If I give the user a dialog box saying "Please wait, processing" and I give them a "Cancel" button, how should I (or how might I) abort everything that's happening?

One way to do this is to simply have a boolean called "userDidCancelEverything" and every event-driven method checks to see if this is true. This seems ugly though.

Answer 1

How you implement a cancel function will obviously depend on how you implement the events in your app. For example, when the user taps the button the resulting action might add a number of operations to a serial operation queue: the first operation would wait for the device to be connected, the next would call the authentication web service, and so on. If you do it that way, then your cancel button's action would call the operation queue's -cancelAllEvents method to empty the queue and then reset the state related to the operations to a known state. It'd be similar if you use some other scheme -- stop and remove any pending events and then set the app back to a known state.