add a static boolean doReinitializeDraft that is set to true in onPause() if this activity was started using startActivityForResult(). in onResume(), do if(doReinitializeDraft) { initializeDraft(); }.
Some people reported that drafts were disappearing, and I found a way to
reproduce it (my interpretation in brackets):
- Open Saved Messages chat, could be any other chat too
- Go to another app and share to DC
- In DC select Saved Messages
- (as sharing is done using startActivityForResult(), a second
ConversationActivity is created without affecting the existing one)
- Leave DC. (The second ConversationActivity will correctly save its
draft to the db)
- Open DC again from the "Recent apps". (The first ConversationActivity
will be loaded. It will not know that there is a newer draft and still
show the old draft, or nothing if there was none. When it's closed, it
will overwrite the draft)
I came to this conclusion by logging all writes to the draft in the db.
Also, when I set `REQUEST_RELAY` to -1 (`startActivityForResult(intent,
-1) will behave the same as `startActivity(intent)`) (but that's not a
solution, sometimes we need startActivityForResult(), see e.g.
https://github.com/deltachat/deltachat-android/pull/1412)
What's still a little weird: I tried replacing all calls to
`startActivityForResult(-intent for ConversationActivity-)` with
startActivity(), and the issue didn't go away. Apparently it's only
enough if all calls are replaced, which is the same as setting
`REQUEST_RELAY` to -1. Maybe it's enough if one activity in the call
chain is called using startActivityForResult().
The call to `initializeDraft()` makes the activity start & resume 2-3ms
slower, which is probably acceptable.
While going back and forth with activities & sharing, I also encountered
some more bugs (without trying to reproduce them), but they are not too
annoying (as opposed to losing your draft) and I'm hesitant to changing
the activity-switching logic too much as it is so easy to just break
things again.
While 4 weeks always fits in a month,
5 weeks (35 days) always covers at least a month,
so it can be used in a situation where messages are required to
be stored for a month.
* add get-mime-original apis
* remove unused control
* add 'Show full message' buttons
* split reusable WebViewActivity from LocalHelpActivity
* add FullMsgActivity
* load html via AsyncTask
* adapt to changed api
* handle mailto:-links in WebView
* block loading remote images by default, add user setting always/once/never
* do not hide 'Once' button in always-mode, playing around a day with hidden 'Once' that looks more like a bug :)
* wording: as 'Always' affects all messages, it is better to speak of multiple senders
* wording: use 'Load remote images'
this makes it easier for the user to find the option
if one sees, images are missing in the document.
* wording: shorten text.
* wording: change 'may' to 'can'. 'may' sounds a bit as if someone allows this.
* Don't use AsyncTask
* check 'once' if appropriate
* use lite-colored checkbox-emoji in dark-theme
* add comment about missing error logging
Co-authored-by: Hocuri <hocuri@gmx.de>
adbenitez