Why mobile web apps are slow

Why mobile web apps are slow.

A great fact-driven discussion, on the challenges facing mobile application developers, with regard to speed and memory management.

Changing the Navigation Bar: MFMailComposeViewController

The iPhone 3.0 SDK introduced a number of cool new controllers, one of which was the MFMailComposeViewController class.

And although – in and of itself – it does so much, like much of what we run into in this developer life, it leaves some things greatly to be desired.

Like, “why in the heck does it ** have ** to put the subject line in the navigation bar as a title? Don’t they ** know ** I have a cool custom nav bar that they’re totally puking over?!?!?!”

Don’t fret. There is a solution.

First, you’ll need to implement the following delegate in the .h file of the controller where you are implementing the mail composer:

MFMailComposeViewControllerDelegate

Next, you’ll need to implement some sort of event handler. Here’s mine:

-(IBAction)doEmail:(id)id {
if ([MFMailComposeViewController canSendMail]) {

  MFMailComposeViewController *controller = [[MFMailComposeViewController alloc] init];

  controller.mailComposeDelegate = self;
  [controller setSubject:@"My Subject"];
  [controller setMessageBody:@"My Body" isHTML:YES];

  [self presentModalViewController:controller animated:YES];

  [[controller navigationBar] setTintColor:[UIColor greenColor]];
  UIImage *image = [UIImage imageNamed: @"custom_nav_background.png"];
  UIImageView * iv = [[UIImageView alloc] initWithFrame:CGRectMake(0,0,320,42)];
  iv.image = image;
  iv.contentMode = UIViewContentModeCenter;
  [[[controller viewControllers] lastObject] navigationItem].titleView = iv;
  [[controller navigationBar] sendSubviewToBack:iv];
  [iv release];
 
  [controller release];
  }
else {
  UIAlertView* myAlert = [[UIAlertView alloc] initWithTitle:@"My App" message:[NSString stringWithFormat:@"You cannot send email at this time."] delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil];
  [myAlert show];
  [myAlert release];
  }
}

Finally, you’ll need to implement a method to dismiss the email composer after you cancel or send.

// Dismiss email composer UI on cancel / send
- (void)mailComposeController:(MFMailComposeViewController*)controller didFinishWithResult:(MFMailComposeResult)result error:(NSError*)error {
  [self becomeFirstResponder];
  [self dismissModalViewControllerAnimated:YES];
}

The bits that take care of the custom navigation bar (and incidentally, hiding the subject line title Apple insists on fobbing off on you) are in bold in the code above.

There are a few interesting details to note:

  [[controller navigationBar] setTintColor:[UIColor greenColor]];

Will tint the Cancel and Send buttons to whatever color you like; in this example, I chose green. Use whatever you like here.

  UIImage *image = [UIImage imageNamed: @"custom_nav_background.png"];
  UIImageView * iv = [[UIImageView alloc] initWithFrame:CGRectMake(0,0,320,42)];
  iv.image = image;
  iv.contentMode = UIViewContentModeCenter;
  [[[controller viewControllers] lastObject] navigationItem].titleView = iv;
  [[controller navigationBar] sendSubviewToBack:iv];
  [iv release];

The code above loads an navigation bar image (320 x 42 pixels for iPhone 2G, 3G, and 3Gs; 640 x 84 pixels for retina display), and sets the titleView on the MFMailComposerViewController navigation bar to the UIImageView I constructed with my custom navigation bar background.

And last but definitely not least, we must send the custom titleView to the back so that we can “see” the Cancel and Send buttons.

The subject line will now no longer appear in the title bar – which is why I did this in the first place. It was totally jamming my chi.

Give it a try. I’d be interested in your feedback on this solution.

Stop the Bouncy UIWebViews!

If you’ve ever used UIWebView inside of any iPhone app, one of the more unique – and some would say, annoying – behaviors of the embedded web view is that it “bounces” when pulled down, exposing a gray background and letting your users know that “hey – this guy is using a web view!”

There is an answer to the “bouncy” web view problem. Actually, there are two (2) answers to the “bouncy” web view problem. Since one uses an undocumented call and will therefore get your app “bounced” from the App Store (sorry for the bad pun), I won’t include it here.

The answer that ** won’t ** get your app declined but ** will ** stop the bouncing may be found below:

// Stop the bounces
UIScrollView* sv = nil;
for(UIView* v in myWebView.subviews){
  if([v isKindOfClass:[UIScrollView class] ]){
    sv = (UIScrollView*) v;
    sv.scrollEnabled = YES;
    sv.bounces = NO;
    }
  }

This will still allow your web view to scroll, but won’t “bounce” when you try to pull the view up or down outside of its given bounds. If you also want to stop scrolling, simply change the sv.scrollEnabled line to NO.

Big Time Bug in Facebook Connect for the iPhone

While working on a new app for a client in Orlando today, we uncovered a significant bug in the Facebook Connect classes from Facebook for the iPhone.

What’s the bug?

Well, if you’re one of the fortunate souls who have a FB user id larger than an int, FB Connect for the iPhone, as it comes from Facebook, will blow up.

Blow up REAL good.

Oh, it may authenticate. But just wait till you check the uid in the session.

HEY! It doesn’t match my real uid!

The big bug is this – the FB Connect code uses library methods meant for integer values… all the while preaching to everyone the importance of Facebook User IDs being 64 bit values; in other words, in Objective-C parlance, long longs.

