Ok, I’m back onto presentation patterns work this morning and I’m drafting out my chapter on “Graceful Shutdown.”  I don’t have the Fowleresque one line pithy description down yet, but let’s try “gives the user and background services a chance to clean up remaining work before a screen or the entire application itself is closed.”

Think about your IDE tool of choice.  You’ve probably got one open right now.  If you make some code changes in a couple class files then accidentally trigger off the exit application command, what happens?  Hopefully your IDE throws up a dialog that says “Unsaved changes,” tells you what code files have those unsaved changes, and gives you the user a choice to either save those files before closing or cancel the application shutdown to allow you to continue working.  It’s an obvious technique for creating a user experience that doesn’t suck.  Now, it’s our turn and we need to build this into our systems to keep users from forming a mob and hunting us down because the big whiners accidentally lost hours of work.

What are the Challenges?

1. Intercepting the screen closing and window closing events.  All the UI technologies that I’m aware of expose some sort of “Closing” event on windows, screens, or tab items that allow you to cancel the closing.  One way or another you need to intercept this event, but if the “can the screen/application close” logic is any way, shape, or form complicated, I want to move that logic to a non view code element that is easy to put under a test harness.
2. What elements of the application have outstanding work or need a chance to gracefully clean up after themselves before pulling the plug on the application?  This is a piece of cake in a one screen application but much more difficult in applications that show and hide various screens through the lifecycle of the application. 
1. Avoiding the need to hard code the communication between the closing event handler and the elements of the application that need to take part in shutting down the application. 
2. How do you locate these elements or maybe how do these elements register themselves as being interested in shutdown?  This is a piece of cake in an application that has a static configuration of screens or services and rarely changes, but what about systems that need to be extensible or applications that create, show, hide, and teardown screens quite frequently? 
3. Registering the listeners of the “can close / perform shutdown” message in a way that does not lead to memory leaks from dangling event references
4. Registering the listeners of the “can close / perform shutdown” message in a way that doesn’t create a lot of repetitive busy work for developers
5. Finding a way to communicate
3. Giving the user usable feedback about what is happening.  The simplest thing to do is just to say “You have unsaved work” in a dialog box, but what if your users need more contextual information than that?  How about a message that reflects exactly what is outstanding?  That leads to a different pattern and a little more complexity than just asking if anyone in the system is busy.

Anything else?  I will follow up with links to actual content tonight.  If there is anything *you* want to see or something that is bothering you or something you did that you like, comments are very welcome.

Quick Note

I’m getting some criticism about my book from folks that are more interested in User Interface Design (look and feel) and folks primarily interested in user experience.  It’s really this simple, the book just isn’t about those topics.  I’m strictly concerned with the underpinnings of a user interface behind the scenes.  Right now, that topic isn’t well understood or documented and I’ve got a niche to fill.  You, Mr. Designer, make the best possible vision for how the UI is going to look, behave, feel, and flow and I’ll worry about how to make your vision possible, testable, and maintainable.  It simply takes more than one skillset to make an app.