Devins Heaven

Instruments, Xcode’s tool to track and analyze your application’s process, has a cool little feature that lets you turn your iPhone’s screen into a sea of red and green that came straight out of Microsoft Paint. To turn this little feature on, open up instruments and create a Core Animation instrument for the iPhone. Click on the detail view icon in the bottom left of the window, and a bunch of debug options will pop up. Check the Color Blended Layers box. Now you have a good April fools prank, but this view is actual helpful when it comes to optimizing your iPhone animation performance.

The key to this color blended layers is simple – green is opaque (good), red is transparent (bad). If your application has a table view, and you are scratching your head wondering why the table doesn’t scroll like butter, look no further than this filter (okay, make sure you reuse cells too). If you can turn your views from transparent to opaque (turning red to green) you’ll notice your table start to scroll a lot smoother. Tuning your application to animate with ease is an acquired skill. You really have to play around and see what will run smoothly. Of course, there are pros and cons to many decisions you’ll make. In terms of animation performance, the more you eliminate transparency, the greater the performance.

label.backgroundColor = [UIColor clear]; // this is not your friend

Attic was published to the App Store this week. If you haven’t already go pick up a copy . Here is a hidden quick tip for revealing usage information. Double tap an album to reveal the information – the last time the album was played, number of songs on an album, and average play/skip count of album’s songs.

I happy to announce the shipping of Attic [iTunes Link]. Starting today, March 1st, you can find Attic on App Store shelves everywhere for $1. In a nutshell, Attic is a super cool music controller for playing those old dusty neglected albums in your iTunes music collection. Plain and simple. To mark the launch, I’ve got a few new articles written to publish this week. I’ll also be sharing my experiences promoting the application and everything that comes with that. I’ve got other exciting things in the works I’d like to share, but I’ll keep quiet on those things in the mean time.

I’ve been working hard to prepare my application Attic for launch on the App Store. Most recently, I’ve been working on squashing any last minute bugs and localizing the application for different languages. I’m happy to say that testing the application now consists of acting like a 2 year-old pressing the screen in randomly until something breaks. I’ll be writing about all promoting the application and more once the application finally is published, so stay tuned. I’ve been working on other big projects as well that I will share more information on in the coming weeks.

Time Keeper (TK) is an application that allows athletes to record their times for swimming, biking and running. On the onset, I thought TK would be an application to compete with Nike Plus or even the Run Keeper application, but I realized TK is aimed differently than these solutions. While products like Nike Plus record a person’s running, these solutions don’t call for a person to run a specific distance. Time Keeper is predicated on a person running, swimming or biking a specified distance whether that be a 10 laps, a 1 kilometer or 40 yards. They can then track their progress, see their average times and see best times.

Pop Apps vs. Niche Apps

After a few months on the App Store shelves, Time Keeper hasn’t gotten a boat load of downloads. Currently the application gets around 10 downloads a week. This is fine though because the application isn’t a “pop app”. Its not intended for a large audience because not everyone will find it useful. The small group of people who have downloaded the application have given a great response for the application. I received emails from people in various situations –  a student who runs track in high school uses TK to record his times for events that he competes in, a man who records swimming times for his daughters at competitions. These are the situations I imagined Time Keeper being used for, and they have  slowly materialized into reality. For that reason, I find Time Keeper a successful application despite not having a ton of sales. The price of the application also reflects the realization that not everyone will be in the market to purchase the application.

Getting Feedback

Because the application has a higher price than many applications, I wanted to assure users that I’d be able to provide assistance to their problems and listen to their suggestions. A swimmer suggested that times should be recorded to not just the tenth of a second, but to the hundredth of a second. Soon after I implemented this change into the application. I wanted to create an avenue so that users could supply feedback and limited the barrier that might stop a customer from supplying feedback. From day 1, I setup a Get Satisfaction account for the application and allow users to email me feedback directly from the application.

App Store’s Role

Despite the grumblings of the App Store, the way apps are distributed on the iPhone makes it possible for niche apps to get sales. As a developer, I haven’t had to advertise the application or setup my own payment system. Consumers also can trust that when they purchase an application that it has been vetted and they won’t be scammed. Consumers don’t need to hassle with entering their information each time they want to purchase an application. The App Store simply gives niche applications more credibility and exposure.

