SoFunction
Updated on 2025-04-09

Android implements the addition and removal of MMS attachments

This article describes the addition and removal functions of Android's MMS attachments. Share it for your reference, as follows:

Add attachments

In ComposeMessageActivity

addAttachment(int type) function

According to different types, it is divided into 6 cases

case A：

MediaSelectListActivity.ADD_IMAGE Use gallery to select pictures:

(this, REQUEST_CODE_ATTACH_IMAGE);

Start an intent:

Intent innerIntent = new Intent(Intent.ACTION_GET_CONTENT);
(contentType); //image type
Intent wrapperIntent = (innerIntent, null);
startActivityForResult(wrapperIntent,requestCode);

createChooser function new Intent = new Intent(ACTION_CHOOSER);

That is, an ACTION_CHOOSER activity

case B:

MediaSelectListActivity.TAKE_PICTURE

Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
(MediaStore.EXTRA_OUTPUT, .CONTENT_URI);
startActivityForResult(intent, REQUEST_CODE_TAKE_PICTURE);

Get a camera to take pictures.

case C:

MediaSelectListActivity.ADD_VIDEO

Much like case A

Only in type, change from image to video

case D:

MediaSelectListActivity.RECORD_VIDEO

Just like case B, a video recorder is used, but this time there is a space calculation: leave 1024Byte for the text.

Calculate based on a MMS of 300k, the maximum use of 299k for recording. That is, 299*1024byte

Intent intent = new Intent(MediaStore.ACTION_VIDEO_CAPTURE);
startActivityForResult(intent, REQUEST_CODE_TAKE_VIDEO);

case E：

MediaSelectListActivity.ADD_SOUND

(this, REQUEST_CODE_ATTACH_SOUND);
Intent intent = new Intent(RingtoneManager.ACTION_RINGTONE_PICKER);

case F：

MediaSelectListActivity.RECORD_SOUND

Like B, seven recorders. This time the type is an exercise

Intent intent = new Intent(Intent.ACTION_GET_CONTENT);
(ContentType.AUDIO_AMR);
("", "");

case G：

MediaSelectListActivity.ADD_SLIDESHOW

The slideshow is awkward. Because the entire MMS attachment is also called slideshow, and the slideshow here means that multiple pictures are pieced together. The attachments to MMS are often several pictures. . . This place is trampled from the beginning of naming.

Uri dataUri = (false);
Intent intent = new Intent(this, );
(dataUri);
startActivityForResult(intent, REQUEST_CODE_CREATE_SLIDESHOW);

There are several things in the saveAsMms function: first, force the SMS to be converted into a MMS, encapsulate the content of the SMS into PduPersister (which can be understood as a MMS body), and new SendReq, which is the MMS header. Generate uri containing the MMS header and body.
Finally, there is an awkward SlideshowEditActivity. This thing is too troublesome. Don't watch. .

Then we arrived at the onActivityResult function. Those applications that read media data from outside activities return back to this.

A. picture

The image in onActivityReuslt will get uri, call:

addImage(uri, false);

This function will call:

Copy the codeThe code is as follows:
(, uri, false);

That is, add pictures in non-append mode.

If the image is too large, an asynchronous image compression function will be enabled.

B Take photos

It also returns a uri to onActivityReuslt function. It also calls addImage(uri, false), the same as above.

C Select video file D Take video

All calls:

addVideo((), false);

() also gets uri and addVideo call:

Copy the codeThe code is as follows:
(, uri, append);

Same as picture processing.

E Select recording file F Recording

All addAudio -->
(, uri, false);
Don't say much

Delete attachments

There is a handler in the AttachmentEditor, which is used to send messages to composeMessageActivity.

All buttons for deleting attachments are on the AttachmentEditor. There are different buttons for different media types, but the exit is the same after pressing:

Message msg = (mHandler, MSG_REMOVE_ATTACHMENT);
();

That's the operation.

The reason is the same because all nearby SlideshowModels exist in SlideshowModels, and this SlideshowModel is:

ArrayList<SlideModel> mSlides; consists of a column of slides.

Each slide can contain video, image, audio, text, and the first three cannot generally exist at the same time. The only exceptions are image and audio.

(Actually, I think if, if each slide can only contain one of three, that is, the logic may be clearer)
Let's talk about it back to that remove operation. .

The handleMessage function in the Handler of composeMessageActivity, the operation after deleting msg is:

(, null, false);

The last bit false indicates non-append mode, that is, the attachment is modified again.

What is mWorkingMessage?

It is the status of all the status of all data operations in SMS (including MMS). There are several main members:

mMmsState MMS status, is it a MMS, why is it a MMS, does it have attachments and titles, or mandatory MMS, etc.

