Mundue Blog

Adding scripts to Apple Mail Rules

mundue — Tue, 07 Feb 2012 22:00:17 +0000

I use Apple Mail Rules for many things. They help me organize and flag incoming messages, which I find very useful. Recently however I came across a problem trying to implement a rule which is supposed to run a script as its action. The AppleScript code was never executing. Attempts to seek solutions via Twitter, StackOverflow, and mailing lists all yielded no working results. I finally got it working, and thought I’d share how it’s done.

If you’re not familiar with Rules, here a quick explanation. Rules operate on incoming messages and test them against each rule’s conditions. If conditions are met, the message is subject to perform the rule’s action. In Mail’s Preferences pane, you select the Rules icon and click on Add Rule. Give your rule a description (name it, essentially), then define some conditions and actions. The conditions can be logically ANDed (“all”) or ORed (“any”) together to get the desired results. There’s a lengthy list of conditions in the popup menu. Options for each condition help narrow it down, for example, the Account condition has a list of all your active accounts. The built-in actions for a rule include moving to a folder, marking it flagged, playing a sound, etc.

One action that I hadn’t used before was “Run AppleScript.” In this case I need to use a script to extract the email address of the sender from a message. Maybe there’s an easier way, but I decided to try to write a simple script and see what would happen. I’m no stranger to AppleScript because I was using it before the System 7 rollout over 20 years ago.† So what would such an AppleScript look like? If you look at the Help for using scripts as rule actions, it says to simply select your existing script file from the file chooser. Then it says, “To see sample scripts for mail, open the AppleScript dictionary for Mail.” Aha! That should be insightful. Clicking on the link brings up the AppleScipt editor (found in /Applications/Utilities) with the dictionary for Mail. An AppleScript dictionary shows the publicly exposed message suites that Mail supports. This basically defines how you can interact with Mail through Apple Events, the underlying technology behind AppleScript.

But there are no sample scripts. OK, I try the menu item File->New From Template->Mail->Mail Rule Action.scptd, which prompts you for a save location. In my internet search results people mentioned saving such scripts into ~/Library/Mail Scripts. That folder doesn’t exist, but I created it and saved my file. The script has the thinnest of possible example code to show how you might use it to process each message. Then I added something innocuous to the script, like a beep command, so I could tell if it’s working or not. Going back to Mail, I selected my new script and saved the rule. To make it even easier, I made the rule’s condition match any message from a particular account. One way to test rules is to select some message in a mailbox and choose “Apply Rules” from the context menu. [NOTE: this will apply ALL the rules for the selected messages, not the one you just created!]

In my case, the rule matched the conditions, but the script didn’t run. You can add another action in the rule to play a sound (this is different from the beep command in the script) and that action runs, so you know the condition is met. So what’s the problem? Well, it turns out there’s a bug in Mail, and when you choose the file in your ~/Library/Mail Scripts folder, it can’t parse the path name. Instead of inserting /Users/mmartel/Library/Mail Scripts/MyScript.scptd it inserts the friendly ~/Library/Mail Scripts/MyScript.scptd path.

Now that’s a real bummer. If you dig a little deeper, you can find out that in Lion the sample Mail scripts are actually in a new folder, in the system Library folder:

OK, now these are some useful script samples, and if you look here you’ll find some good examples. But what happens if you try to save your scripts to that folder? Not possible, sorry. That Library folder is restricted in Lion, so you can’t put your files in there without mucking with permissions. So now what? Can’t put scripts in my own folders, can’t put them in the system’s folders. This isn’t looking good.

My solution is to put them in a shared folder which I can write to. Such a folder is /Users/Shared/ and if you select a script in there then Mail won’t need to use the ~ substitution which causes the bug which makes it unable to locate and run the AppleScript. I don’t know why this process isn’t better documented. Until then I’ve filed a bug with Apple and hopefully someday we can again put scripts in our own user folders and have Mail find/execute them.

For the curious among you, here’s part of my script, which just says the name of the sender of a message that meets the conditions:

using terms from application “Mail”

on perform mail action with messagestheseMessagesfor ruleSaveSender

tell application “Mail”

repeat with eachMessage in theseMessages

set name_ to extract name from the sender of eachMessage

do shell script “say ‘Received email from ” & name_ & “‘”

end repeat

end tell