The iPhone SDK provides developers with a sophisticated framework to build apps. The SDK doesn’t have everything though, and now that the NDA agreement has been lifted, developers can share their own frameworks. I’ve highlighted some of the popular frameworks available on the web. Why reinvent the wheel when someone already has?

• Three20 by Joe Hewitt. Hewitt wrote this library as a result of developing the Facebook iPhone application. Despite the popularity of the facebook application and the framework, he has sign said he’s done developing applications for the iPhone. This library is very extensive, but Photo Thumbnail browser and tab interface (like the Facebook application) stand out.
• Twitter Engine by Matt Gemmell. This engine will have you grabbing twitter messages and parsing twitter information in no time. The engine is built to be used for Mac and iPhone applications. Popular applications like Twitterific take advantage of the engine in their own application.
• FontLabel. The iPhone only comes equipped with a small list of fonts installed on the iPhone. With FontLabel, you can include .tff font files inside of your application resources and use the font like it where any old font in the application.
• Tapku Library. Call me bias for pointing out my own library, but I think this framework has some useful classes to help development. Update: I’ve recently added a coverflow class, along with a calendar and graph views.
• SciFiHiFi by Buzz Anderson. This framework is a small bunch of utility classes for UI and security. The UI portion has classes for loadingHUD and cells classes for showing activity and editing. The security class allows you to add usernames and passwords to the keychain.
• OpenFlow. This framework replicates the cover flow API that you see in applications like the iPod/Music app. Apple doesn’t provide a cover flow view in the SDK itself, so this framework comes in handy.  (Check out my implementation of coverflow in the Tapku Library)

If you know of any iPhone or mac frameworks of note, leave a comment below. Frameworks are really valuable to the community because they build on an already powerful SDK. The more developers can contribute, the better applications become and the more powerful application can become.

The iPhone product line hasn’t stagnated since the first iPhone and iPod Touch have been released. Devices offer different capabilities over each iteration and each iPhone OS version offers different APIs. In short, your application has to detect against a cornucopia of devices and operating systems. You’re first inclination might be to use the UIDevice class to check which device and OS version is installed. This means you have to remember when certain APIs were added and which device have which feature. Instead, you can check the presence and capabilities of a framework by asking for the framework class outright in your code. Apple has implemented class methods in each API to tell if the device has the specific functionality you are looking for. Here are a few example using the mail and camera capabilities:

Mail Composition

There might be a time when you need to send out a message through email. In versions prior to iPhone OS 3.0, you had to specifically open the mail application to access send an email. Now in iPhone OS 3, if a user has set up their account, you, as a developer, can imbed a modal view to send emails.

Class mailClass = (NSClassFromString(@"MFMailComposeViewController"));
// We must always check whether the current device is configured for sending emails
if (mailClass != nil && [mailClass canSendMail])
{

	[self displayComposerSheet];

}else{

	[self launchMailAppOnDevice];

}

Camera Capabilities

There isn’t a camera in the iPod Touch, but that doesn’t mean there won’t be one in the future. If your application checked whether the device was an iPhone or iPod Touch, and Apple released a iPod Touch with a camera, your app would be inaccurate. With this code below, you don’t have to worry about new devices in the future.

Class photoClass = NSClassFromString(@"UIImagePickerController");
// Check is the device has a camera...
if(photoClass != nil && [photoClass isSourceTypeAvailable:UIImagePickerControllerSourceTypeCamera])
{

	NSLog(@"Camera Ready");

}else{

	NSLog(@"No camera");

}

“It’s spam”, “It’s annoying”, “Nobody uses email anymore”. Before getting huffy and puffy about email marketing, I assure email marketing can be used to easily manage a project (and leave you grinning like the monkey). Hopefully I’ll have convinced you to try Mail Chimp or some other service when you manage your iPhone project by the end of this article for some reason or the other.

I haven’t used Mail Chimp for too long, but its a great free(mium) service. When I first signed up, I was a bit scared and confused by the site, but they have well put together videos and even free service chat as well. Having said that, Mail Chimp is a really powerful way to manage contact lists, and then send out emails, HTML-rich or plain, to a large group of people. Now I’ll go into a few cases where you might find launching your next iPhone project a whole lot easier…

