Basic implementation of message drafts, to preserve composing progress

[chrisbobbe]

From beta feedback on CZO:

Tried to report an issue and ended up with an error. Please add drafts as it deleted message content. Only topic tittle survived.

In the legacy apps, if you write some text in the compose-box content input, then exit and re-enter the same message list, the text will appear in the input, so you can pick up composing where you left off. These drafts aren't synced with the server, and there's no UI to browse a list of your drafts to choose from, so you have to remember which message-list view you were looking at while writing it.

This issue is for a similarly basic implementation. For anything more complicated, we'll need a design.

[chrisbobbe]

In this user's case, this part of #720 would have helped:

We'll await the result of the send request. If it succeeds, the send is done and we can proceed just like the send button does now: clear the input and take it back to a ready state. If it fails, we'll show an error message and make the input ready again, but still holding the text the user entered.

because the input wouldn't have been cleared before making the send-message request to the server.

[Dhanesh-Sawant]

Hi @chrisbobbe,

For the basic implementation of drafts, can we use a DraftManager approach with local storage to save and restore drafts? This would save the compose-box content locally (e.g., using in-memory or SharedPreferences) whenever the input changes or the user navigates away, and restore it when re-entering the same message list.

[chrisbobbe]

Please open a discussion in #mobile-team in the Zulip development community, linking to this issue; that's a better venue for a more detailed discussion. 🙂