end perform mail action with messages

end using terms from

The “do shell script” is just a way to run bash scripts inline, and from there your imagination is the limit as to what this AppleScript can do. Check out the example scripts mentioned above to find out more about the specific syntax requirements.

I hope you find this useful. I just wish I hadn’t wasted the better part of a day figuring it out. If you know of better documentation, please let me know where to find it.

—–

† Does anybody remember Inside Macintosh: Volume VI or all 1008 pages of Inside Macintosh: Interapplication Communication?

Using NSOperationQueue for Background Parsing

mundue — Sat, 03 Sep 2011 23:00:00 +0000

Let’s say you’re making HTTP requests and handling responses as we described last time. Parsing the results is usually pretty easy, but what happens when you have a large blob of data, be it XML or JSON or whatever? Any lengthly processing on the main thread, more than a couple hundred milliseconds, will introduce a noticeable hiccup in the UI. Adding a worker thread would help, but perhaps the easiest method is to use the non-blocking NSOperationQueue. With NSOperationQueue you simply package up the work to be done into an NSOperation instance and add it to the queue.

Your application can create any number of NSOperationQueue objects, but the documentation suggests there is a practical limit to how many operations are executing at any given time. Specifically, adding additional queues does not mean you can execute additional operations. I find that a single queue is usually sufficient. Having access to a global operation queue means you can add, suspend, and cancel operations as needed. Add something like this to ApplicationDidFinishLaunching:

// Create the shared operation queue

sharedOperationQueue = [[NSOperationQueuealloc] init];

Then you can begin adding operations to the queue. Take the request handler callback we used last time, and modify it slightly, like this:

id delegate = self;

myConnectionController* connectionController = [[[myConnectionController alloc] initWithDelegate:delegate

selSucceeded:@selector(connectionSucceededWrapper:)

selFailed:@selector(connectionFailed:)] autorelease];

[myConnectionController startRequestForURL:[NSURLURLWithString:@"http://request.org/somequery.php"]];

Notice all we did was change the selSucceeded selector to connectionSucceededWrapper:. The new wrapper method creates and adds the operation to the queue, as follows:

- (void)connectionSucceededWrapper:(NSMutableData*)data

{

NSInvocationOperation* theOp = [[NSInvocationOperation alloc] initWithTarget:self

selector:@selector(connectionSucceeded:) object:data];

[sharedOperationQueue addOperation:theOp];

}

There’s no need to change the connectionSucceeded callback. This is presumably where you do the parsing, or any lengthy processing, and probably post notification that the model has changed. Perhaps you are loading thumbnail images and need to cache the image data and notify a table view to refresh a cell. Because the NSOperationQueue operates in a separate thread your UI will not stutter. However, since it executes on another thread, if you need to update any UI elements make sure to use performSelectorOnMainThread: when doing so.

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site,RSS feed, or Twitter.

Simple HTTP Request Handling

mundue — Tue, 19 Jul 2011 05:00:57 +0000

It’s common for iPhone apps to need to make HTTP requests and receive results in either JSON or XML format. There are several excellent full-featured tools ( ASIHTTPRequest, RestKit, etc.) to help you with this task, but sometimes all you need is NSURLConnection. NSURLConnection is a simple class that provides easy to use high-level asynchronous request/response handling. I’ll describe a simple wrapper I’ve been using to make it easy to handle multiple requests easily.

When using NSURLConnection there are only a couple of things to deal with. Unless you are using the synchronous version (not recommended) you will typically set up an object, such as your application delegate or a view controller, as a delegate to receive the NSURLConnectionDelegate callbacks. The main delegate message you need to handle are connection:didFailWithError:, connection:didReceiveData:, and connectionDidFinishLoading:.

One potential issue you face here is using a single object as delegate for multiple connections. Then your delegate message handlers will become messy as they attempt to determine which response goes with which request, etc. Now instead consider creating a utility class with just two public methods, like this:

myConnectionController interface

@interface myConnectionController : NSObject {
NSMutableData* receivedData;
}
@property (nonatomic, retain) id connectionDelegate;
@property (nonatomic) SEL succeededAction;
@property (nonatomic) SEL failedAction;
- (id)initWithDelegate:(id)delegate selSucceeded:(SEL)succeeded selFailed:(SEL)failed;
- (BOOL)startRequestForURL:(NSURL*)url;
@end

