* initial approach commit, needs cleanup
* Keep >30s videos for non-story recipients, but split for stories
* Some cleanup
* fix too many chats toast offset
* show tooltip in the send flow
* pr feedback
* add hasViewedOnboardingStory to account record
* Post notifications for TSAccountManager onboarding state
* fix bug with local addressing when updating profile key data
* sync onboarding story view status with accountRecord
* do the bare minimum to keep tests working
* use asVoid
* update contactRecord and groupv2 protos to add hideStory flag
* sync contactRecord and groupv2Record with local storyHidden state on ThreadAssociatedData
* Add OnboardingStoryManager
* mark onboarding story viewed
* Add tests and fix issues that came up from testing
* up test timeout for slower CI
* rename SystemStoryManager and put into dependency injecton container
* Use viewed state on StoryMessage itself. Have SystemStoryManager observe app lifecyle events to automatically manage the onboarding story
* use iOS assets which are now in s3
* todo cleanup
* increment timestamp for uniqueness
* pr comments
* change literal delimiter
* Add ChainedPromise utility, tests, and use in SystemStoryManager
* discretionarily observe app backgrounding in SystemStoryManager
* renaming from PR comments
* Split OWSSignalService into a swift protocol and implementation, migrated from objc
* Put OWSSignalService under SSKEnvironment and use mock in mock environment
* Rename from basename + impl to protocol + basename
* extend mock functionality a bit
* pr feedback
The non-lazy map and filter always make a new array or dictionary,
which is often consumed immediately into a Set. Using `lazy` avoids
that intermediate allocation, as well as the need to loop over the
array or dictionary a second time.
This is a micro-optimization, but several of these accessors are
accessed fairly frequently, so we might as well make them faster.
Group snapshots fetched from the service do not store the
`didJoinFromInviteLink` field on their members, and when we parse a
snapshot into a group model we hardcode this value to `false` for all
members. However, we store that field locally on a `GroupMembership`'s
`MemberStateMap` when processing an "add members" change action, as the
field is provided in the `AddMember` change action proto.
This becomes an issue, since when we refresh the group's state from the
service (which we do periodically, e.g. when opening a group for the
first time after launch) the `GroupMembership` from the group's snapshot
on the service will not match the `GroupMembership` we have locally,
even though they are from the same revision, due to mismatched
`didJoinFromInviteLink` values (hardcoded in the snapshot).
Consequently, we believed we were "updating the group model in a user-
facing way", but the only change therein was clobbering a
`didJoinFromInviteLink: true` to `...: false`, which was 1) wrong and
2) did not have a description to show.
This commit changes `GroupMembership` to ignore values for
`didJoinFromInviteLink` when comparing equality. This means that when we
parse a snapshot into a `TSGroupModel` with all those values hardcoded
to false, but otherwise identical to our local, we will no longer see it
as different from our local (and subsequently clobber our local and
generate an empty update).
The block-based API returns a token that needs to be explicitly
unregistered, *and* the block should not capture 'self' strongly.
The fixes in this PR come in three flavors:
1. Switch to the selector-based API, sometimes taking advantage of
the fact that extra arguments to an Objective-C method can be
safely discarded (because they are passed at +0).
2. Save the observer token and unregister in deinit.
3. Comment why it's safe to leave the observer registered forever
in this particular case.
