views:

118

answers:

2

I'm working on an iPhone app that offers the user the opportunity to send an e-mail in 3 different places in the app, and for 3 different purposes.

Rather than put the same code for showing the e-mail composer in 3 different view controllers, shouldn't I develop a separate E-mail class, create an instance, and then set properties such as To, CC, BCC, Body, HTML_Or_Not, and so on?

Also, if I create an instance of such a class, and it brings up the e-mail composer, is it OK to release the class even before the e-mail composer has left the screen?

+1  A: 

My advice, It's so easy to use the built in mail picker class, just stick with it, you can create a function to setup and show the picker, and use that when you need to like so:

- (void)showMailPicker {
 if ([MFMailComposeViewController canSendMail]) {
  MFMailComposeViewController *picker = [[MFMailComposeViewController alloc] init];
    picker.mailComposeDelegate = self;
   picker.navigationBar.barStyle = UIBarStyleBlack;

  [picker setToRecipients: ...];

  [picker setSubject:@"Title"];

  // Fill out the email body text
  NSString *emailBody = @"email Body...";
  [picker setMessageBody:emailBody isHTML:NO];

  [self presentModalViewController:picker animated:YES];
  [picker release];
 }
}

Yes, it's safe to release the picker once you have presented it, and remember that once you present the picker, you can't change the email addresses, subject, body etc...

Eric Schweichler
This doesn't answer the question. Scott seems to be aware of the `MFMailComposerViewController` and it sounds like he **is** using it. What he wanted was a way to encapsulate the behaviour of showing, handling and dismissing the mail composer in one place, and avoid duplicating the code in each class that uses it. So unless you plan for this method to live in a global class of some kind, this isn't the answer.
Jasarien
In the Apple sample app called MailComposer, the code implements a fallback method for sending e-mail for those using iPhone OS 2 or earlier. That shouldn't be necessary anymore, so I have eliminated that. The code also tests for whether the iPhone is even set up to do e-mail. I am keeping that test. Finally it brings up the mail composer, before which I can add code to pre-populate certain fields. I find that I am creating multiple variations of this in order to hard code the different data I want to pre-load, even inside one view controller. Thus my question about a global class.
Scott Pendleton
Certainly this could be implemented in a global class or function, I figured that was a given that didn't need explaining.
Eric Schweichler
A: 

My aproach would me to encapsulate the whole process of creating, initialising, displaying, dismissing and handling all of the aspects of the mail composer in a class, like a "mail manager" or something.

Then you can create and instance and set the properties you need, and then call "show mail composer" or something to that effect.

I wouldn't recommend releasing this manager class if it will be dealing with the dismissal and handling of the result of the mail composer (ie, handling an error when sending) until after it has finished what it's doing. If you release it too early, you may not have any logical way to dismiss the mail composer or gracefully handle it's results etc.

Jasarien