* allow playback of audio messages from the message detail view
* Update UI when an audio message pauses because another one started playing
* pr feedback
* Add audio playback rate button UI
* update animation values and remove feature flags since its now ready to go to prod
* address PR feedback
* PR nits
Commit 04737ff044
attempted to fix an assertion in
StoriesViewController due to UITableView
complaining about inconsistent state. The issue
continues to happen. This diff fixes it once and
for all (I hope!).
The scenario that caused a crash prior to
04737ff044 was:
Initially:
models = [a,b,c]
Database changes to [a,b]
reloadStories (loading queue)
newModels = [a,b]
schedule block to run on main queue
Database changes to [x, b]
updateStories (loading queue)
captures self.models, value is [a,b,c] // cue ominous music
load from database
newModels = [x,b]
schedule block to run on main queue; will delete c and change a to x
reloadStories.block runs on main queue
self.models=newModels, value is [a,b]
tableView.reloadData() // UITableView thinks c is deleted
updateStories.block runs on main queue
self.models=newModels, value is [x,b]
tableView.beginUpdates()
tableView.delete(index: 2) // crashes because c was already deleted
Post-04737ff the following scenario causes a
crash:
Initially:
models = [a,b,c]
Database changes to [a,b]
updateStories (loading queue)
load from database
models.set([a,b])
schedule block to run on main queue which will delete c
iOS gets a wild hair and decides to call some
UITableViewDataSource methods.
tableView(_, numberOfRowsInSection:)
return [a,b].count // Now UIKit thinks c is gone
updateStories.block runs on main queue
tableView.beginUpdates()
tableView.delete(index: 2) // crashes because 2 is out of bounds vs number of rows
This commit fixes the problem by ensuring the
read-modify-write that happens in updateStories
never reads older data than what UITableView
has been told about and also that updates to the
model are properly synchronized with
beginUpdates()...endUpdates().
Here's how to think about it: the database goes
through a series of changes. Call them v1, v2,
..., vN.
The loading queue will see each in turn. For each,
it will enqueue a corresponding block on the main
queue to update `model` and tell UITableView about
it.
From the POV of the main queue, each update occurs
in the scope of a UITableView update.
From the POV of the loading queue, each update
reads from exactly the preceding version (from
`trueModels`) and writes to exactly the next
version of `trueModels`.
Therefore, there are no data races.
This change should have no direct user impact.
`OWSOutgoingReactionMessage` was untested. This adds a basic test for
its `shouldBeSaved` method.
I think this is a useful change on its own, but may make future changes
easier, too.
SignalServiceKit is currently a separate pod. This makes merges tedious
and error-prone. Ultimately, it slows us down. It might've made sense as
a standalone library before, but it's so tightly integrated now that it
isn't useful to have it be separate.
This changes that, and makes SignalServiceKit a "normal" target.
IMO, most of this change isn't that exciting—just a bunch of changes to
scaffolding. There's one slightly spicier change: our generated
`Acknowledgements.plist` is now a little more clever.
Co-authored-by: Max Radermacher <max@signal.org>
• provide visual feedback when user selects media quality.
• add VoiceOver support.
• fix retain cycle caused leak of ActionSheetController objects.
• correct bottom margin on non-notch devices.
- PhotoCapture's logic was correct, but hard to prove such.
- ScanQRCodeViewController left notifications on for the rest of the
process lifetime.
- CallService was working around a WebRTC issue that appears to no
longer be present (per inspection of the WebRTC code).
This should have no direct user impact.
We currently have two ways of sorting `#import` and `#include`
statements:
1. With our precommit script
2. With `clang-format` (via `git-clang-format`)
It *looks* like we aren't using `clang-format` (because of the
`SortIncludes: false` option in `.clang-format`) but we are,
which you can see by running `clang-format --dump-config`. As a separate
issue, it seems like we're not picking up the `clang-format`
configuration file (`clang-format --style=file:.clang-format
--dump-config` gives different results).
I've run into situations where the two of them "fight", so I think the
best thing to do is pick one. After some discussion, we decided to pick
`clang-format`.
* Propagate ThreadAssociatedData audioPlaybackRate down to CVComponentAudioAttachment
* remove audioplaybackrate from component state; keep only on view state
This commit adds something new to the message detail view: the remaining
disappearing message time, if relevant.
For example, "Disappears: 6d 23h 58m 6s" (or something similar) will be
shown.
Builds off of 70eca7b99b and
846e802784.
The cause of this issue was that ImageEditorViewController's view was created
with zero dimensions. Those dimensions were then used to pre-calculate size
of the toolbar which ended up being incorrect.
The fix is to let UIKit create the root view and move everything we did in `loadView`
to `viewDidLoad`.
When user starts video recording some buttons in the top part of the screen disappear and recording duration indicator appears. This commit adds simple fade-in/fade-out animation to those changes.
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).
Previously, `String#formatDurationLossless` rolled a custom formatter.
Now, it uses `DateComponentsFormatter`.
See also: the tests in `Signal/test/util/StringAdditionsTest.swift`,
which were untouched as part of this change.
I think this is a useful refactor anyway, but it should also fix rare
RTL bugs where duration components would be backwards. (I don't think
this ever happened under normal conditions, but it could happen if a
disappearing messages timer was set to something unusual like "1 day, 3
hours".)
I also plan to build off of this for an upcoming change, which is why
I did this now.
This is a trivial change that should have no user impact.
`String.formatDurationLossless` calls `NSString.formatDurationLossless`,
so this is a no-op. I think it's slightly better to call a `String`
method from Swift than an `NSString` one.
I did this because it makes an upcoming change easier, but I think it's
useful on its own.
