* add broadcasts ffi
* add 'broadcast' options to menu, chat, profile etc.
* generate initial broadcast names
* reword broadcast hint
* make 'Broadcasts Lists' experimental; while on that, also add a confirmation dialog to the location streaming switch (wording taken from ios)
* Update res/values/strings.xml
Co-authored-by: Hocuri <hocuri@gmx.de>
* comment on strings.xml
* tweak 'experimental' appearing, avoid the 'test tube'-emoji that is not supported on many devices
Co-authored-by: Hocuri <hocuri@gmx.de>
* add download-ffi methods
* add 'Download' button for incomplete messages
* show 'downloading' animation
* make download_limit configurable
* set button to 'disabled' and text to 'Downloading...' on downloading; color does not really reflect that yet, but that can probably be tweaked by xml
* make 'download message body' translatable
The non-squashed original commits are available at 243bd3a56:
* First, quick and dirty version
* Basic HTML connectivity view
* Codestyle, automatically refresh
* Make it accessible from the settings
* Improve usability
I did some user-testing with my family, these are the results:
- Added an emoji to the html page (red dot for not connected, and so on)
- Adapted error messages for SMTP:
"Not started" -> "(You did not try to send a message recently)"
"🟢 Connected" -> "🟢 Your last message was sent successfully"
- "Not connected" is misleading, because they think that this means that there is no internet connection.
But "Not connected" can have other causes, like, a not responding server or a changed-but-not-updated-in-DC password
Possible solutions:
- "Not connected" -> "Not connected with gmx.de" (or whatever comes after the '@' in configured_addr). The problem: some people have an own domain for their emails, but no own servers. "Not connected with <your domain>" and might make them think that the problem is that DC tries to connect to the server <your domain>, while the server is hosted at Strato.com.
- We can ask the system whether there currently is network and then show another error message. The problem: Sometimes the system is wrong.
* Remove error_network
* Remove server_response string
* Move `getConnectivitySummary()` to `DcHelper`
* Implement the changes we agreed on
* Remove string error_no_network
* small fixes
* Remove screen lock feature, move the two remaining "App access" options into "Advanced"
Locking the app was removed a long time ago, so in "App access" in the
settings, the only two remaining items were "Screen security" and
"Incognito keyboard".
* Remove the now-unused strings
* remove app-access-category from main settings screen
Co-authored-by: B. Petersen <r10s@b44t.com>
for various reasons,
screen-lock will be removed completely in one of the next versions.
- if screen-lock was enabled before, add a warning
and keep the options (user can switch screen-lock on and off
until it will be finally removed)
- if screen lock was disabled before,
hide the corresponding options,
(the user will not be able to enable screen-lock anymore)
reasons for removing are:
- hard maintainability on different android versions, see discussions at
https://github.com/deltachat/deltachat-android/issues/1208 and
https://github.com/deltachat/deltachat-android/pull/1279 and
https://github.com/deltachat/deltachat-android/pull/1319 and offline.
ftr, also the used api createConfirmDeviceCredentialIntent() is deprectated,
so another set of api calls would be needed in the soon future.
- compared to the effort, few security is added,
the function is only available if the system is protected anyway,
one just have to repeat the system secret.
- might even worsen overall security - if app login secret is peeked,
and attacker will also have the system secret.
- the functions stands in the way of moving forward to a
cross-platform solution (however, not sure if this will really come)
- For chat menu item, use already translated auto-delete string.
- For experimental setting, use untranslatable hard-coded string.
- Introduce a new translatable string for ephemeral dialog title
reason is that ppl are pretty annoyed by the
permanant notification, that might have been expected and that would be okay.
but, more worse, for whatever reasons, this drains more battery on some systems
than having just "allow consuming battery" enabled,
maybe some system do not go to doze mode because of the permantent-notification.
anyway, to avoid initial annoyances, we switch back to
- asking the user to "allow consuming battery"
- having a 15 mintues or so polling interval (as on iOS)
but, in contrast to 1.3, we now still have the _option_ to
enable a permantent-notification that user can enabled if everything else
described at https://dontkillmyapp.com does not work.
the "smart" permantent notification from 1.3,
that are only shown under some circumstances, however, are gone.
they are not realiable, eg. we did not use them when "consume battery"
was enabled - which is not sufficient on various "modern" systems.
but the main reason is that _if_ the user enables a permantent notification,
this can also be regarded as a hint that things are up and running.
right-aligned settings look a bit odd on newer android versions,
the default is a second row with the value.
also, the led is subject to change
as it probably won't be directly editable in the notification channels -
so, do not continue to maintain an explicit class for that.
Hocuri