In this sample class receivedData is where the response will be stored, the connectionDelegate refers to what will be the target of the succeededAction and failedAction messages. After all, that’s all I really care about when making this request: success or failure notification. Now your connection controller can be instantiated like this:

Calling code example usage

id delegate = self;
myConnectionController* connectionController = [[[myConnectionController alloc] initWithDelegate:delegate
selSucceeded:@selector(connectionSucceeded:)
selFailed:@selector(connectionFailed:)] autorelease];
[myConnectionController startRequestForURL:[NSURL URLWithString:@"http://request.org/somequery.php"]];

You also need to implement the callbacks. These will take the response data and parse it, typically, or handle any error conditions. Although the request is handled asynchronously by the URL Loading System, your callbacks are signalled on the main thread, and you may not want to tie it up parsing large chunks of XML or JSON. Next time I’ll write about using NSOperationQueue to do the parsing in a background thread so the UI remains responsive.

Callback methods

- (void)connectionSucceeded:(NSMutableData*)data {
// data contains response, e.g. JSON to be parsed
}
- (void)connectionFailed:(NSError*)error {
// error contains reason for failure
}

This is a totally trivial example, but you can see how easy it will be to a) define multiple callback handlers for any given class, and thus allowing for multiple NSURLConnections, and b) subclass myConnectionController for specialized request handling. This is what the default implementation looks like:

myConnectionController implementation

@implementation myConnectionController
@synthesize connectionDelegate;
@synthesize succeededAction;
@synthesize failedAction;
- (id)initWithDelegate:(id)delegate selSucceeded:(SEL)succeeded selFailed:(SEL)failed {
if ((self = [super init])) {
self.connectionDelegate = delegate;
self.succeededAction = succeeded;
self.failedAction = failed;
}
return self;
}
-(void)dealloc {
[connectionDelegate release];
[super dealloc];
}
- (BOOL)startRequestForURL:(NSURL*)url {
NSMutableURLRequest* urlRequest = [NSMutableURLRequest requestWithURL:url];
// cache & policy stuff here
[[NSURLCache sharedURLCache] removeAllCachedResponses];
[urlRequest setHTTPMethod:@"POST"];
[urlRequest setHTTPShouldHandleCookies:YES];
NSURLConnection* connectionResponse = [[[NSURLConnection alloc] initWithRequest:urlRequest delegate:self] autorelease];
if (!connectionResponse)
{
// handle error
return NO;
} else {
receivedData = [[NSMutableData data] retain];
}
return YES;
}

And finally, the standard delegate methods for NSURLConnection are hidden inside the myConnectionController implementation. These should be familiar if you’ve ever used NSURLConnection directly:

NSURLConnectionDelegate methods

- (void)connection:(NSURLConnection*)connection didReceiveResponse:(NSURLResponse*)response {
[receivedData setLength:0];
}
- (void)connection:(NSURLConnection*)connection didReceiveData:(NSData*)data {
[receivedData appendData:data];
}
- (void)connection:(NSURLConnection*)connection didFailWithError:(NSError*)error {
[connectionDelegate performSelector:failedAction withObject:error];
[receivedData release];
}
- (void)connectionDidFinishLoading:(NSURLConnection*)connection {
[connectionDelegate performSelector:succeededAction withObject:receivedData];
[receivedData release];
}
@end

That should be enough to get you started. Hopefully you won’t find it too hard to extend this to add the ability to cancel a request, etc.

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site,RSS feed, or Twitter.

3 Years On The App Store

mundue — Mon, 04 Jul 2011 23:00:00 +0000

This week marks the 3rd anniversary of the App Store launch. It sounds, and feels like a lifetime ago. It’s sometimes hard to remember how “unconnected” our lives were before the iPhone, but I can say that prior to June of 2007 I absolutely hated every cell phone I owned. There was the Qualcomm clunker, the Motorola junker, the Samsung clamshell, etc. More often than not the phone was merely a device to slap the carrier’s label on to. People got a “verizon phone,” or an “at&t phone” if you lived in the U.S. We were, and still are, captives of the telcos, but that’s starting to change finally.

