This action was previously hidden under a secret longpress gesture in
the fingerprint view controller.
Ideally we'd never receive corrupted messages, but at the point we do,
our sessions are out of whack, and the only recovery option is to reset.
Let's help our users do that.
* Resetting session sends END_SESSION message
Otherwise the remote side wouldn't know we reset the session and will
send us a message on the old ratchet.
* Don't reset their identity key when resetting sender ratchet.
* Updated translations
// FREEBIE
The earlier fix for the broken ios10 emoji font ended up breaking
messages for some users with a tall font.
Here we have a lighter touch - ensuring we don't touch messages that
don't use emoji.
Also, introduce a different approach to the fix, rather than trying to
compute the bounding rect of an appropriately attributed string, just
add an extra bit of height per line.
This approach isn't ideal for long messages with only one emoji line in
them, but the previous approach was incompatible with Chinese messages
that also contain emoji. See the new
`MesssagesBubblesSizeCalculatorTest.swift` for test cases considered.
// FREEBIE
* Separate registering an account from registering for push notifications
* Allows us to complete registration without prompting user for
notification settings.
UX Changes
----------
* Automatically keep push tokens in sync on startup.
Push tokens *can* change, though they rarely do. It happens more often
for people switching between appstore/beta builds.
fixes#1174
* Show alert with registration failure
* add secret 8-tap debug log gesture to registration flow
* Move registration to separate flow
* don't see flash of inbox when first launching
* show useful error messages when given wrong code / no code
* remove background fetch
We werent using it, but only relying on a side effect of it which is
no longer necessary.
Code Changes
------------
* More registration logging.
* Install PromiseKit with carthage
Our dependencies are not yet framework compatible, so we can't use
cocoapods.
* Merge preferences util "category" into superclass.
The immediate reason for this is Swift interop was assuming optional
types were not optional, and exploding when a value was nil.
This is clearer anyway, since we were treating it like a subclass, and
it was the only thing using the class anyway.
* auto-genstrings now searches *.swift (and *.h, which was previously
broken) for translateable strings.
// FREEBIE
fixes#1329
We must register notification settings earlier to be sure we'll be able
to get the users push tokens.
We were previously relying on a quirk of background fetch, a feature
which we don't *actually* use, wherein it's possible to get push tokens
for a user without first prompting them for their notification
settings. More on this from UIApplication.h:
// Calling this will result in either application:didRegisterForRemoteNotificationsWithDeviceToken: or application:didFailToRegisterForRemoteNotificationsWithError: to be called on the application delegate.
// ---> Note: these callbacks will be made only if the application has successfully registered for user notifications with registerUserNotificationSettings:, or if it is enabled for Background App Refresh.
- (void)registerForRemoteNotifications NS_AVAILABLE_IOS(8_0);
In the previous implementation, if a user had disabled background
notifications (e.g. in order to save battery), we were waiting for push
tokens that would never come.
However, this simple "fix" introduces a UX problem - now we prompt for
an alert in the middle of our registration flow.
// FREEBIE
Hack to fix https://github.com/jessesquires/JSQMessagesViewController/issues/1885
This doesn't happen often, but is reproducible under simulated message
churn (~50 insert/update/deletes randomly spaced over 10 seconds).
During performBatchUpdates, the collectionViewLayout can call
layoutAttributesForElementsInRect which can reference the just-deleted
item's
view. (The view presumably hasn't been deleted yet, but will be by the
time
performBatchUpdates is complete).
It's opaque how layoutAttributesForElementsInRect get's it's list of
views. I
can only speculate how this works based on debugging, but it seems that
the
CollectionFlowLayout keeps an internal list of item frames, which when
crashing
still contain items corresponding to the to-be-deleted items.
In any case, it seems like a bug that JSQMVC would ever attempt to get
layoutAttributes for an item which doesn't exist in the datasource.
previously fixed in: SSK:91fcd01632a81f2aa67d2d94b97c68d519e6881a
But got lost in a rebase after moving TSMessagesManager+sendMessage to
OWSMessageSender.
// FREEBIE
Improves the detection logic for iPhone 6 and above (uses interface idiom and the pixel width of the screen). This fixes detection on the iPhone 7 which was previously broken because it’s model number wasn’t include.
Also removes a number of category methods that weren’t being used in the codebase and were equally incomplete.
// FREEBIE
On iPhone 6 and above, media bubble sizes are 10% wider
On iPhone 5s and below, media bubbles are fixed in their larger dimension and the other dimension is calculated based on the aspect ratio of the underlying image (clamped to a reasonable min/max height).
// FREEBIE
Media bubbles (for photo, video and animated) sizes are calculated using shared logic. The bubbles are fixed width and their height is calculated based on the aspect ratio of the underlying image (clamped to a reasonable min/max height).
Fixes#1270
// FREEBIE
* From the error dialog you are able to back out of scanning or try again. Adds English localization for this message.
Adds an extra flag in OWSQRCodeScanningViewController to make sure that we don’t handle captureResults when capture is disabled (this was racing before because the call to [capture stop] is async and that was causing the cancel case to present the error dialog multiple times.
Fixes Signal-iOS#1347
* Fixes appearance of race with starting capture
Also marks the capture variable as atomic since it is accessed on
multiple threads.
// FREEBIE
Fixes the bug wherein:
Given the sender had disappearing messages enabled
And the receiver thinks it's disabled (this can happen due to re-install)
When we receive a disappearing message
The message does start expiring timer and disappear
But you see a notice "<sender> disabled disappearing messages"
Rather than the expected "<Sender> set disappearing messages timer to X".
// FREEBIE
