* streamline menu
- remove prefix 'Show', we are not using it at most other places,
nor do comparable UI
- move 'All Locations' below 'All Media',
this seems to be more logical
(we were even thinking of making 'Locations' a tap in 'Media')
* add missing plural form for 'Location' (needed for iOS map experiments, maybe also the better title for the in-chat-maps in general)
* update changelog for 1.36, core part
* update changelog for 1.36, android part
* bump version to 1.36
* add device message for 1.36
* qualify 'Add Second Device' as experimental also in device message
* apply recent suggestions to CHANGELOG
we already had a confirmation dialog for probably most security-aware users
always when the device is protected by a screen lock.
this commits adds a more on-point text -
and shows the same text in a simple alert in case a device has no screen lock.
ppl try already now to set up a second device from the welcome screen.
however, end up in logging into their email account again,
creating issues with keys and more.
a dedicated "Add as Second Devies" button targets this UX issue
by offering a clear path for setting up a second device.
moreover, the string "Scan Invitation Code" is used again (as on all releases),
this string is used quite a bit in different handouts,
changing that would worsen UX as well.
the "Restore from Backup is moved down,
if you really use this path, finding the button is the smallest issue.
the different layout of the button makes clear,
that this is not the preferred way to set up a new account
(but sure, to restore a backup :)
* add DcBackupProvider add receiveBackup() wrappers
* add 'Add Another Device' item to settings
* add android-ifaddrs
core-rust uses getifaddrs() which is not available on android ndk.
pull in the code from https://github.com/morristech/android-ifaddrs
that provides an implementation.
* add BackupProviderActivity
* make SVG-hack reusable
* add BackupProviderFragment
* prepare scanning backup codes
* Revert "add android-ifaddrs"
This reverts commit 33b1424427620396f282805d37f8e05c67758546.
* more logging
* call receiveBackup() on scanning DC_QR_BACKUP
* Fixup for recvmmsg fallback
* protect BackupProviderActivity by system secret
* show transfer progress as provided form the core; hide qr-code once scanned
* add a permanent notification for the provider
* clarify what we are waiting for
* add a permanent notification for the receiver
* ask before finishing BackupProviderActivity
* it is fine to cancel the abort question by tapping outside the alert
* remove outdated comment from 'keep screen on'
* add and check TRANSFER_MODE
* rename BackupProviderActivity to BackupTransferActivity
* use our base activity
* start/stop IO in base activity
* use BackupTransferActivity also for scanning
* add BackupReceiverFragment
* show detailed transfer progress
* show details instead of percent during preparation, for now
* launch chatlist and remove welcome when transfer is done
* redirect to chatlist automatically after transfer succeeded
* reword
* make log accessible from send and receive activities
* bump version
* show error if backup provider creation fails
* remove unneeded format()
* show some context in the errors alerts, hide QR code sooner
* calculate transfer percentage as specified
* show a 'close' instead of a 'back' button to make visually clear, things are aborted (there is a quesion anyway)
* add option to copy backup-qr-code to clipboard
* remove vague retry statement, core will show a detailed error soon
* warn about QR codes on clipboard getting invalidated
* make basic strings translatable
* add troubleshooting menu item (once help is evolved, it may be a more visible button, may be localized, may be offline)
* rename to backup_transfer_fragment.xml
* add detailed instructions
* move 1,2,3 layout to the .xml
* fix layout
* use text size used elsewhere
* do best effort to show SSID on sending device
* make SSID code reusable for receiver
* adapt to otherwise used font style
* show ssid also for receiver
* minor refactorings
* make qr code subtitle translatable
* tune down 'same network hint' on scanning device
* add progress bar to provider
* add progress bar to receiver
* bump version
* use 'Add Second Device' wording
this seems slightly catchier as "Add Another Device"
and has less "A" esp. in "Add as Another Device" :)
also at least translation to german seems nicer ("Zweitgerät"),
most ppl will use max. two devices, but even if more,
that should still be fine.
this was also the first intuition also by other devs in their mockups,
so we'll give it a try.
* use "Exporting/Preparing/Prepared Account" wording
let's give that a try - "Account" is also widely used,
so that seems to make some sense.
even if not 100% fitting,
it seems better than introducing the new term "Collection".
* refine abort question
* Update res/layout/backup_provider_fragment.xml
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/qr/BackupProviderFragment.java
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/qr/BackupReceiverFragment.java
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/qr/BackupTransferActivity.java
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/qr/BackupReceiverFragment.java
Co-authored-by: Hocuri <hocuri@gmx.de>
* remove string duplicate
* refine 1,2,3
* simplify string ids
* focus on what matters
---------
Co-authored-by: link2xt <link2xt@testrun.org>
Co-authored-by: Hocuri <hocuri@gmx.de>
in english "Background" is already used for "Background connection",
"Background App Refresh", "Background Notification",
so using another term here make things clearer -
esp. when the option is seen without futher context.
also, many other app prefer "Wallpaper", eg. iOS, Android, Signal, WhatsApp ...
so it is also known from there.
all in all, the new term seems much clearer and
avoids misunderstandings.
note: this change is about english only,
no need to re-translate the other languages,
where "Wallpaper" may also should strange;
i added a hint that translators do not need to use the term literally.
a common hint makes things easier,
and also has the advantage, that it is more clear to the user what the
focus of this view is as it picks up the wording from the title.
* add dclogin scheme to qr code scan
* Update src/org/thoughtcrime/securesms/qr/QrCodeHandler.java
Co-authored-by: Asiel Díaz Benítez <asieldbenitez@gmail.com>
* Update src/org/thoughtcrime/securesms/qr/QrCodeHandler.java
Co-authored-by: bjoern <r10s@b44t.com>
* handle DCACCOUNT and DCLOGIN schemes on new intents
* keep existing function name, that is maybe not less confusing, but at least already known
Co-authored-by: bjoern <r10s@b44t.com>
Co-authored-by: Asiel Díaz Benítez <asieldbenitez@gmail.com>
* reword "Webxdc [content]" to "Webxdc Apps"
adding "App" to the term makes things much clearer to the user,
was "Webxdc" is about.
eg. on iOS, we have an app selector meanwhile,
calling that _just_ "Webxdc" in the menu or in the title makes it pretty
unclear to the user what this is about.
same for the tab "Webxdc" on desktop or the default description in the summary.
otoh, calling it _only_ "Apps" (as now), may also raise false expectations
and may be mixed with "normal" apps.
so, "Webxdc App" seems to be a good approach.
there is also the term "Mini App" [^1], we could also go for that,
but this is a broader discussion as this would give up the term "Webxdc" partly.
in any case, if there is few space in the UI,
it seems to be okay to abbreviate with just "App" or "Apps" as needed,
if it is otherwise clear that the thing is a "Webxdc App" or "Mini App".
[^1]: the term "Mini App" is aleady known for similar types of apps
(some "small app" running in a "super app")
cmp. https://www.w3.org/TR/mini-app-white-paper/#what-is-miniapp .
of course, our "Webxdc Apps" are not compatible with other "Mini Apps"
however, this is also not the case between "Mini Apps" of other vendors
which also have different focuses.
so "Mini App" seems to be a broader term and does not imply compatibiliy.
* use term 'Private Apps' for webxdc content
* add some translator hints
* do not set deprecated stock-translations
* mark now unused stock translations as deprecated
* add new system messages to english strings.xml
* add translator comments to new strings
* set new system messages
* add 'Add to Home Screen' menus for webxdc apps
* make adding shortcut basically work
* avoid starting webxdc from foreign accounts
* recreate back stack, if possible
according to
https://developer.android.com/training/notify-user/navigation :
"When you start an activity from a notification,
you must preserve the user's expected navigation experience.
Tapping Back should take the user
back through the app's normal work flow to the Home screen [...]"
same seems to be true for shortcuts using the same class for constructing
the back stack.
the back stack is reconstructed for API 26 (Oreo, 2017) or newer,
for oder API `requestPinShortcut()`
only uses the top-level activity for the shortcut.
working around that is probably possible, but would be quite some effort in an
already complicated area and would result in bugs that are not so easy to see.
also, on these old androids, users are probably used to the no-back-stack
behaviour.
* show a warning if app was deleted
* add 'Add to Home Screen' also to gallery
beside chat- and webxdc-activity,
this is the third place where the webxdc is listed.
as adding may result in dialogs from the launcher,
we allow the option only for a single selected webxdc,
as otherwise a series of dialogs would pop up.
* show 'Done' toast short, this is what we are doing at all the other places when showing 'Done'
B. Petersen