1

Suppose this is a mathematical application that manipulates waveforms. User opens a waveform file, and edits it.

Now user amplifies waveform using the application toolbox. Amplification may take a long time. Then they undo it. And then they redo it again.

For redo, how should the application behave?

  1. Replace result of amplification that was performed before and was held in memory internally by the application.
  2. Re-run the time-consuming amplification procedure again?

This problem expands to every functionality.

Thanks :-)

Ali Tavakol
  • 405
  • 3
  • 11
  • 1
    I would suggest to dig `CQRS` / `CQS` (many similar names) stuff. It is style when you separated your `commands` from `events`. If you design application wisely as per `CQRS`, `undo` / `redo` becomes trivial tasks. – muradm Dec 16 '18 at 08:05
  • Do you really think undo followed by immediate redo is a common enough scenario to make it worthwhile thinking about this? Seems like a case of premature optimisation for a non-realistic use case. That said, it comes down to a memory/processing time trade-off. You could code the application in a way that the result is kept but if the operating system indicates the system is under memory pressure then the result is discarded (and redoing requires recalculation) – eddiewould Dec 16 '18 at 08:07
  • How much memory is consumed by a waveform (typically)? – eddiewould Dec 16 '18 at 08:11
  • @eddiewould I process waveforms using memory-mapped files. It is on acted upon directly on disk, I think. Size is not known. – Ali Tavakol Dec 16 '18 at 08:21

1 Answers1

2

Undo-redo actions are typically implemented using a stack of commands and the position of the last executed command. After an undo, you move that position one step backward without removing the last command of the stack (now one past the last executed command).

Whether you store data along with your commands is up to you. However, in the situation you describe, for the undo to work, you need to either reverse the last command perfectly (and you may not be able to), or keep the previous state in memory. So keeping the next state, after the amplification, should not cost you anything in this particular case. However, you do need to properly discard it if the user does not redo that command.

As @eddiewould pointed out in a comment, a command can be inherently destructive (so unreversible) and allowing to undo it (by keeping the previous state) can be unfeasable, for example because of memory restrictions. In such a case, you should inform the user beforehand that going back will be impossible.

Nelfeal
  • 12,593
  • 1
  • 20
  • 39
  • 1
    It's worthwhile noting that sometimes 'undo' is contextually disabled (for the reason that @Nelfeal mentioned) - if the original operation was destructive and keeping around the previous state would consume too much memory. – eddiewould Dec 16 '18 at 08:15