* Little fix for context menu
* Add 'My Stories' section to stories tab
* Add new story thread types
* Show stories in conversation picker
* Support for sending stories
* Update story list when sending stories
* Add basic 'My Stories' view controller
* Initial stories settings screens
* Consolidate TSPrivateStoryThread and TSMyStoryThread into one class
* Require an explicit read transaction to initialize an outgoing message
* Fix linting
* Allow enabling group story from internal settings
* Fix tests
* PR Feedback
This respects the `giftBadges` capability when trying to send gift
badges. In other words, it prevents you from sending gift badges to
someone who lacks the capability.
The bulk of this change involves fetching and saving of this new
capability. The rest of the code involves showing it on the "choose
recipient" screen (and some debug screens).
This stacks on top of PR #4065.
This is a simple change that uses the existing
batch profile fetching to get user names.
It adds a test for OWSProfileManager.
This is the first meaty part of optimizing
fetching display names.
Some contacts fall back to phone numbers as their
display names. This PR fetches them in a single
SQL query via
`OWSContactsManager.phoneNumbers(for:, transaction)`.
To achieve this, this PR introduces
`GRDBSignalAccountFinder.signalAccounts(for:,transaction:)`
to fetch many accounts at once.
In order to fetch many accounts at once, we need
to be able to fetch many values from a
ModelReadCache at once. So this PR introduces
`ModelReadCache.readValues(for:,transaction:)` and
`ModelReadCache.getValues(for:,transaction:,returnNilOnCacheMiss:)`.
Existing methods that operate on a single value
were refactored to use the batch methods.
This PR adds tests for this functionality, which
necessitated changing the visibility of various
private symbols and also improving the fake
profile manager to make it more configurable.
There's also a tiny optimization for Refinery to
avoid calling a closure that has no work to do.
This helps elide do-nothing SQL queries that would
otherwise have been introduced.
This PR is the first in a series that will
optimize looking up full names of group members.
The biggest source of slowness when opening a
group chat is looking up the full names of group
members in the search for duplicates. It is slow
because it requires multiple db queries for each
member.
The characterstic feature of this algorithm is the
iterative process of assigning names to signal
addresses. For example, some contacts' names may
be cached. For others, their profiles must be
fetched. For those without profiles, their phone
numbers must be formatted (which requires fetching
SignalAccounts). For those without phone numbers,
their user names must be formatted.
This PR creates a class called Refinery. Its job
is to make it easy to assign values to keys
through multiple passes, where each pass may
succeed only for a subset of keys.
This is useful because we will eventually issue a
single DB query for some of these passes.
PR 2982 optimized
ConversationViewController.createGroupMembershipCollisionBannerIfNecessary`
that fetches user profiles off the main thread and
then, when that completes, uses them on the main
thread to find duplicate display names.
The optimization doesn't work for large groups.
Because `UserProfileReadCache` is backed by an
LRUCache with a maximum capacity of 32, there is
effectively no cache and profiles get fetched
twice.
The main purpose of this commit is to fix this
optimization for large groups without expanding
memory usage unnecessarily. While increasing the
LRU cache's size to 1000 (or some other arbitrary
value) would fix the problem very simply, my gut
tells me that we're going to keep running into
this problem.
Rather than pick an arbitrary "large enough"
value, this commit increases the cache size to be
just large enough for its intended purpose and to
keep it that size for just long enough to do its
job.
This commit introduces the concept of a "lease" on
a larger cache size. The cache's size is defined
as the largest of all its leases plus its
"regular" size (the size it was initialized with).
For now only the user profile cache uses it.
- Optionals are now SDSSwiftSerializable as long as their wrapped type
conforms
- Avatar file writes are now performed outside of a write transaction
- Various rebase cleanup
SenderKey requires that building a message is agnostic from a single
recipient. This makes the recipient argument when building an outgoing
message optional.
Currently this is used to determine if a profile key should be appended
to the message. A different solution will be required for SenderKey
messages.
