You need to save the user’s work periodically in an interactive program.

Use a background thread.

This code fragment creates a new thread to handle background saves, as in most word processors:

public class AutoSave extends Thread {
    FileSaver model;

    public AutoSave(FileSaver m) {
        super("AutoSave Thread");
        // setDaemon(true);        // so we don't keep the main app alive
        model = m;
    }

    public void run(  ) {
        while (true) {        // entire run method runs forever.
            try {
                sleep(300*1000);
            } catch (InterruptedException e) {
                // do nothing with it
            }
            if (model.wantAutoSave() && model.hasUnsavedChanges(  ))
                model.saveFile(null);
        }
    }

As you can see in the run( ) method, this code sleeps for five minutes (300 seconds), then checks if it should do anything. If the user has turned autosave off or hasn’t made any changes since the last save, there is nothing to do. Otherwise, we call the saveFile( ) method in the main program, which saves the data to the current file. Better would be to save it to a recovery file of some name, as the better word processors do.

What’s not shown is that now the saveFile( ) method must be synchronized, and what’s more, whatever method shuts down the main program must also be synchronized on the same object. It’s easy to see why if you think about how the save method would work if the user clicked on the Save button at the same time that the autosave method called it, or if the user clicked on Exit while the file save method had just opened the file for writing. The “save to recovery file” strategy gets around some of this, but it still needs a great deal of care.