Quick Wipe of iOS Simulator Using Alfred

When I am rapidly prototyping new features, I frequently need to blow out the entire app structure from the simulator and start fresh.

To do this manually, I would follow the following steps.

From Simulator (when simulator is open)*:

1. Go to Menu Bar
2. Click iOS Simulator
3. Click Reset Content and Settings

Benefits of this approach:

• Easy to do/remember
• Blows out all settings and apps

Drawbacks to this approach

• Destroys ALL content, including any general settings
  • I frequently need to test something more complex, like uploading images. I will save images to the simulator by going to Safari on the simulator and saving images form the web for use in the simulator’s photo library. Using the Reset Content option destroys all of this data and it has to be recreated.
• Simulator must already be running to reset settings

From Finder

1. Go to path: ~/[user]/Library/Application\ Support/iPhone\ Simulator/[SDK Version]/Applications
2. Delete all folders in the Applications folder

Benefits of this approach

• Deletes apps from simulator without wiping settings

Drawbacks to this approach

• Very manual, even when you have a sidebar shortcut set up in the Finder

My solution: Alfred Simulator Wipe

I love the application Alfred. Alfred is an extremely useful app that started its life as an application launcher, and has evolved into a swiss army knife that is ultimately customizable and expandable. When I get on any Mac and hit ⌘-space and see Spotlight instead of Alfred, I know my productivity will be less than normal. One of the best features of Alfred is the ability to create custom shell/Applescript extensions and run them from the app with a keyword (The devs just added the ability to pipe input into these scripts with v1.2, but I haven’t had a chance to play with it yet). This is the technique I used to automate the majority of this simulator wipe process (You have to have purchased the PowerPack to take advantage of extensions). Here is how to create an Alfred extension to wipe your Simulator applications:

1. Download Alfred

2. Open Alfred Preferences (with Alfred open, hit ⌘,)

3. Click the ‘+’ button at the bottom left of the window:

   

4. Select AppleScript

5. Enter an Extension Name. Other details are optional

6. To make it look nice in Alfred, you can drag in an icon that will be displayed in the app when the keyword is invoked

7. Enter a title and description

8. Pick a keyword that Alfred will use to launch the script

9. Check the ‘background’ box (This allows the script to run and not block Alfred until it completes)

10. Use the following code in the AppleScript field:

    tell application “Finder”
    delete (every item of folder “[Drive]:Users:[user]:Library:Application Support:iPhone Simulator:5.1:Applications”)
    end tell
    

11. The iOS simulator uses a separate directory for each installed SDK. For each iOS SDK on your system (I have 3), add a new line to delete that Simulator’s installed apps. You would simply copy the delete line above and change [5.1] to a different folder name.

12. Click the Save button when you’re done

13. Invoke Alfred, then type in the keyword you set up to run the extension

14. You should wind up with something like you see below

Alfred Screenshot

This will easily wipe out your simulator apps without destroying any data in the simulator itself. It’s also a lot easier than going through the Finder every time. I’m linking to an export of the extension below. Please let me know in the comments if you are doing anything similar or you can think of any improvements!

Alfred Simulator Wipe Extension

Persisting Data Using the Plist Format: Part 2/2

This is a follow up to my previous post on persisting PList data to disk as a form of transient storage for data. This second part will just show an easy way to pull that data from disk and get it into memory in an easily usable format.

All of our Plists are stored as dictionaries. The keys for the dictionaries are stored as constants in a code file (Constants.h/.m). This allows for compiler time checking and keeps us from having to litter our code with magic strings when trying to access the values.

Here is a sample workflow to get this method up and running:

The PList Data

Assuming we have a plist that contains the following data:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>firstName</key>
    <string>Mark</string>
</dict>
</plist>

Create a Constants File, and Always Use It

Create a Constants file, and add all keys to it as const NSString. Be strict and only reference these keys when attempting to access data from your NSDictionaries. Don’t shortcut and put the strings directly into your code. Here is an example of how I have this set up:

Constants.h

#import <Foundation/Foundation.h>

@interface Constants : NSObject

extern NSString * const DICT_KEY_FIRST_NAME;

@end

Constants.m

#import "Constants.h"

@implementation Constants

NSString * const DICT_KEY_FIRST_NAME   = @"firstName";

@end

Add your Constants file to your pre-compiled headers file so it is available everywhere

Adding files to your pre-compiled headers makes them available everywhere in your project without having to import each specific class header in the file where you’re trying to use it. Use this convenience judiciously, and only for classes that you truly think you’ll need everywhere. I always include my Constants file in the pre-compiled header to ensure I can access it without having to import it everywhere.

You can find your pre-compiled header file in the Supporting Files group in your project navigator in XCode (if you haven’t moved it). It is typically named {projectname}-Prefix.pch, where {projectname} is the name of your project. At the bottom of this file, you can add #import statements for the header fields you are interested in. Your file should look something like this:

//
// Prefix header for all source files of the 'FeverMonitor' target in the 'FeverMonitor' project
//

#import <Availability.h>

#ifndef __IPHONE_3_0
#warning "This project uses features only available in iOS SDK 3.0 and later."
#endif

#ifdef __OBJC__
    #import <UIKit/UIKit.h>
    #import <Foundation/Foundation.h>
    #import <CoreData/CoreData.h>
    #import "Constants.h"
#endif

The import statement you’re interested in the last one. Make sure you add it inside the #ifdef__OBJC__ block.

This adds an #import statement for each file at compile time which includes these files throughout your entire project. It will also update XCode’s autocomplete indexing so that you are able to use autocomplete for the code on the imported files.

Pull your file from disk, and use the constants defined

Here is an example of how we could wrap this all up and pull some data from a plist file already on disk:

    NSString *filepath = [self convenienceMethodToGetFilePathForPlist];
    NSDictionary *resultsDict = [NSDictionary dictionaryWithContentsOfFile:filepath];
    NSString *firstName = [resultsDict objectForKey:DICT_KEY_FIRST_NAME];

    NSLog(@"First Name: %@",firstName);

Note above that you will need a way to get the plist file path before being able to access it. Also note that I prefix the string constant with DICT_KEY. I do this so that as my constants file grows, I can easily locate the value I’m looking for by typing the prefix I’m looking for.

Well, that wraps up this segment. As a caveat here, I’d like to mention that this data storage methodology, in my opinion, would not scale to larger data sets. You should definitely consider using Core Data for the majority of your data storage scenarios. We decided to use the PList format in this case because the data was transient, and was going to be wiped out on each subsequent change to it.

Persisting Simple Data Using the Plist Format

Recently, we had the need to save some simple transient data to disk. For data of any significant size, we would have looked at Core Data for our persistence. In this case, we decided to use the PList format to save data to disk and pull it back off. We went through several ideas to store this data.

Some of the ideas we considered for persistence included:

• Core Data
• JSON saved in a flat file format
• PList saved directly to disk from a Cocoa object such as an NSArray or NSDictionary

Because of our specific set of requirements and our hardware stack, we opted to go with the PList format. Our main driver for this decision was the amount of control we have over the response format from the server. Since we control our servers and their output, we are able to specify PList as a return type. We use the excellent AFNetworking library to perform our networking tasks.

The AFNetworking library has a request named AFPropertyListRequestOperation.* This operation will take an NSURLRequest and return an id that can be cast to a native Cocoa object, such as an NSDictionary or NSArray. Because we know the object’s return structure, we directly cast our object and move on to processing it. From there, it is just a matter of using the writeToFile:Atomically method to persist to disk.

Here is an example workflow:

