The first case is kind of obvious, and we’ve had this on the WordPress app for a while:

NSString *urlToValidate = urlTextField.text;	
if(![urlToValidate hasPrefix:@"http"])
    urlToValidate = [NSString stringWithFormat:@"http://%@", url];

That was OK, but clearly not enough. Some users complained that they couldn’t add their blogs to the app, and looking at the log files, the reason was obvious. They were typing things like “http:myblog.com”, “http//myblog.com”, “hppt://myblog.com”, or any other combination you can think of.

So we need to get a bit more sophisticated. Since iOS 4.0 you can use regular expressions natively with NSRegularExpression (or go for RegexKitLite if you need 3.0 compatibility), so we are going to use two of them.

^https?://

First, we check if the typed url starts with http:// or https://. If that’s the case, everything looks good

^h[htp]{1,3}s?[:/]/*

The second one is a bit trickier, but not the most complicated regular expression you could find. It means:

• Starts with “h”
• Then between 1 and 3 of “h”, “t”, or “p”. This covers htpp, hppt, htt,…
• An optional “s”. It could be a mistyped https url
• Either a “:” or a “/”
• Zero or more “/”

Note that this would also match a valid “http://” prefix, but that’s why we are using the other first. After a bit of testing, I made a NSURL category with the guessURLWithString method. If you find any errors or any URL that isn’t properly fixed, please leave a comment.

@implementation NSURL (NSURL_Guess)
+ (id)guessURLWithString:(NSString *)URLString {
    NSError *error = nil;
    NSRegularExpression *okExpression = [NSRegularExpression regularExpressionWithPattern:@"^https?://" options:NSRegularExpressionCaseInsensitive error:&error];
    if (error) {
        NSLog(@"Invalid regular expression: %@", [error localizedDescription]);
        return nil;
    }

    NSRegularExpression *wrongExpression = [NSRegularExpression regularExpressionWithPattern:@"^(h[htp]{1,3}s?[:/]/*)" options:NSRegularExpressionCaseInsensitive error:&error];
    if (error) {
        NSLog(@"Invalid regular expression: %@", [error localizedDescription]);
        return nil;
    }

    NSString *fixedURLString;
    if ([okExpression numberOfMatchesInString:URLString options:0 range:NSMakeRange(0, [URLString length])]) {
        fixedURLString = URLString;
    } else if ([wrongExpression numberOfMatchesInString:URLString options:0 range:NSMakeRange(0, [URLString length])]) {
        fixedURLString = [wrongExpression stringByReplacingMatchesInString:URLString options:0 range:NSMakeRange(0, [URLString length]) withTemplate:@"http://"];
    } else {
        fixedURLString = [NSString stringWithFormat:@"http://%@", URLString];
    }

    return [NSURL URLWithString:fixedURLString];
}
@end

You can download the code from GitHub

So I launched Instruments from Run > Run with Performance Tool > Time Profiler, and went for a first run: about 6.5 seconds.

As you can see in the image, it gets better. You can play with the settings in the bottom left pane, but for a launch Separate by thread and Hide System Libraries are a good pick.

There are two places that look good to optimize: checkIfStatsShouldRun and persistentStoreCoordinator.

• The first (checkIfStatsShouldRun) is the first thing called in applicationDidFinishLaunching, but it needs to access the core data objects, and also sends a connection request synchronously. I moved later into the initialization process, and made the runStats method run in the background.
• As for the second, it was a remainder of the migration development. We didn’t delete the old data file, so every launch the app tried to import the old blogs, wasting a precious amount of time. Now, after a successful import the file is deleted, and no more time is lost.

A few changes, ten minutes of looking around, and now it launches in less than 3 seconds. I also found some other things worth improving, but those require deeper changes, and now it’s not the time for that.

NSLog is really helpful for debugging, but there is no way (or I haven’t found it) to get the console output unless you are running a debug build from Xcode. This small class can log to a file while also printing to the console. Just import it and start using FLog instead of NSLog.

FileLogger.h:

@interface FileLogger : NSObject {
 NSFileHandle *logFile;
}
+ (FileLogger *)sharedInstance;
- (void)log:(NSString *)format, ...;
@end

#define FLog(fmt, ...) [[FileLogger sharedInstance] log:fmt, ##__VA_ARGS__]

FileLogger.m:

#import "FileLogger.h"

@implementation FileLogger
- (void)dealloc {
 [logFile release]; logFile = nil;
 [super dealloc];
}

- (id) init {
  if (self == [super init]) {
    NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
    NSString *documentsDirectory = [paths objectAtIndex:0];
    NSString *filePath = [documentsDirectory stringByAppendingPathComponent:@"application.log"];
    NSFileManager *fileManager = [NSFileManager defaultManager];
    if (![fileManager fileExistsAtPath:filePath])
      [fileManager createFileAtPath:filePath
                           contents:nil
                         attributes:nil];
    logFile = [[NSFileHandle fileHandleForWritingAtPath:filePath] retain];
    [logFile seekToEndOfFile];
  }

  return self;
}

- (void)log:(NSString *)format, ... {
  va_list ap;
  va_start(ap, format);

  NSString *message = [[NSString alloc] initWithFormat:format arguments:ap];
  NSLog(message);
  [logFile writeData:[[message stringByAppendingString:@"\n"] dataUsingEncoding:NSUTF8StringEncoding]];
  [logFile synchronizeFile];

  [message release];
}

+ (FileLogger *)sharedInstance {
  static FileLogger *instance = nil;
  if (instance == nil) instance = [[FileLogger alloc] init];
  return instance;
}
@end

1.) Open iPad app in portrait mode
2.) Click on “My Blogs” top left and choose a blog
3.) Make sure you are on the comments view and click ‘edit’ at the top right of that dialog (the button changes to ‘cancel’)
4.) Then when the list is in edit mode rotate the device to landscape mode
5.) The ‘cancel’ button now says ‘edit’. click on this ‘edit’ button.
6.) It should work fine, now simply put the device in portrait mode again and continue from step 2 above.
It should crash the second time you do this, if not it will crash on the third time.

Nice catch. When you are debugging with Xcode, most of the times you get some useful message in the console or at least some stack trace pointing where things went wrong. Today’s message was this useful

Program received signal:  “EXC_BAD_ACCESS”.

And the stack trace was no better:

NSZombie to the rescue

If you have worked with Cocoa for a while, you might be familiar with NSZombie, but since the development tools have changed in the last years, some of the tutorials around are not accurate.

NSZombie is a Cocoa trick that turns any object going to be deallocated into a NSZombie instance. You are going to crash anyway, but instead of Xcode just complaining that you tried to access the wrong memory address, you get something a bit better like this:

2011-02-25 01:27:57.063 WordPress[10496:207] *** -[CFString isEqualToString:]: message sent to deallocated instance 0xcf1b0c0

Not much, but at least you know that the guilty object was a string.

But there’s more to it. First, you enable NSZombie by double clicking your executable in the project info, and then in the “Arguments” tab setting the NSZombieEnabled environment variable

Instruments, that wonderful tool

Sometimes, it will be enough just knowing which class was released more than it should. But when it’s not, Instruments can help.

Sadly, Instruments can only do NSZombie magic on the simulator, but for this example that was not an issue. From Xcode, go to the “Run” menu, then “Run with Performance Tool”, and there you’ll probably see Zombies disabled. Don’t worry, select “Allocations” and you will be fine.

As soon as the app starts running, stop it by clicking on the big record button, we need to set up a few things first.

Click on the little “info” button besides Allocations, and enable “Record reference counts” and “Enable NSZombie detection”. Start the app again (with the same big record button) and repeat the steps that led to the crash. Same story, but this time…

And when you click on that memory address, it will show you the history of the object, when and where it was created, and every time it was retained or released until it crashed

And even more, if you double-click that line, it will take you to a code editor, at the exact line when it was released. Now, that was helpful

And as you can see from this piece of code, we were releasing email on dealloc, but we didn’t retain it on setEmail. Delete that [email release] and problem fixed.