Graceful Shutdown Braindump

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.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • David Martin

    The day you posted this my team and I spent a good amount of time trying to answer this exact question. However, for us it may be more difficult. Our users will be in the middle of a process several “layers” deep when they attempt a logout/shutdown.

    The problem we come across is this (simplified): At the lowest (and current) level we feel we may need to ask the user what to do as in “Save”, “Don’t Save”, & “Cancel”. No problem so far, but the next level up may also have a similar question.

    I say “we feel” because we’re doing the wrong thing and trying to anticipate the requirements. But if we were to be required to implement something like this I fear that from a usability standpoint it would suck – User clicks Logout. User is asked to confirm/answer a question. User is asked again to confirm/answer a different question. On up the tree.

    Are you even attempting to tackle more complex scenarios? Looking forward to the book.

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @David,

    Yep, yep, yep. I’ve been thinking about showing more complex scenarios where you want to give the user more fine grained control.

    Needs more though.

  • http://www.commongenius.com David Nelson

    There is also the question of whether to ask the user to save each individual “document” (i.e. Office-style) or just ask once for all documents (i.e. VS/SSMS-style). I tend to prefer Office-style, because I may want to save some but not others, or I may not remember what changes are in all of the documents and I need to see them before I know whether or not to save. In Visual Studio I usually end up canceling the close and dealing with each document individual, whereas in Office I can just deal with each document as it comes up in the shutdown process. However, on the rare occasions where there are a lot of open modified documents during shutdown, dealing with them individually can be a pain.

  • http://stormbase.net Andy

    Jeremy, as Jeff said, ignore the critics…(or at least respond in a good fashion like you did). I am also looking forward to getting hold of your book. keep up the good work :)

  • http://www.agilification.com Jeff Doolittle

    Jeremy,

    Don’t listen to the critics. You are on a great track and I for one am looking forward to the result.

  • Pat

    Jeremy,

    There is also a problem with web browsers. Trapping browser close events in different browsers itself is somewhat difficult. Any thoughts on how to handle that?

  • http://www.chrisholmesonline.com Chris

    @Andy,

    If you can’t detect it then there’s not much you can do that will be “graceful”. There may be “not-so-graceful” ways to handle shutdowns. What technology are you using?

  • http://codebetter.com/members/jmiller/default.aspx Jeremy D. Miller

    @DM,

    That’s a good point. Chad & I tried to convince our last boss to let us do that when we had an extremely input centric app. Even still though, you might need to be pausing the shutdown to let the outstanding “saves” go through before killing the AppDomain.

  • Andy Herrman

    Man I wish the tech I use (sadly ones I cannot change) provided a “Closing” event that could be handled. Trying to set up a graceful shutdown when you don’t know anything about shutdowns occurring is a pain.

    Fortunately in my case the implications of an unexpected shutdown is rather minor, but in some cases it could be major. Any suggestions for those kinds of situations? How to try and make a shutdown graceful even if you don’t know when it will happen and can’t actually detect it?

  • DM

    You might want to mention the (OneNote) approach of not even having a save button. Everything is saved automatically, close the app with no concern, etc.