Beta Testing

One step developers should take before releasing an application is to beta-test. This means seeding a build of your application to up to 100 different people. With all the permissions you have to jump through to release an adhoc build, it can be a daunting task to manage 100 UDID strings and entering the information into the developer portal page. Using Mail Chimp’s sign up form, you can create a custom form that allows your beta-testers to enter in their information along with their devices UDID. After people have signed up, you can export your new list of beta testers, and upload the data into the developer portal to add those devices. You can then use Mail Chimp to email the provisioning profile and the adhoc build to distribute the application so testers can try out the application.

Friends & Family

Whenever you publish a new application, you want to hook up your friends and family with a free copy. Again, if you have a lot of people you want to give the app to, this can be a long process. You’ve got to remember everyone you want to send a promo code to, request the codes, make sure each person gets their own unique one. With Mail Chimp, you can take a care of that easily. After you’ve entered in your friends email address and info, you can append a new field called Promo. Download the excel spreadsheet (from the list tab, go to “view list”, then go to the “view all” page) of the contact information and request the necessary number of promo codes from iTunes Connect. Copy and paste the promo codes into the correct column in the excel spreadsheet, and import the data back to Mail Chimp. Make sure you check the box to auto-update so you don’t recreate the data. Finally, you can send one email with each person receiving their individual promo code using the *|PROMO|* in the email contents.

Fans & Potential/Previous Customers

Okay, call me crazy, but you can use MailChimp for regular email marketing campaigns too. Many iPhone developers utilize this tactic to target their audience to push sales. Notably, 1Password and TapTapTap have used emails to send out information on current and new applications. People can sign up, and you can send out updates and news about your application. Of course, MailChimp makes it for people to unsubscribe from the email list just as easy as they signed up for the email.

Accessing data, whether it be a from the iPhone’s memory or even from the internet is a necessity of almost any application. This article will overview some of the basics to access and saving files that your iPhone (or Mac) applition might need to do sometime or the other. The best

Directory Access

NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *basePath = ([paths count] > 0) ? [paths objectAtIndex:0] : nil;
NSString *filePath = [basePath stringByAppendingPathComponent:@"filename.plist"];

Using Plists

The Plist file format is the best format to use when reading and writing to the iPhone’s disk. Not only is it faster (because it is native) than XML, JSON and a plain text file to read, but the code is really simple.

NSDictionary *dictionary = [NSDictionary dictionaryWithContentsOfURL:filePath];
//or
NSArray *array = [NSArray arrayWithContentsOfURL:filePath];

Then to save you data to a file:

// plistDict is a NSDictionary
NSString *error;
NSData *plistData = [NSPropertyListSerialization dataFromPropertyList:plistDict  format:NSPropertyListXMLFormat_v1_0 errorDescription:&error];
if(plistData) {
     [plistData writeToFile:filePath atomically:YES];
} else {
     NSLog(error);
     [error release];
}

Play Nicely!

Where you save your files are important for when the iPhone backups information to a computer. You want to make sure your application backup is as small as possible so you need to place information in there specific directory.

1. NSDocumentsDirectory- This data is backed up every time a user syncs their information to their computer.
2. NSCachesDirectory – This information is not backed up by syncing, but not lost once your application quits. This space is ideally where you’d want to save state information. For example, in a text messaging application, you’d might want to save the string the user entered into the application, but had yet to sent out. You definitely don’t want to back this information up, but it will be needed when the application is opened again.
3. NSTemporaryDirectory – This data is lost after your application is terminated.

If you’re are like me, you name classes, variables and methods poorly from time to time. You’ll look back on a piece of code at a latter date and scratch your head over the way you call certain functions. Whenever I create a new project, I hate the fact the Xcode names the application delegate class with the project title as a prefix for the class name.  I take the time to rename the .h and .m files, the declartion, and implementation… and don’t forget about that Nib file. These days of painstakenly renaming across an entire application are gone with Snow Leopard and Xcode 3.2. Enter Refractoring!

Select the string you want to replace in a file somewhere in Xcode. In this case its the application delegate class name.

A dialogue box will pop up. Enter the string of how you want the class to appear, and hit preview. It will show you which files will be modified. After hitting Apply, presto and everything is renamed.