I have been struggling with this for quite some time as well, but as of late I seem to have found a method of working that always does the trick. What it comes down to, is that when you want to change the build settings, as well as when you want to build a distribution version, you need to make sure that a device (iPhone, iPod Touch) is connected to your Mac. If you don’t connect it, there’s a good chance that the build profiles don’t show up in the build settings. Connecting the device and restarting XCode usually fixes this.

The practice I’m using currently, is that whenever I want to build for testing in the iPhone simulator I make sure no device is connected, and when a build is destined for a device I make sure that a device is actually connected. I make it a habit to connect or disconnect the device (depending on the build target), and restart XCode. This is a bit of a hassle, but at least it gives me predictable results.

myapp://myapp?latitude=51.3&longitude=5.2&title=middle of nowhere

In the receiving application the method - (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url will be called on the application delegate object, and in this method you need to extract the parameters from the URL. The following code shows how to do that with minimal code. Like Apple’s example, it does a lot of checking to prevent undesired usage, in this case the url parameters must meet the exact specifications (i.e. no missing parameters, no extra parameters) otherwise the request will be ignored.

- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url
{
  // You should be extremely careful when handling URL requests.
  // You must take steps to validate the URL before handling it.
  // If any of the validations fails, bail out returning NO.
  if (!url) {
    // The URL is nil. There's nothing more to do.
    return NO;
  }

  // Split the url into two sections, one section with the base url and one with the parameters.
  NSArray *urlSections = [[url absoluteString] componentsSeparatedByCharactersInSet:
              [NSCharacterSet characterSetWithCharactersInString:@"?"]];

  // Check that you actually got a base section and a parameter section.
  if ([urlSections count] != 2) {
    return NO;
  }

  // Check that the base part of the url is what you expect it to be.
  if (![[urlSections objectAtIndex:0] isEqualToString:@"myapp://myapp"]) {
    return NO;
  }

  // Split up the parameter section into a parameter Array.
  NSArray *parameterArray = [[urlSections objectAtIndex:1] componentsSeparatedByCharactersInSet:
              [NSCharacterSet characterSetWithCharactersInString:@"&="]];
  NSEnumerator *parameterEnum = [parameterArray objectEnumerator];
  NSString *parameter, *value;
  // The parameters values that we are expecting.
  NSString *latitude = nil, *longitude = nil, *title = nil;

  // Run through the array of parameters.
  while (parameter = [parameterEnum nextObject]) {
    // Get the value that goes with this parameter, and if it is missing break.
    if ((value = [parameterEnum nextObject]) == nil)
      break;

    // Check the parameter value against the parameters that you support/expect,
    // and assign the matching value to the right variable.
    if ([parameter isEqualToString:@"latitude"])
      latitude = value;
    else if ([parameter isEqualToString:@"longitude"])
      longitude = value;
    else if ([parameter isEqualToString:@"title"])
      title = [value stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
    else {
      // An unexpected parameter was passed, bail out.
      latitude = nil;
      longitude = nil;
      title = nil;
      break;
    }
  }

  // Check if we got all parameters (in this case all are mandatory), if not bail out.
  if (latitude == nil || longitude == nil || title == nil) {
    return NO;
  }

  // Use the parameters to do your thing.
  CLLocation *location = [[[CLLocation alloc]
                               initWithLatitude:[latitude doubleValue]
                               longitude:[longitude doubleValue]] autorelease];
  [someObject activateDestination:title location:location];

  return YES;
}

By using a locally cached sqlite3 database in combination with lazy loading, the loading now takes about 3 seconds, which is really a massive improvement. In the coming week additional testing will be done, and I hope that this release can be available in the AppStore in 2 weeks from now.

This could be combined with a 2nd now playing screen that shows the album cover art. Then this screen would not have buttons, instead the swipes would do the work.
Do you think this would be a useful addition? Or do you have a better idea? Then please post your comments and I’ll see what can be done.

Also this week I’ve made improvements to the now playing screen, to get rid of the sluggish performance that various people have been reporting. I expect to submit the new version for AppStore review in the coming week.

For a developer, some of the reviews and 1* ratings on the AppStore are actually very discouraging: unsubstantiated hints of illegal practices, people who are apparently to dumb to read or understand what’s written in the description and then question the usefulness or functioning of an application :-(.

RitMeester is the first Mac based program that helps you to keep a detailed and consistent administration, with minimum effort. All details required by the tax authorities are stored, and you’re only a few clicks away from creating a printed version of your administration when needed.

RitMeester is available in Dutch only, and can now be downloaded as a trial version. Once you are convinced of the benefits it provides you, you can upgrade to the full version for €17.50.

It doesn’t add any new functionality, so if the previous version runs fine for you there is no need to upgrade, allthough it won’t hurt either.