When the App Store opened, I dreamed of working for myself. After 26 years of service in academia and Corporate America I was tiring of enormous org charts and meaningless schedules. It took a little bit of time, but in late 2009 I finally quit my last day job. By then we had built up a little stable of apps, and the income was starting to pick up. I’ll never regret that decision, as many indie developers will tell you: once you work for yourself you’ll never want to go back to working for ‘the man’.

Year three on the App Store was an exciting one for us. Mundue apps have now been downloaded a total of 9.2 million times, about 95% of which are free apps. We released two new iOS apps this past year, and are working on a few more at the moment, and also created Mac and Android versions of reMovem. I gave a talk on ad network mediation at the Austin 360iDev conference, and met many new friends there and at other conferences. If you have the opportunity to attend the next 360iDev, this September in Denver, I highly recommend that you do so.

So what will year four be like? I’m very optimistic about the upcoming changes in iOS 5. With the sales of iOS devices still very strong, it looks like the next year or two will be even better for app developers. With over 400,000 apps in the store, the bad news is that your piece of the pie is constantly shrinking, but the good news is that the pie keeps growing ever larger with no slowdown in sight.

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site,RSS feed, or Twitter.

In With the New

mundue — Mon, 20 Jun 2011 18:00:00 +0000

The new shiny is here. At the annual WWDC recently, Apple unveiled three widely-anticipated new products. This year it was all about software, so hardware announcements will have to come later. In the keynote Steve Jobs mentioned OS X Lion, iOS 5, and iCloud. If you’re an iOS or Mac developer these changes will have a huge impact on you in the next few months. I’m not going to go into much detail about the announcements, but you should definitely check out the keynote if you haven’t seen it yet.

The changes in Lion are impressive; I consider it the most significant update since OS X was first released 10 years ago. Developers will want to rev their desktop apps to take advantage of the many new features, like Autosave, Resume, Versions, and Fullscreen. Some of the features we’ve long had on iOS are coming to the desktop in a big way, and this really does fulfill the “Back to the Mac” promise. If you don’t have a trackpad yet, you’ll want one for Lion. Lion’s on the immediate horizon with a scheduled July release.

Similar in scope is the iOS 5 update. Even if you don’t appreciate each of the 200 listed new features, you are going to be impressed with the new Notification Center, Reminders, and, hold the applause, wireless syncing. Billed as PC Free, Apple doesn’t even call this syncing, but it’s supposed to allow for wireless activation, backup, and updating. Although they’ve had some of this functionality on Android for a while, Apple’s superior user experience really shines here.

The game-changer of the three is of course iCloud, long speculated as Apple’s sync service “in the cloud.” But it’s much much more than that. By seamlessly storing data in a central wireless repository and automatically syncing it to all your devices (desktop & mobile), the problem of syncing multiple devices should be eliminated. Like many, I’ve suffered though the pain of MobileMe duplicating and removing contacts, calendar entries, and email settings. With six iOS devices and three Macs sitting in front of me right now, this solution can’t come soon enough. I expect some new breeds of apps designed to take collaboration (with self & others) to the next level. In addition, even for casual games like reMovem it will be easy to save game state so you can start it on your iPod touch and finish the same game later on your iPad.

If iCloud is the glue that holds apps together, then Xcode 4 is the all-in-one tool needed to build them. In order to work with any of the newer SDKs you should already be using a version of Xcode 4. I hesitated for quite some time, mostly because my experience with the early pre-release versions was less than satisfactory. Around the time of the VTM Seattle conference (early April) I made a conscious effort to switch from Xcode 3.2.6 to Xcode 4. Honestly I haven’t regretted it one bit. I know there are some things that don’t work right, but luckily I’m not using the Core Data modeling which is broken. If you do, then I can understand the hesitation.

I’ve been using Xcode 4 exclusively now for 3 months and it’s really a nice improvement in many ways over the previous versions. I’ve used it for a couple of client projects and submitted three of my own apps with it during that time. Once you get over the learning curve, and it is steep, you’ll be happy you made the switch. We’re often asked by new developers, “Where do I start?” Although all of the beginning iPhone development books reference Xcode 3, you’d be better suited to dive into Xcode 4 right away and avoid any uncomfortable transition.