mAttachmentType AttachmentType Attachment type. If mSlideshow is multi-page:slide type. Single page: Pictures | Sound | Video | Text. If mSlideshow is empty, it is the text type.

mSlideshow Attachment Data Array. It's that ArrayList<SlideModel> mSlides.

Now look back at the deletion operation.

The most important function in setAttachment is changeMedia(type, dataUri), the parameter type passed here is TEXT, and dataUri is null.
This function goes into:

SlideModel slide = (0);
MediaModel media;
// Remove any previous attachments.
();
();
();
// If we're changing to text, just bail out.
if (type == TEXT) {
  return;
}
// Make a correct MediaModel for the type of attachment.
if (type == IMAGE) {
  media = new ImageModel(mContext, uri, ()
      .getImageRegion());
} else if (type == VIDEO) {
  media = new VideoModel(mContext, uri, ()
      .getImageRegion());
} else if (type == AUDIO) {
  media = new AudioModel(mContext, uri);
} else {
  throw new IllegalArgumentException("changeMedia type=" + type
      + ", uri=" + uri);
}
// Add it to the slide.
(media);
// For video and audio, set the duration of the slide to
// that of the attachment.
if (type == VIDEO || type == AUDIO) {
  (());
}

When we see the first return, we can return it. .

How clean and neat! I can't just see the original attachment of the MMS and delete it with one knife. The type is returned to it and put the uri empty.

Also, let’s talk about some off-topics.

This changeMedia function, back and forth, is changed (0)

When settingAttachment, if you use the append mode, you will use appendMedia instead of the changeMedia function.

For append mode,

If the last page contains image image or video vedio, then the next picture must be added to the append.

I feel that this judgment in the source code is a bit complicated. . You can summarize it in just one sentence. He wrote the code for a long time~

But I can't write anything better

There is also the add function of SlideModel. Many situations are stacked together, so it is a bit complicated.

The key function added is the following. The first parameter is the original media in the corresponding format (for example, if you want to add a video, this is the original video, which can be null), and the second is the new media added

private void internalAddOrReplace(MediaModel old, MediaModel media) {
  int addSize = ();
  int removeSize;
  if (old == null) {
    if (null != mParent) {
      (addSize);
    }
    (media);
    increaseSlideSize(addSize);
    increaseMessageSize(addSize);
  } else {
    removeSize = ();
    if (addSize > removeSize) {
      if (null != mParent) {
        (addSize - removeSize);
      }
      increaseSlideSize(addSize - removeSize);
      increaseMessageSize(addSize - removeSize);
    } else {
      decreaseSlideSize(removeSize - addSize);
      decreaseMessageSize(removeSize - addSize);
    }
    ((old), media);
    ();
  }
  for (IModelChangedObserver observer : mModelChangedObservers) {
    (observer);
  }
}

There is also an asynchronous reduction function when the attachment is too large, which is the following function

public static void resizeImageAsync(final Context context,
     final Uri imageUri, final Handler handler,
     final ResizeImageResultCallback cb, final boolean append) {
   // Show a progress toast if the resize hasn't finished
   // within one second.
   // Stash the runnable for showing it away so we can cancel
   // it later if the resize completes ahead of the deadline.
   final Runnable showProgress = new Runnable() {
     public void run() {
       (context, ,
           Toast.LENGTH_SHORT).show();
     }
   };
   // Schedule it for one second from now.
   (showProgress, 1000);
   new Thread(new Runnable() {
     public void run() {
       final PduPart part;
       try {
         UriImage image = new UriImage(context, imageUri);
         part = (MmsConfig
             .getMaxImageWidth(), (),
             () - MESSAGE_OVERHEAD);
       } finally {
         // Cancel pending show of the progress toast if necessary.
         (showProgress);
       }
       (new Runnable() {
         public void run() {
           (part, append);
         }
       });
     }
   }).start();
}

The picture is scaled to a maximum of 640*480. If it is still greater than 300*1024-5000 bytes (almost 295k), then it is scaled to 295k.

This size is written by the source code programmer based on his feelings.

Here is the function in the ResizeImageResultCallback of the ComposeMessageActivity called.

After processing the size, you will take the new picture and setAttachment again, which will update the attachment.

For more information about Android related content, please check out the topic of this site:Android database operation skills summary》、《Android programming activity operation skills summary》、《Android file operation skills summary》、《A summary of SD card operation methods for Android programming and development》、《Android development introduction and advanced tutorial》、《Android resource operation skills summary》、《Android View View Tips Summary"and"Android control usage summary》

I hope this article will be helpful to everyone's Android programming design.