Large attachments #4019
Large attachments #4019
Conversation
mcginty
force-pushed
the
feature/big-push-attachment-limits
branch
from
452dd4f
to
ca81649
Compare
mcginty
force-pushed
the
feature/big-push-attachment-limits
branch
from
ca81649
to
7ee3c69
Compare
| : MediaConstraints.MMS_CONSTRAINTS; | ||
|
|
||
| if (!constraints.isSatisfied(this, masterSecret, slide.getPart()) && !constraints.canResize(slide.getPart())) { | ||
| Toast.makeText(this, R.string.ConversationActivity_attachment_exceeds_size_limits, Toast.LENGTH_LONG).show(); |
There was a problem hiding this comment.
very strange side effect for this method
There was a problem hiding this comment.
yeah i was being lazy, fixed
|
comments addressed, updated |
mcginty
force-pushed
the
feature/big-push-attachment-limits
branch
from
a13b45f
to
22b69a8
Compare
| Toast.makeText(context, | ||
| R.string.ConversationActivity_sorry_there_was_an_error_setting_your_attachment, | ||
| Toast.LENGTH_SHORT).show(); | ||
| } else if (attachmentListener.isAttachmentAllowed(slide)) { |
There was a problem hiding this comment.
listeners should be one way, not bidirectional
mcginty
force-pushed
the
feature/big-push-attachment-limits
branch
from
22b69a8
to
eaadb1d
Compare
| long size = 0; | ||
| byte[] buffer = new byte[512]; | ||
| int read; | ||
| protected static long getMediaSize(Context context, MasterSecret masterSecret, Uri uri) throws IOException { |
There was a problem hiding this comment.
I don't love that this method way down here has the side effect of doing potentially long running I/O. Also, why protected? Might be better to make the caller pass in the size, rather than having it happen implicitly down here?
|
Updates #700 (Pinging for anyone else who tries the same stunt I did) |
mcginty
force-pushed
the
feature/big-push-attachment-limits
branch
from
8384b1c
to
cdb30ae
Compare
|
Media size is calculated and passed into Slide constructor, so the constructor itself is no longer a blocking operation. This also was nice in that it got rid of a couple of objects holding onto the MasterSecret. |
| Log.w("ComposeMessageActivity", e); | ||
| } | ||
| private void setAttachment(Uri uri, MediaType mediaType) { | ||
| setMedia(uri, mediaType, false); | ||
| } |
There was a problem hiding this comment.
i don't think we need separate methods for these
|
feedback addressed, unspited variables |
// FREEBIE
// FREEBIE
remove lots of unnecessary MasterSecret passing too // FREEBIE
mcginty
force-pushed
the
feature/big-push-attachment-limits
branch
from
8bfe323
to
49ed4d0
Compare
|
in 2.27.0 |
Closes signalapp/Signal-Android#4019 // FREEBIE Upstream commit: signalapp/Signal-Android@551274f
Closes signalapp/Signal-Android#4019 // FREEBIE Upstream commit: signalapp/Signal-Android@551274f
This change includes asynchronously resolving slide attachment objects since we need to calculate the total size of the media as well as alerting the user about size issues before the media is attempted to be sent.
It's a net loss diff since there was a good amount of redundant code that was easy to simplify in the process.
Audio and Video sizes are raised to 100MB, gif raised to 5MB.