* Auto-add new contact threads to profile whitelist when local user sends first message to that thread.
* Ensure dynamic interactions have a non-negative timestamp even if the conversation was empty.
* Only call updateMessageMappingRangeOptions _after_ beginLongLivedReadTransaction and updating messageMappings.
* Improve documentation around how to avoid corrupt mappings in conversation view.
* Fix edge cases around large initial range sizes.
* Always treat dynamic interactions as read.
* Rebuild the “unseen” database views to remove dynamic interactions (see above).
// FREEBIE
When we send the nth message, we retain the footer for the n-1th message
until the nth message is successfully sent.
1. leave the footer on the n-1th message
2. draw the nth message with the "..." footer
3. update the nth message with the "sent" footer and hide the footer for
the n-1th message
In the normal case this all happens very quickly, which results in some
unpleasant flicker every time you send a message.
The concession here is that we'll only print the n-1th footer if the
outgoing message *fails*. So until we implement a design more like
Android's double-check for sent/delivery, the user will not be able to
distinguish between a sent and delivered message *while* their message
is outgoing.
In my opinion the lack of jank in the normal case makes the app
supercedes this use case.
// FREEBIE
Crypto Scheme:
- Name (un)padding
- WIP AES-GCM (funtioning, but need to verify against android
implementation, and tag functionality)
Changes to avatar API:
- hard code avatar domain (cdn.signal.org)
- avatar form hands out new avatar key, invalidating old avatar
- preliminary aes-gcm integration
Also:
- New type to represent AES128 keys, rather than passing around opaque
data blobs everywhere, we can use the compiler to help us make sure
we're passing compliant keying material.
- Started using factory pattern for API requests. This is intended to be
a lighter weight way to implement new API requests, rather than the
current 1-method class ceremony.
// FREEBIE
For ease of CDN cache expiry, each new avatar will have a unique URL, so
no need for a separate digest. Contents of file at URL will be verified
by forthcoming crypto scheme.
// FREEBIE
Refactored the ContactAvatarBuilder to clarify intent of the two
methods. One is only used for non-signal contacts in the Invite flow.
The other should be used for any signal contacts so we have a single
consistent way of generating the avatar initials.
// FREEBIE
Make avatar building sync
Tests on a iPhone5 with 1k threads, 3k contacts show no noticeable lag.
Profiling shows ~4% of usage goes to contact avatar building, but once
cached, even that goes towards zero.
// FREEBIE
There is a more true-to-life way to set verification state - mark
someone as verified or default via the SN UI.
If they are marked as verified, you can mark them as no-longer-verified
by toggling a keychange in the debug UI
// FREEBIE
From: https://developer.apple.com/library/content/qa/qa1754/_index.html
Q: Can you explain the difference between calling the AVAudioSession method overrideOutputAudioPort: with the value AVAudioSessionPortOverrideSpeaker and using the category option AVAudioSessionCategoryOptionDefaultToSpeaker with setCategory:withOptions:error:.
A: The difference is that setting the AVAudioSessionPortOverride by calling overrideOutputAudioPort: is more transient than using the category option AVAudioSessionCategoryOptionDefaultToSpeaker.
Important: The use of both AVAudioSessionPortOverrideSpeaker and AVAudioSessionCategoryOptionDefaultToSpeaker are only applicable to the AVAudioSessionCategoryPlayAndRecord category.
Calling overrideOutputAudioPort: and setting the AVAudioSessionPortOverride to AVAudioSessionPortOverrideSpeaker is a way of temporarily overriding the output to play to the speaker. Any route change or interruption will cause the audio to be routed back to its normal route, following the last-in wins rule. Think of using overrideOutputAudioPort: in terms of what you might use to implement a Speakerphone button where you want to be able to toggle between the speaker (AVAudioSessionPortOverrideSpeaker) and the normal output route (AVAudioSessionPortOverrideNone).
Note: This property is intended to allow 3rd party applications to mimic the behavior of a Speakerphone button and therefore may change the input route as well as output route. For example, setting the AVAudioSessionPortOverride to AVAudioSessionPortOverrideSpeaker while a headset is plugged in will cause the route to change to built-in mic / built-in speaker.
// FREEBIE
// FREEBIE
TODO
NEED
-[ ] icon in route picker
-[ ] commit cleanup
NICE
-[ ] present action sheet automatically when making outgoing bluetooth call
-[ ] left align icons
-[ ] audio is paused when switching between video mode (maybe existing behavior, not sure)
-[ ] Copy: iPhone/iPad/iPod instead of "iPhone Microphone"
DONE
-[x] remove "receiver" from options while in video mode
-[x] show available audio routes
-[x] select available audio routes
-[x] notification if availabe inputs change so we can update call screen
mid call with available BT route
-[x] include speakerphone in choices
-[x] Enabled button shows active speakerphone. Should still show
bluetooth picker.
-[x] toggle back and forth between audio devices
-[x] hide audio route button in video mode if no BT available
-[x] Fixed: When on speakerphone - switching to video mode goes back to bluetooth.
-[x] Fixed: When switching to video w/ bluetooth device connected there is no
audio picker.
-[x] respect speakerphone/BT selection when in or toggling to/from video
-[x] do not hide audio route button when in video mode and bluetooth
connected
-[x] Show which is currently selected audio route
-[x] switching to speakerphone no longer works
-[x] switching *back* to bluetooth no longer works
-[x] add proper bluetooth button for audio calls
-[x] add proper bluetooth button for video calls
This ensures message ordering for clients that can't handle out of order
call messages (legacy iOS and Android).
Even when we revert the previous commit, to send ICE Updates sooner,
we'll want to keep this (until we're confident all clients can receive
out of order call messages)
// FREEBIE
That change makes it more likely that the remote client will receive an
ICE update before their peer connection client is set.
We want to ship the robustness fix (waitForPeerConnection in
handleRemoteAddedIceCandidate) before we have the caller start sending
ICE updates immediately, in a future release.
At that time, we can simply revert this commit.
// FREEBIE