After seeing some of the presentations at WWDC when the Apple folks made Xcode do the almost-unthinkable, it’s clear that its capabilities (now, and planned for the near future) were carefully thought out. Yes it’s a beast, but one you can customize to fit your workflow if that’s your preference. If you’re still on the fence about Xcode 4, I recommend you give it a try soon so you can get on with the new shiny bits. Lion is nearly upon us, and iOS 5 awaits your exploration!

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site,RSS feed, or Twitter.

The Annual Pilgrimage

mundue — Mon, 06 Jun 2011 12:00:36 +0000

The annual pilgrimage to San Francisco is underway this week. I figure I’ve attended about a dozen in the past 21 years. All have indeed been awesome. Many long-time attendees seem to have mastered the week-long partying and a few have even published “survival guides.” My goal is not to get as many free drinks as I can, or to stay awake during the late-afternoon sessions. I’m here to see old friends, make new ones, and absorb the latest installment of greatness from Apple. I came prepared with questions, code problems, and and open mind about what’s next for iOS and OS X. Seeing a live Stevenote will be a bonus.

Yes the conference has grown a great deal since the 1990′s in San Jose. I think there were barely 1,000 attendees that year. But it’s still easy to find people in the crowds or in the streets around the conference center. Most will have iPhones or iPads and Twitter at the ready, and the proliferation of third-party events means you’ll likely run into someone more than once without even trying.

There are an awful lot of To Be Announced sessions at the time I am writing this. I’m not sure what to make of it except that we’re sure to see a few surprises this morning. No, we won’t be getting free iPhones, but around noontime today I guarantee we’ll all be maneuvering to plug in ethernet cables and download the pre-release of [REDACTED].

If you’re not here I’m sure you’re watching a live stream of the day’s events. Hang in there, all will soon be revealed. If you are here and you see me, please say hi!

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Care and Feeding of Your Search Paths

mundue — Mon, 23 May 2011 12:00:00 +0000

I ran into an odd issue the other day and spent a little time getting to the bottom of it. It turns out I wasn’t taking good care of my Xcode project’s library search paths. Here’s what I had to do about it and why you might care. Note this problem has likely been lurking in my project for some months, and may have caused other unintended consequences.

The Symptom

I was in the middle of updating a project with the latest AdWhirl and Millennial Media SDKs. If you are not familiar, the AdWhirl SDK uses the Millennial Media SDK and both have been changed recently to use a newer method in the MMAdView class. This ended up causing a runtime error, followed by a helpful stacktrace:

2011-05-10 17:11:43.105 reMovemFree[1630:707] +[MMAdView adWithFrame:type:apid:delegate:loadAd:startTimer:]: unrecognized selector sent to class 0x118c48

2011-05-10 17:11:43.184 reMovemFree[1630:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[MMAdView adWithFrame:type:apid:delegate:loadAd:startTimer:]: unrecognized selector sent to class 0x118c48'

I puzzled over this for a few hours trying to figure out just why this happened. The headers files were correct, and obviously the project was linking without a problem. At this point I didn’t want to write any more debugging or introspection code, but I was really just looking for a way to find out exactly which methods the class did support. That turned out to be a dead-end anyway.†

The Cause

If you work with 3rd-party SDKs you might be accustomed to taking updates every few months or so. After some time you have probably updated certain libraries many times. I know I do this quite often. Many of you are probably way ahead of me here and can see where this is going. When you (literally) drop in a new SDK, and delete the old one, Xcode adds the new SDK path to the Library Search Paths for the project. Which is fine:

The problem is that Xcode didn’t delete the old SDK from the search paths when I dragged it out of the project. Since the build links with the first version of a library it finds on the search paths, any older version will usually do. Here’s what happens after repeatedly dropping in new versions of SDKs:

So what really happened was that I was linking to the earlier version 4.1.0 of the Millennial Media SDK, not the latest 4.2.4, even though both were on the library search path. This seems like a deficiency in Xcode, since it appears to go to lengths to track external referenced file dependencies.

The Solution

The simple solution for me was to go in and manually prune the old SDK paths from the Library Search Path setting for my project. And of course, add a note in my “todo” list for future updates to take care when adding new SDKs. Unfortunately the Xcode 4 widget for editing the Library Search Path setting is a little funky compared to the Xcode 3 version. I managed to get it shrunk down so small it is barely usable, but with a great deal of patience I was able to find and zap the offending entries.

Incidentally, you may want to take advantage of Xcode’s Source Trees preference, which lets you define an external folder, give it a symbolic name, and refer to in inside your project. This is super handy for two reasons, 1) it dramatically shortens all the nearly-unreadable $(SDKROOT)/../../../etc paths, and 2) it makes code portability to different machines with different folder structures much easier. It turns this:

into this:

Hope this helps a little, even if just to remind you to double-check those Library Search Path settings next time you drop in a new replacement library from a 3rd-party vendor. If you know of a better way to manage this issue, I’d love to hear about it.

† The commandline tool “otool” is great for examining dynamic and static libraries. The problem for me was that I examined the libraries I assumed were linking, not the ones that were actually linking. Looking at the wrong library didn’t help, since it obviously had the right method signatures:

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Prompting for Reviews

mundue — Mon, 09 May 2011 16:00:00 +0000

Like pay-to-play or in-app ads, prompting for a rating is controversial in that some developers frown upon it. Free apps tend to have an average 3 star rating. People rarely bother to go back to the App Store to rate an app. There’s always a small minority that will go out of their way to provide negative reviews. So why not solicit positive feedback by providing a reminder to rate the game? In my opinion, there’s nothing overtly annoying or obnoxious about presenting an alert view that can easily be dismissed.

I rolled my own code to prompt users for a review and the results have been excellent. We’re now getting mostly 4 and 5 star ratings in the prompt-enabled apps. The key of course is in the timing of the prompts. I’ll explain a little about how the code works, then discuss the results so far. For a far better complete code template and explanation see also Noel Llopis’s blog post from last year.

Since the stated objective is to get positive feedback without annoying the user, we want to filter out people who have just launched the app for the first time. One way to do this would be to use a timer, maybe wait until some period of time has elapsed. That’s probably OK, but could lead to a prompt coming up at a truly random time. Instead I have code that checks for two things: time elapsed plus a new high score achieved. To detect a desired length of time, use something like this in your -[UIApplicationDelegate application:didFinishLaunchingWithOptions:] method:

