Undo and Redo
To achieve this, we’ve created an interface named
UndoManager. The implementation of this interface is provided through the
PdfFragment#getUndoManager() method. The
UndoManager provides methods for controlling the undo/redo business logic, including:
undo()— undo the last performed edit
redo()— redo the last undone edit
canUndo()— whether or not the undo action can be executed
canRedo()— whether or not the redo action can be executed
Undo and redo operations are enabled by default. However, you can use
redoEnabled(boolean) when building a
PdfConfiguration to control whether or not undo and redo are enabled or disabled in your app. Logically, redo cannot be enabled if undo is disabled.
To listen for undo and redo changes, you can attach
OnUndoHistoryChangeListener to the
addOnUndoHistoryChangeListener(). The callback will notify you once the undo history changes so that you can update the UI or components that need to be aware of the undo/redo state.
The entire implementation is still kept internally within the framework, meaning developers can’t access the data regarding each specific edit, nor can they create their own. More and more things will be exposed in upcoming versions.
The undo history state restoration works by restoring the instance of the fragment rather than serializing it. This means that if you destroy the fragment when the configuration changes, you will lose the history.
Currently, undo/redo history is only tracked for annotations.