Alternate solution to the problem. Following is my discussion with the support.
>> If we stored undo information for the current page only, it wouldn't be possible to undo something on a previous page even after we scroll to it.
You could maintain an undo queue/stacks for each page that the user has done modifications on, in that edit session. You don't have to maintain undo queues for all the pages in the document. You need to maintain the queues only for the pages that the user has modified so far, from opening of the Goodnotes app and opening the document.
When the user scrolls to the previous page, bring up that page's undo list, which will be separate from the next page.
>>However, I can imagine how the current behavior can still work in the user's advantage in case they need to be able to undo something on a previous page.
Why would a user want to undo things on the previous page while staying on the current page? Naturally they would navigate to the previous page and then do undo/redo operations that they certainly will prefer to be happening in front of their eyes.
If you are concerned about previous page's undo operations, you can maintain in separate list for that page as explained in previous point.
Same discussion also applies to "redo" operations.
Alternate solution to the problem. Following is my discussion with the support.
>> If we stored undo information for the current page only, it wouldn't be possible to undo something on a previous page even after we scroll to it.
You could maintain an undo queue/stacks for each page that the user has done modifications on, in that edit session. You don't have to maintain undo queues for all the pages in the document. You need to maintain the queues only for the pages that the user has modified so far, from opening of the Goodnotes app and opening the document.
When the user scrolls to the previous page, bring up that page's undo list, which will be separate from the next page.
>>However, I can imagine how the current behavior can still work in the user's advantage in case they need to be able to undo something on a previous page.
Why would a user want to undo things on the previous page while staying on the current page? Naturally they would navigate to the previous page and then do undo/redo operations that they certainly will prefer to be happening in front of their eyes.
If you are concerned about previous page's undo operations, you can maintain in separate list for that page as explained in previous point.
Same discussion also applies to "redo" operations.