also otherwise, we say "[attach] Contact", "[attach] File", "[attach] Video" etc. -
so it should be "[attach] App" as well.
this is also what desktop/iOS are doing.
the title in the app picker itself, however,
is fine with reading "Apps" - it shows multiple ones
we got some feedback,
that ppl were wondering if others can use an app
once drafted and opend.
the old title "Tap to open" might even underline that impression.
this PR changes the title to "Tap 'Send' to share"
(we need to be super-short here, "Tap 'Send' to let others use the app" is already too much :)
the sending out of apps is the much more important step than to open,
play a game and then wondering ...
ppl will figure out the latter themselves,
wondering if one can configure eg. a poll before sending -
and if not, then it's that.
it is unclear, which time this is - time of adding or time of last update?
it is the prior, however,
both are not important enough to clutter the list,
also desktop/ios do not show them.
i assume, the time display was just kept when adapting from files view.
by making the apps easier accessible,
(cmp https://github.com/deltachat/deltachat-ios/pull/2721 )
we really only want an uncluttered list.
the instructions are shown when there are no Apps, Images etc. in a chat.
while the "shared in this chat" wording
is maybe more correct on an abstract way
(there are other ways than "attach" to have an app),
the "attached in this chat" points implicitly better to the new app selector -
esp. as the same wording is used for "images",
where the avg user usually knows about how to get that attached.
this little rewording comes from a discussion with @hpk42,
surely, there can be more improvements :)
the fix could have been avoid by checking for null
or not being overly specific with the exception.
as this is a very sensible area,
where any failure is dramatic,
we do both.
i think, it is even an improvement for Android:
the hint is now also anchored by 'System Settings'
which is more in focus by casual users than 'App Settings' (long tap icon).
also, some android derivates may have different order,
which is captured better by a broader hint.
classic onboarding allows not setting a displayname on purpose,
however, that results in broken webxdc layouts
as the name is then replaced by a 40-or-so-chars-hash-without-spaces.
one can argue, that apps should handle that gracefully,
but most do not and just look buggy.
it seems reasonable,
to use the email address in that case,
same as we do at other places if the name is unknwon.
(tbh, i thought it was like that, but i mixed sth up in OS comparison).
this was also the situation before we changed selfAddr calculation, btw.
it is anyway a cornercase, webxdc cannot send the address somewhere
nor can correlate reasonably, and if the user sets a name, things are fine
(and more often than not we nudge user to set one :)
