If a user's database is corrupted, we now try to fix it. I recommend
reviewing `DatabaseRecovery` to see how this works, and
`DatabaseRecoveryViewController` for the bulk of the UI.
* sort system stories normally after viewing
* scroll to hidden stories after hiding (or unhiding). Scroll to hidden story section after expanding
* if hiding/unhiding/deleting a story from within a viewer, proceed to the next story or context and remove the previous one from the viewer
This restores the behavior prior to
4a0141be41, where I made a mistake that
affect development builds.
Previously, the generated code looked like this, to prevent
instantiation of `SignalServiceAddress`es with no identifiers:
// This is a sketch!
let address: SignalServiceAddress? = {
guard hasUuid || hasE164 else { return nil }
let address = SignalServiceAddress(uuid: uuid, e164: e164)
guard address.isValid else {
owsFailDebug("address was unexpectedly invalid")
return nil
}
return address
}()
It makes sense (to me) to do this, because all proto fields are
optional. That means you can have a valid message that lacks both of
these fields, which is allowed. It shouldn't error.
However, I changed it to the equivalent of this, which caused an error
in `SignalServiceAddress`'s initializer:
let address: SignalServiceAddress? = {
let address = SignalServiceAddress(uuid: uuid, e164: e164)
guard address.isValid else {
return nil
}
return address
}()
This reverts that to avoid the debug assertion failure. I don't think
this ever affected "real" builds beyond some extra logging.
_This change should have no user impact._
This cleans up the way we generate registration IDs. It:
- Rewrites the generation code in Swift
- Removes the "sneaky transaction" method. I did this for clarity, and
because we won't use it for much longer
- Turns a log warning into a regular log—generating a registration ID is
not a problem
- Adds tests
I think this is a useful change on its own, but will be handy for an
upcoming change, too.
Previously, we collected all URL matches and then searched through them.
Now, we search lazily, which should improve performance.
I added a perf test that repeats a URL a million times. The new code
finishes in ~0.001 seconds on my machine. The old code does not finish.
* Fix story video flickering due to excessive StoryItemMediaView recreation.
* remove debug assert if no attacgment found on dismiss, only affects debug builds but can happen if deleting while in the viewer
* fix text color for replies button on iOS 13
* pr feedback
* always set caption even if nil
* Add StoryContextAssociatedData and db migrations
* Remove hideStory from ThreadAssociatedData
* Remove lastViewedStoryTimestamp and lastReceivedStoryTimestamp from TSThread
* drop deprecated columns in db migration
* add indexes
* dump schema.sql
* Update unviewed stories SQL query
* fix thread fetching for incoming story messages
* reload story tab badge when StoryContextAssociatedData changes
* Add test for TSGroupModel backwards-compatible deserialization
* move db migration
* Only use StoryContextAssociatedData for story badge count
* update StoryContextAssociatedData lastReceivedTime when a story message is deleted
* catch group threads for outgoing story messages too
* clean up sql query
* Only update lastReceievedStoryTimestamp for remote deletions
* add latestUnexpiredTimestamp to StoryContextAssociatedData
[Android][0] and [Desktop][1] have already removed this field. This
follows suit.
The highlights:
- `SignalService.proto` removes some fields by making them `reserved`
- `ProtoWrappers.py` updates our code generation to support addresses
that only have a UUID (previously, you needed both a UUID and E164
field)
- Most everything else is removing E164s
[0]: 9c266e7995
[1]: 2b0d3cab40
Once initialized, a URLSession’s configuration can’t be changed. In
order to transfer the headers, assign them to the configuration before
assigning the configuration to the session.
This change should have no user impact.
`TSInvalidIdentityKeyReceivingErrorMessage` had an unused method,
`theirSignalId`. This removes it.
`git grep -i theirSignalId` returns no results after this change.
I think this is a useful change on its own, but will also be useful in
an upcoming change.
_This change should have no user impact._ And you can see that the only
changes to generated files are in comments.
Before this change, we used comments to denote reserved or deprecated
fields. This works, but I think we should instead use the `reserved`
keyword, which offers a few advantages. From [the protobuf docs][0]:
> If you update a message type by entirely removing a field, or
> commenting it out, future users can reuse the field number when making
> their own updates to the type. This can cause severe issues if they
> later load old versions of the same .proto, including data corruption,
> privacy bugs, and so on. One way to make sure this doesn't happen is
> to specify that the field numbers (and/or names, which can also cause
> issues for JSON serialization) of your deleted fields are reserved.
> The protocol buffer compiler will complain if any future users try to
> use these field identifiers.
This updates our proto files to use `reserved` instead of comments. It
also adds support to our wrapper script. (I moved a few things around in
that script, too, for consistency.)
I think this is a useful change on its own, but I think it'll make
things a little better when we deprecate some fields, which we're
planning to do soon.
[0]: https://developers.google.com/protocol-buffers/docs/proto3#reserved
* Add first send story privacy field to AccountRecord proto
* Store hasSetMyStoriesPrivacyKey on StoryManager
* sync hasSetMyStoriesPrivacy state
* Reuse MyStorySettingsViewController in a sheet view controller
* Show my story privacy settings from conversation picker if unset when selecting my story destination
* reload my story row to change subtitle
* pr feedback
