Makes No Sense At All

Many developers have been facing issues with building iphone applications using distribution profiles (AdHoc and AppStore). Often the correct distribution profiles don’t appear in the build settings in XCode.

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.

A second iPhone application that I developed was released to the AppStore this week under the moop.me label. Like RitMeester it is targeted at the Dutch highway junkies, and shows maps of the different regions in the Netherlands with the main roads and traffic jams on these roads. And unfortunately, as I daily experience, there are plenty of those. The name of the application (File Info) might be a bit confusing, and comes from file which is the dutch word for traffic jam.

So far there have been rave reviews only, scoring 9 times out 9 the maximum 5 star rating, and today it took the number 1 spot in ‘most downloaded’ list in the Dutch AppStore. Thank you! The application is available for free in the Dutch AppStore now.

Recently the successful iPhone applications Trein and iNap realized a tight integration, in that you can activate iNap directly from Trein. How to create the integration on the side of the ‘receiving’ application, iNap in this case, is described in the iPhone SDK example ‘Launch Me’.

When integrating applications, you typically want to pass data from one to the other, in this post I’ll describe how the incoming parameters can easily be extracted in the receiving application.

The receiving application will register itself in the OS (for details see the ‘Launch Me’ example), and the result is that it can be activated from another application or from a hyperlink in a webpage. An example of a url that activates another application is:

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;
}

Like Snow Leopard, the next release of MPoD will focus on performance rather then on functionality. Allthough the startup performance was improved a lot in version 1.1, it still takes a long time before the lists of artists, albums and songs are available. For my own 10.000 song library it takes about 15-20 seconds.

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.