Firstly, they aren't compiling (and haven't been for a while), and thus prevent
iOS tests from running and being written. This can and should be fixed.
Secondly, they don't respect the ubsan.supp file. I'm not sure how to fix this.
We may just not be able to run the SSK tests as part of the Signal-iOS test
runner, and instead have to revert to running them from within a separate test
app.
Shows the conversation picker, and sends the attachment to that
conversation.
There's still a lot TODO
-[ ] resolve JSQ dependency
-[ ] properly wait for app to load
-[ ] dismiss share extension after send is complete
-[ ] support non jpeg file types
-[ ] Fix device sleep manager
// FREEBIE
previously, edit menu was only positioned correctly for text bubbles,
and centered for media bubbles.
It wasn't that noticable for images/videos since those usually extended
to the middle of the conversation view, but with narrower media bubbles
(like arbitrary attachments) this became a bigger problem.
// FREEBIE
coordinate SignalProtocol encryption/decryption on a single serial
queue. Previously message sending encrypted on the sending thread, while
message receiving decrypted on the main thread.
// FREEBIE
* Ensure NotificationsManager has dependencies
Otherwise it's easy to mess up the order of the required dependencies.
* move AccountManager into Environment, it's heavy to construct
// 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.
fixes#1231
Motivation
----------
Previously when messages failed to send, there was no reason given.
Furthermore, when media messages failed to send there was no indication
that any attempt to send the message even occurred, nor a retry
dialog.
UX Changes
----------
- Show "uploading" status for media
- Show specific error message in retry-send dialog
- Only scroll to bottom when new message is inserted
- Show specific errors when group creation fails
Code Changes
-----------
- Updated incorrect references to TSMessageAdapters which were actually
references to OWSMessageData
- MessageSender was extracted from SSK MessagesManager
- access MessagesManager as property
- idiomatic init/properties for Env
- log contact intersections
- Move scroll-to-bottom animation to main thread.
// FREEBIE
Fix animation memory leak exacerbated every time you reload a
conversation with expiration timers.
Stop animation on cells that aren't currently being displayed. This is
relatively minor compared to the above, but still, no reason to waste
cycles.
// FREEBIE