7

I'm reading through my keyboard's resource documentation (I use MessagEase normally), and I see that they state:

MessagEase Screenshot

Please note the Android does not provide any Undo.

However, I know this isn't actually true — at least, not in any apparent manner — because when using a physical keyboard Ctrl+Z invokes undo just fine, and doesn't require any additional/external applications, i.e., works natively via generic PNP (I've used telnet, BT, and RF varieties, all of which work). And yet, mysteriously enough, the function seems to be omitted intentionally (disclaimer: I have no evidence to support this conjecture).

In fact, MessagEase has extended input functionalities that include form field controls and ASCII character controls, and yet inputting Ctrl+Z results in a notdef glyph output in the exact same form field.

Why is this the case?

EDIT: Please note that I am referring to connecting a physical keyboard to an Android device, I am not comparing PC vs Android UX.

1
  • It is possible to implement it with the TextWatcher interface
    – crazo7924
    Oct 15 at 11:23
6

This question can get better answers from developers than the end user community.

Android framework does have a class named UndoManager "for managing and interacting with the global undo state for a document or application. This class supports both undo and redo...". And Android's EditText view (which extends TextView, and is commonly used in apps to get text input from the user) does support Undo and Redo operations since Android 6 at least. In fact a ROM developer can show these options in long press context menu for every app, as we see Copy, Paste and Select All, which are displayed by default. But Undo / Redo always work if the virtual or physical keyboard can send CTRL-Z and CTRL-SHIFT-Z key events.

I extended CTRL- events support in AnySoftKeyboard for non-terminal apps. So anyone can. Why they don't is purely a matter of choice. There's no technical limitation.

4
  • Note that the UndoManager class as of Android 12 is restricted, per: developer.android.com/about/versions/12/non-sdk-12#new-blocked Also based on: android.googlesource.com/platform/development/+log/refs/heads/… it looks like a feature under consideration and paused/dropped/hidden and developers were expected to use TextWatcher to perhaps roll their own undo/redo operations. Sep 24 at 9:26
  • @MorrisonChang hidden APIs are hidden from apps, not from framework. So the non-SDK restrictions don't apply to EditText/TextView. As of the latest commit, both undo and redo operations are fully handled by these framework classes: android.googlesource.com/platform/frameworks/base/+/…. But even if Google drops the support (which doesn't seem to be the case so far), extending EditText class to handle key events and keeping history won't be a big task. Sep 24 at 10:07
  • I'm not sure which 'developers' you are referring to in your first line vs your last line, 'Android framework developers' or 'third party developers'. I think my point was that the undo/redo functionality in TextView isn't clearly spelled out in the official documentation and only hinted at by the XML property android:allowUndo. The fact that a third-party app developer needs to look at framework source isn't new but less 'a matter of choice' than 'awareness'. Sep 24 at 17:47
  • @MorrisonChang "I think my point was that the undo/redo functionality in TextView isn't clearly spelled out in the official documentation". Yes that's a valid point. And my point is that "Android does not provide any Undo" doesn't sound like a valid excuse for not providing such a small feature. It's a matter of app developer's choice, though nothing bad with that. Sep 25 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.