Initially they were there to offer richer error messages when the wrong
code was scanned.
However, we found that people were posting them publicly,
misunderstanding the QR codes to be a kind of personal identifier.
For one, this isn't useful because the QR codes, like safety numbers,
are unique *per* conversation. So they aren't useful in a generic sense.
And secondly this is bad because the QR code contains both parties phone
numbers.
// FREEBIE
* Separate account registration from push token registration
* Provide better errors when validation fails (e.g. numbers don't match, numbers blank)
* More logging during registration
* Call success after setting phone number to avoid any future race condition
This isn't currently causing problems, but it's unexpected that we'd
mutate the state *after* calling a callback which might inuitively rely
on that state.
* Don't throw exception off thread when device keys 404's
* Better async startup handling
- move processing off main thread
- reduce code duplication
- don't wrap it in a transaction in the future case where we want to
further access the DB
// FREEBIE
Motivation
----------
We were often swallowing errors or yielding generic errors when it would
be better to provide specific errors.
We also didn't create an attachment when attachments failed to send,
making it impossible to show the user what was happening with an
in-progress or failed attachment.
Primary Changes
---------------
- Funnel all message sending through MessageSender, and remove message sending
from MessagesManager.
- Record most recent sending error so we can expose it in the UI
- Can resend attachments.
- Update message status for attachments, just like text messages
- Extracted UploadingService from MessagesManager
- Saving attachment stream before uploading gives uniform API for send vs.
resend
- update status for downloading transcript attachments
- TSAttachments have a local id, separate from the server allocated id
This allows us to save the attachment before the allocation request. Which is
is good because:
1. can show feedback to user faster.
2. allows us to show an error when allocation fails.
Code Cleanup
------------
- Replaced a lot of global singleton access with injected dependencies to make
for easier testing.
- Never save group meta messages. Rather than checking before (hopefully) every
save, do it in the save method.
- Don't use callbacks for sync code.
- Handle errors on writing attachment data
- Fix old long broken tests that weren't even running. =(
- Removed dead code
- Use constants vs define
- Port flaky travis fixes from Signal-iOS
// FREEBIE
* new protobufs from libsignal-service-java@a1c93edc40e3ce201fa4e70339a3e6f4e197e319
* Makefile to build ObjC classes from *.proto
* refactored some touched code to minimize duplication
* removed unused protos
* deleted some dead code
* renamed method for clarity
// FREEBIE
Our pod SSKeychain was renamed to -> SAMKeychain to avoid collision with
the iOS10 library SSKeychain.
* log failure to write keychain (this seems to only happen on simulator)
* ensure we exit if we fail to set DB cipher key
// FREEBIE
In theory, this should have already been handled by the
YapDatabaseRelationship extension via edges.
However, in practice, there were situations (cause unknown) where
interactions would exist without an edge to their corresponding thread.
Rather than being clever with the edge/callback machinery, now threads
explicitly delete all their interactions, and interactions delete all
their attachments (when applicable).
Also, a class to clean up spurious interactions / attachments
In the process:
- refactored TSYapDatabaseObject init to specify designated initializer
- added some testing niceties to TSYapDatabaseObject
// FREEBIE
* Use SocketRocket pluggable policies
Pluggable policies are currently only in our fork, but pending upstream
PR: https://github.com/facebook/SocketRocket/pull/429
Also:
* rebased SocketRocket against latest upstream to incorporate bug fixes.
* adapt to new upstream API for error handling (vs previous exception throwing)
* renamed AFSecurityOWSPolicy -> OWSHTTPSecurityPolicy to differentiate
it from OSWWebSocketSecurityPolicy
* Follow conventional singleton pattern with onceToken
* bump xcode version to play nice with SWIFT_NAME in SocketRocket
// FREEBIE
While trying to pull in upstream changes to our fork of SocketRocket I
noticed we're publishing it/installing it from CocoaPods trunk, but
there's no need to do that.
Also, due to upstream refactoring, the actual included file has
changed.
// FREEBIE
Michael Kirk
Michael Kirk
Michael Kirk
Frederic Jacobs