防止MFMailComposeViewController的取消

防止MFMailComposeViewController的取消

本文介绍了如何防止MFMailComposeViewController的取消崩溃?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

某处:

if([MFMailComposeViewController canSendMail])
{
    MFMailComposeViewController *email_vc = [[MFMailComposeViewController alloc] init];
    email_vc.mailComposeDelegate = self;

    [email_vc setSubject:subject];
    [email_vc setMessageBody:message isHTML:FALSE];
    [email_vc setToRecipients:recipients];

    [self presentModalViewController:email_vc animated:FALSE];
    [[UIApplication sharedApplication] setStatusBarHidden:TRUE];
    [email_vc release];
}
else
...

其他地方:

- (void)mailComposeController:(MFMailComposeViewController*)controller didFinishWithResult:(MFMailComposeResult)result error:(NSError*)error
{
    switch (result)
    {
        case MFMailComposeResultCancelled:
            NSLog(@"Cancelled");
            break;

        case MFMailComposeResultSaved:
            NSLog(@"Saved");
            break;

        case MFMailComposeResultSent:
            NSLog(@"Sent");
            break;

        case MFMailComposeResultFailed:
            NSLog(@"Compose result failed");
            break;

        default:
            NSLog(@"Default: Cancelled");
            break;
    }

    // This ugly thing is required because dismissModalViewControllerAnimated causes a crash
    // if called right away when "Cancel" is touched.

    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 0.01 * NSEC_PER_SEC), dispatch_get_current_queue(), ^
    {
        [self dismissModalViewControllerAnimated:FALSE];
    });

}

那个丑陋的dispatch_after block是唯一可以让它在没有崩溃的情况下工作的方法。

That ugly "dispatch_after" block is the only way I can get this to work without a crash.

上下文是触摸电子邮件撰写视图控制器上的发送以外的任何内容将导致崩溃。有没有办法解决这个问题,而不必诉诸这个丑陋的创可贴?我对创可贴的理论是,当您触摸取消以确认用户确实要取消时,会显示中间视图。我想知道是否 [self dismissModalViewControllerAnimated:FALSE]; 正在尝试解除视图中的视图或其他类似的效果。通过插入一个小延迟,我推断邮件撰写视图有时间清理,然后才会被要求离开。

The context is that touching anything other than "Send" on the email compose view controller will cause a crash. Is there a way to deal with this without having to resort to this ugly band-aid? My theory on the band-aid is that an intermediate view is being presented when you touch "Cancel" to confirm that the user really wants to cancel. I am wondering if [self dismissModalViewControllerAnimated:FALSE]; is trying to dismiss a view out of sequence or something to that effect. By inserting a small delay I am theorizing that the mail compose view has time to cleanup before it is asked to go away.

我看到在另一个问题中使用延迟。但作者没有详细说明:

I've seen a delay used in another question. The author did not go into any details though:

编辑1:添加崩溃日志

Incident Identifier: ****************
CrashReporter Key:   *****************
Hardware Model:      iPhone4,1
Process:         ************* [9038]
Path:            /var/mobile/Applications/*********************
Identifier:      ***********************
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2012-07-20 11:25:53.704 -0700
OS Version:      iPhone OS 5.0.1 (9A405)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xa003853a
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                 0x316b9fbc 0x316b6000 + 16316
1   UIKit                           0x350caa9e 0x34f8e000 + 1297054
2   UIKit                           0x34fa6814 0x34f8e000 + 100372
3   UIKit                           0x34fabfb2 0x34f8e000 + 122802
4   QuartzCore                      0x33354ba0 0x33329000 + 179104
5   libdispatch.dylib               0x37896f74 0x37894000 + 12148
6   CoreFoundation                  0x37bac2d6 0x37b20000 + 574166
7   CoreFoundation                  0x37b2f4d6 0x37b20000 + 62678
8   CoreFoundation                  0x37b2f39e 0x37b20000 + 62366
9   GraphicsServices                0x376adfc6 0x376aa000 + 16326
10  UIKit                           0x34fbf73c 0x34f8e000 + 202556
11  *****************               0x00002346 main (main.m:14)
12  *****************               0x00002304 start + 32

编辑2:经过多次刮擦后,看来这是一个真正的Apple漏洞。

我下载并运行了MailComposer示例项目:

I downloaded and ran the MailComposer sample project:

它工作正常。

然后我编辑代码以在呈现和解散邮件组合控制器时删除动画。

Then I edited the code to remove the animation while presenting and dismissing the mail composition controller.

[self presentModalViewController:picker animated:FALSE];

[self dismissModalViewControllerAnimated:FALSE];

当取消用于关闭电子邮件撰写UI时,它崩溃了。

Sure-enough, it crashed when "Cancel" was used to dismiss the email composition UI.

运行僵尸带来了这个:

-[MFMailComposeController actionSheet:didDismissWithButtonIndex:]: message sent to deallocated instance 0x7479ef0

我想行动表获取解雇消息而不是邮件组成视图控制器。

I guess the action sheet gets the dismiss message instead of the mail compose view controller.

如果有人可以确认行为,我会报告错误。

If someone could confirm behavior I'll report the bug.

编辑3:报告错误。

我接受的答案很好地解释了导致此问题的潜在机制。此外,在回答评论的来回期间,确定了两个额外的解决方案。所有的创可贴,但现在有一些选择。

The answer I accepted has a good explanation of the potential mechanism that is causing this issue. Also, during the back and forth in the answer comments two additional work-arounds were identified. All band-aids but now there are a few choices.

我还没有检查过,但我怀疑ShareKit也受此错误的影响(如果是演示文稿)邮件撰写视图控制器没有动画)。

I haven't checked yet, but I suspect that ShareKit is subject to this bug as well (if the presentation of the mail compose view controller is not animated).

推荐答案

不完全。

事件序列可能如下所示:

The sequence of events probably happens like this:


  • 操作表调用 -actionSheet:clickedButtonAtIndex:在其代表(MFMCVC)上。

    • MFMailComposeViewController在其委托(您的VC)上调用 -mailComposeController:didFinishWithResult:error:

      • 您的VC调用 [self dismissModalViewControllerAnimated:NO]

        • 这会导致MFMCVC被释放。由于解雇不是动画,因此不再涉及MFMCVC。它被取消分配!

        • Action sheet calls -actionSheet:clickedButtonAtIndex: on its delegate (the MFMCVC).
          • MFMailComposeViewController calls -mailComposeController:didFinishWithResult:error: on its delegate (your VC)
            • Your VC calls [self dismissModalViewControllerAnimated:NO]
              • This causes the MFMCVC to be released. Since the dismiss isn't animated, there is no longer anything referring to the MFMCVC. It gets dealloced!

              • 但其代理已被解除分配!

                • 所以它崩溃了!

                修复将是Apple在 -dealloc中执行 actionSheet.delegate = nil

                The fix would be for Apple to do actionSheet.delegate = nil in -dealloc.

                潜在的解决方法

                [[self.modalViewController retain] autorelease]
                [self dismissModalViewControllerAnimated:NO]
                

                这是如果你使用ARC,有点棘手。

                This is a bit trickier to do if you are using ARC.

                这篇关于如何防止MFMailComposeViewController的取消崩溃?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-01 06:05