if (![defaults objectForKey:kFirstRunKey]) {

    [defaults setObject:[NSDate date] forKey:kFirstRunKey];

This gives you the timestamp of the first run time. I typically define kFirstRunKey to include a unique version number, so I can record the first run of each update. Now each time a new high score (use whatever criteria you see fit) is achieved, check the current time against the first run timestamp, like this:

- (void) askToRateApp {

 if ( ![self reachable] )

   return;

 NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];

 if ( [defaults boolForKey:kAlreadyDeclinedToRateKey] )

   return;

 NSTimeInterval elapsed = [[NSDate date] timeIntervalSinceDate:[defaults objectForKey:kFirstRunKey]];

 if (elapsed < kAskDelaySeconds ) // approximately 1 day

   return;

Notice a couple of interesting things here. First, I have a Reachability test to exit early if there’s no connection. Second, if the user has previously declined to rate the app, respect that choice and do nothing. Finally, there is a test to see if enough time has elapsed. If not, again do nothing. At this point you could prompt the user, or optionally add more tests. Maybe you only want to prompt on the 17th high score. Then something like this would work:

 NSInteger showAsk = [defaults integerForKey:kShowAskToRateKey];

 // If showAsk is 0, the prompt screen will be shown.

 // If showAsk is > 0, we decrement it now.

 if ( showAsk == 0 ) {

   feedbackAlert = [[[UIAlertView alloc] initWithTitle:NSLocalizedString(@"AskToRateApp",@"") message:nil delegate:self cancelButtonTitle:NSLocalizedString(@"NoThanks",@"") otherButtonTitles:NSLocalizedString(@"RateNow",@""), NSLocalizedString(@"RemindLater",@""), nil] autorelease];

   [feedbackAlert show];

 } else {

   showAsk = (showAsk - 1) ;

   [defaults setInteger:showAsk forKey:kShowAskToRateKey];

In this example, the showAsk variable is tested to see if the counter is zero. If it is, we show the feedback alert. Otherwise we decrement it and store it back in the default settings for next time. Set a reasonable initial value for kShowAskToRateKey. Once the saved value reaches zero, the alert will be shown exactly once. All that’s left to do is handle the buttons on the feedback alert.

- (void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex

  if ( alertView == feedbackAlert ) {

    NSUserDefaults* defaults = [NSUserDefaults standardUserDefaults];

    if ( buttonIndex == 0 ) {

      // No Thanks

      // Don't Ask Anymore

      [defaults setBool:YES forKey:kAlreadyDeclinedToRateKey];

    } else if ( buttonIndex == 1 ){

      // Rate Now...

      // and Don't Ask Anymore

      [defaults setBool:YES forKey:kAlreadyDeclinedToRateKey];

      [self showAppStoreReviewPage];

    } else if ( buttonIndex == 2 ) {

      // Remind Me Later

      [defaults setInteger:21 forKey:kShowAskToRateKey];

    feedbackAlert = nil;

For the “remind later” choice here, I’m resetting the kShowAskToRateKey to 21, but this can be any value you like. I recommend you use analytics or some other method to determine an appropriate measure of how much time is “later.” FInally you need a small piece of code to make the App Store review page show. This technique can be used on iPhone, iPod touch, iPad, and Mac, but on iPad and Mac it is not possible to go directly to the review page. You’ll go instead to the App description and may want to explain how to actually enter a rating or review in those cases.

- (void) showAppStoreReviewPage {

  [[UIApplication sharedApplication] openURL:[NSURL URLWithString:deepLinkReview]];

For the deepLinkReview you will specify the URL that takes users to the application’s review page on iTunes. It’s pretty straightforward to construct the URL manually. Justine Pratt wrote all about this on her blog last year. You can also wrap the URL in a LinkShare link if you are an iTunes affiliate.

So how well does it work? Like Noel I have see an improvement in reMovem ratings from 3.5 stars to 4.5 stars, with about twice as many written reviews per day as there were a year ago. Still, 2 out of 3 users choose not to leave reviews. Of the rest, half opt for the “remind later” choice while about 15% click the “rate now” button. I suspect only a percentage of those actually complete the process, but it’s better than none. It’s debatable whether this leads to more sales, but having more 4 and 5 star reviews certainly helps when people are looking at the App Store description. I also believe they use the number of reviews as a gauge to an app’s popularity, and, in turn, as a data point for their purchasing decision. So the more reviews, the better.

—-

This post is part of iDevBlogADay, a group of indie iOS development blogs featuring two new posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

One of the Good Guys

mundue — Sun, 03 Apr 2011 01:00:00 +0000

We are sad to see that AGON Online is shutting down at the end of June. A couple of years ago when I was researching services for online leaderboards, I decided to use AGON for two of our holiday games. This was an easy choice on my part, because at the time Open Feint and Scoreloop were a little rough around the edges. Both have matured fantastically, of course, and with the advent of Game Center, the folks at Aptocore (makers of AGON Online) have felt the inevitable squeeze of the bigger competitors.

Nevertheless, from the very beginning it was a pleasure to deal with the folks at Aptocore. The system they built was easy to integrate and manage, and the SDK had an excellent Xcode-integrated documentation set. The support team was knowledgeable and courteous, and always very professional. We’ll miss working with them, and wish them well in their future endeavors.

Many developers used AGON in some interesting games. A few of my favorites were: Eyegore’s Eye Blast, Similis Deluxe, Sheepstacker, Popper, Inkvaders, SpringFling, and Azplode. Check ‘em out!

VTM iPhone Seattle

mundue — Wed, 23 Mar 2011 20:00:00 +0000

Soon we’ll be heading to Seattle for the biannual VTM iPhone conference. This two day event will be held the weekend April 9-10, with an optional third day of seminars the day before. This will be my third Voices That Matter conference, and I’m looking forward to some great sessions and seeing old friends again. I’m also very interested in the hands-on cocos2d seminar with Rod Strougo and Ray Wenderlich on Friday. For those new to Cocoa and Objective-C there’s also a full-day session with the Big Nerd Ranch guys Aaron Hillegass and Joe Conway.

Most of the presenters at VTM are authors and experts on iOS development, which leads to the motto of “learn from those who wrote the book.” There’s a fun vibe at VTM, although I wish it were longer than 2 days, and Seattle is great in April, so this is a great opportunity to meet and hang out with other iOS developers. Since we’re driving up from Colorado this also offers the opportunity of a road trip across a part of the US that we’ve never seen.

It’s not too late to register, and discounts are still available, so, hope to see you there!