NSString *urlString = @"http://api.responder?format=plist";
NSURLRequest *urlRequest = [NSURLRequest requestWithURL:[NSURL urlWithString:urlString]];
    AFPropertyListRequestOperation *operation = 
    [AFPropertyListRequestOperation propertyListRequestOperationWithRequest:urlString success:^(NSURLRequest *request, NSHTTPURLResponse *response, id propertyList) {
            // Cache the response
        NSDictionary *responseDict = (NSDictionary *)propertyList;
        NSArray *pathArray = NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES);
        NSString *cachesPath = [pathArray lastObject];
        NSString *filePath = [NSString pathWithComponents:[NSArray arrayWithObjects:cachesPath,@"responseDict.plist",nil]];
        BOOL success = [responseDict writeToFile:filePath atomically:YES];
        if(!success){
            // Handle error
        }        
    } failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id propertyList) {
        NSLog(@"API Call failure: %@",[error localizedDescription]);
    }];

One caveat here is to be careful that your dictionary is properly formatted when being returned from the server, and when attempting to save to disk. Initially, we had some bugs when nulls were encountered as a response from the server for specific values. The server parsing logic would simply not generate a value for the key if the value was null. In PList format, this is unacceptable syntax. If you tried to save this to disk, the call would fail and return NO from the writeToFile: method.

For my next post, I’ll do a quick follow up on how to pull the data back off of disk and get it into a usable format in memory.

*Please note that the headers returned from the server must specify application/x-plist data format. The AFPropertyListRequestOperation will check for this in the header and fail the request if it is not present.

Goodbye, Steve

I didn’t become an Apple user until a few years ago. I came to the platform out of curiosity. I bought myself a Macbook to start teaching myself how to code iOS apps. I quickly found myself amazed at the ingenuity and simplicity of the entire platform. It was the way everything tied together, and always seemed to work in the way you expected. The more I lived in the Apple world, the more impressed I became. In 3 years, I have gone from using Apple’s products as a hobby to a full time developer on their platform. For the first time in my life, I have questioned that someone actually pays me to work on this stuff. I guess if you ask yourself that question, you are doing the right thing with your life.

I was surprised and saddened to hear of Steve Jobs’ passing tonight. He truly made a difference in our world with sheer will and by questioning everything. His stamp is all over these products we all use every day for entertainment and for work. His drive and determination produced these incredible products and services which set the standard for excellence in technology.

A quote out of the recent statement by President Obama on Steve Jobs’ passing struck me as particularly apt:

“The world has lost a visionary. And there may be no greater tribute to Steve’s success than the fact that much of the world learned of his passing on a device he invented.”

I was glad to hear he passed peacefully and with his family.

Rest in peace, Steve. Our world is a little less without you in it.

Quick Xcode 4 Tip: Deleting Derived Data to Rescue Code Completion

Quick Tip:

I had an issue on a very large project in XCode. Starting 2 days ago, all of my syntax highlighting was completely broken. This is bad, but even worse, my code completion worked only partially. I was getting autocomplete for local variables only. When calling framework methods with a lot of parameters, I rely pretty heavily on code completion. I tried all of the usual fixes. This includes:

1. Doing a Project Clean (⌘⇧K)
2. Doing a Clean Build Folder (⌥⌘⇧K)
3. Restarting XCode

None of these solutions fixed the issue. After some digging, I came across this StackOverflow Post which pointed me in the right direction. Seems like sometimes the project index, which contains metadata used to display code completion suggestions (among other things), can become corrupted. The solution is to delete it. This will force XCode to regenerate it, which rebuilds the index.

Here are the steps to delete your Derived Data folder.

1. Go to XCode Settings (⌘,)

2. Click the Locations tab. You will see a screen like this:



3. Click the small arrow next to the location of the Derived Data folder. This will open the Finder to the location of the Derived Data for any XCode projects you currently have on your Mac.

4. Find the one that starts with the name of your current project and delete it.

5. You should immediately see XCode start to re-index your project

For me, after this process completed, I got all of my functionality back. Your mileage may vary, and please make sure you back everything up before deleting anything!