Too bad, ’cause with FB Connect for iPhone what this turns out to be is “do as I say, not as I do.”

Here’s where the busted code exists in the FBConnect code, and what needs to be done to correct:

FBSession.m

in the -(void)save method, replace the line that has [defaults setInteger:uid] forKey:@"FBUserId"] with the following:

[defaults setObject:[NSString stringWithFormat:@"%qi", _uid] forKey:@"FBUserId"];

in the -(BOOL)resume method, replace the line that has FBUID uid = [defaults intForKey:@"FBUserId"] with the following:

long long uid = 0;
NSString * uidString = [defaults objectForKey:@"FBUserId"];
if (uidString!=nil) {
NSScanner* scanner = [NSScanner scannerWithString:uidString];
if([scanner scanLongLong:&uid] == YES) {}
}


For all the razzing I’m giving Facebook here, really the broken parts of the classes are centered around moving data in and out of the settings bundle. Yeah – the uid’s are integers – big ass integers, to be sure – but the int functions for the settings bundle are no good for long longs – you got to convert them into NSStrings, and then back to long long again (%qi in sprintf-speak) when using the bundle functions.

Hope this helps those of you trying to explain why your iPhone apps work most of the time with Facebook Connect.

Sometimes, it really isn’t you – it IS the software (with apologies to Nick Burns, the Computer Guy).

The Right Way… and The Best Way

If you’ve ever wanted to put a custom image into the title bar of an iPhone app, no doubt you’ve used – or at least run across – code similar to the following:


UIImage * titleImage = [UIImage imageNamed:@"nav_bar_background.png"];
UIImageView * titleImageView = [[UIImageView alloc] initWithFrame:CGRectMake(0, 0, 320, 42)];
titleImageView.image = titleImage;
titleImageView.contentMode = UIViewContentModeScaleAspectFit;
titleImageView.autoresizingMask = UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleHeight;
[self.myBar addSubview:titleImageView];
[titleImageView release];


And this is a very workable solution.

It’s just not the BEST solution.

The problem with this approach is that if the navigation controller pushes another UIView on the stack, odds are the UIImageView is going to cover your navigation buttons.  Even if the title background image is sent to the back of the z-order.

Double-plus un-good.

The optimal approach to solving this is to implement a category for the UINavigationBar.

What’s a category?

It’s a handy way to extend the capabilities of a built in class without fully having to subclass the whole darn enchillada.  Technically, categories permit a programmer to add methods to an existing class without the need to recompile that class or even have access to its source code.

Take a look:

// UINavigationBar catergory for painting background image in a way that doesn't hide nav buttons.

@implementation UINavigationBar (UINavigationBarCategory)
- (void)drawRect:(CGRect)rect {
UIImage *image = [UIImage imageNamed: @"nav_bar_background.png"];
[image drawInRect:CGRectMake(0, 0, self.frame.size.width, self.frame.size.height)];
}

@end

Include this little nugget in your project, and voila – you have a navigation bar image background that works in any orientation and doesn’t hide navigation buttons.

Enjoy.

Simple Formatting in a Cocoa Touch Text Edit Field (UITextField)

Several challenges of the XCode / Cocoa Touch development environment involve doing things that are trivial in other places, but no so much so within XCode.

One of those challenges is formatting a text edit field.  Social security numbers, phone numbers, postal codes, VINs… the kind of mundane crap that is uber-trivial in tools like MS Access, but often prove to be ball-busting-ly frustrating to do in Objective-C.

For me particularly, I had a price field that I wanted to display.

Apple supplies a couple of keyboard choices for the iPhone that could have done the trick for supplying numeric data entry, but they had about 40 characters more than I needed (0-9, and decimal point were all I really desired, and being lazy, didn’t want to write a regular expression for parsing).

There is a phone number pad (no good) and a number pad (almost what I need – but no decimal point).  But the number pad would be “good enough” if I could just embed an implied decimal point.

Apple has no built in / native way to format a text field with say an embedded decimal (so I wouldn’t have to type it). I had to write my own handler to take care of this.

Here is my home brewed work around for this situation. I’m not going to focus on setting up UITextField events, only on the problem at hand.

Consider the following Edit Changed code:

// Our price changed... we want to format it with an implied decimal point.
-(void)textFieldPriceDidChange:(id)textField {

static BOOL toggle = NO;
if (toggle) {
toggle = NO;
return;
}

NSString* strPrice = [[textField object] text];

strPrice = [strPrice stringByReplacingOccurrencesOfString:@"." withString:@""];
toggle = YES;
price.text = [@"" stringByAppendingFormat:@"%0.2f", [strPrice floatValue]/100.0];

}

The code assumes that I have a UITextField named price somewhere on a form. When the field’s text is changed, the event fires, and I:

-) Strip out any existing decimal point,
-) Divide the float representation of the value by 100, to give an implied 2 decimal point precision,
-) Use the printf-styled %0.2f formatting string to pretty up the output the way I want,
-) Put the value back in the field.

But wait a minute… won’t putting a value back into the price field trigger yet another Edit Change event, and cause an endless loop?

Yes. It will.

But take a look at the BOOL static toggle.

That toggle essentially says “OK. If I see that I am already handling the formatting of this field, reset the toggle, and return.”

This is a simple but very effective way to add formatting to a text edit field, and the concept can easily be extended to other formats without a lot of sweat (%05d-%04d, %3d-%2d-%4d, %2d-%7d, %2d/%2d/%4d – you get the point).

Enjoy… and happy coding.