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>
Using both `setMessage()` and `setView()` on the same AlertDialog,
on small screens the "OK" and "Cancel" buttons were not be show. So, put the
message into our custom view.
fix maybe #1748. Maybe not, because actually I don't understand why
issue #1748 even happened because we don't use the system background for
the bubble but an own one (see conversation_item_sent.xml:50). Probably
the system is somehow trying to forcefully create a dark mode.
So, let's see whether this PR fixes the issue, if not, I'll try again.
I can't tell if it helps, I personally was able to both play a 60min
audio and to play 32 voice messages after each other. Shouldn't hurt to
release them, though.
I tested my change, and at least it seems not to worsen anything.
Seems like in the first commit I was not careful enough: The color was
set to red, but then the view was reused in a RecyclerView and the color
stayed red. Therefore, after scrolling, more and more of the status icons got
red.
IIRC some time ago we talked about making the error icon red and make it
an exclamation mark to make it more visible.
Today someone complained to me that they thought the "x" looks like one
can close something and that it shouldn't be green, so I went ahead and
made it red :) (it's also a little bit bigger now)
- the image file is a vector (xml) file now, previously it was a png file.
Might this be a problem?
the color 'universal_overlay' can be used as backgrounds for
semi-transparent overlays.
the color guarantees enough contrast to white/light things drawn on it,
while still letting the background shine through.
the color is the same for both, dark and lite theme
as it is also used to draw on customized backgrounds
(where we can have any background anyway)
before, the shaped formed with this color are not visible
on black background, this is fixed by this commit,
making the color even more universal.
this is an improvement for the image-editor buttons
as well as for the info-messages on arbitrary backgrounds.
B. Petersen