NSDate *myDate = [NSDate date];

But if you want to create a date object with a date such as your birthday it gets a little bit trickier, and – more importantly – much less obvious.

To do this, we need to create an NSDateFormatter, tell the formatter how to expect the date, and then use its convenience method dateFromString to create the date:

NSDateFormatter *formatter = [[NSDateFormatter alloc]init];
formatter.dateFormat = @"YYYY-MM-DD";
NSDate *myDate = [formatter dateFromString:@"2012-12-12"];

Notice that I tell the date formatter to expect the date as YYYY-MM-DD. I could also have told it to expect it as YYMMDD and then pass @”12-12-12″ in the dateFromString method.

Whichever way you do it, the date format must match your string, otherwise the method returns null.

All we need to do this is our good friend the NSDateFormatter and the Unicode Date Format MMMM – let’s check it out:

// create today's date
NSDate *myDate = [NSDate date];
// create a date formatter and set its format
NSDateFormatter *formatter = [[NSDateFormatter alloc]init];
formatter.dateFormat = @"MMMM";
        
NSLog(@"The current month is %@", [formatter stringFromDate:myDate]);

The MMMM tells the date formatter to display the full month, no matter how many letters it has. You can also use:

• M for the month number (1 for January or 12 for December)
• MM for the two-digit month number (01 for January)
• MMM for the abbreviated month number (Jan for January)
• MMMM for the full month number (such as January)
• MMMMM for just the first letter (J for January… not sure who would need this though)

The Unicode Date Format can do amazing things with all aspects of times and dates – check out the complete compendium here:

http://unicode.org/reports/tr35/tr35-6.html#Date_Format_Patterns

Lucky for us we don’t have to use their interface to get links to iTunes Products – we can use the standard good looking and well working iTunes Link Maker. All we need is go there via LinkShare, which will embed our affiliate code.

Here’s how to do this step by step:

1.) Login to LinksShare and see the awful Home Screen
2.) Head over to Links – Get Links
3.) Click on “US iTunes, App Store, iBookstore, and Mac App Store” (you need to be subscribed and approved for this option to become available).

This should get you to a screen similar to this:

4.) Notice the grey button that says “Link Maker Tool”. Click that and you get to a new window and is the familiar iTunes Link Builder, as provided by Apple:

Note the message that reads: “Your affiliate Network is…” – this is the confirmation that you’re building links as an affiliate. If that message isn’t there, your links are not tracked. Instead if LinkShare, this can be a different partner (TradeDoubler is another one for example).

Now you can enter a product and grab the link, which will already contain your affiliate ID.

Turns out it’s equally simple: this example assumes you have a View Controller which is embedded in a Navigation Controller (so it already has a UINavigationBar at the top). Here’s how you add a button to it, set the title and target, and tell it what to do when it’s pressed:

- (void) viewDidLoad
{
    [super viewDidLoad];
	
    // first we create a button and set it's properties
    UIBarButtonItem *myButton = [[UIBarButtonItem alloc]init];
    myButton.action = @selector(doTheThing);
    myButton.title = @"Hello";
    myButton.target = self;
    
    // then we add the button to the navigation bar
    self.navigationItem.rightBarButtonItem = myButton;
    
    
}


// method called via selector
- (void) doTheThing {
    
    NSLog(@"Doing the thing");
    
}

You can set the button on the left hand site by using self.navigationItem.leftBarButtonItem

Thankfully there is a way to delete version files which goes a long way to declutter your brain. The secret lies in the fact that the .xcdatamodeld file is actually a Package and can contain more than one file. It’s like the .app extension which isn’t just one file. I never knew this!

To explore, select your versioned .xcdatamodeld file, right-click it and select “Show in Finder”. Once in there right-click it again and select “Show Package Contents”. Surprise – here are all your Model Versions. Before you go on a mad deleting spree, head back to Xcode and do the following:

1. activate a Model Version that you want to keep (by going to the top level .xcdatamodeld entry, then select it under “Versioned Core Data Model”)
2. next remove the entire file from your project (just the reference… do not move to trash)
3. head back to the Finder and delete the files inside the Package you no longer want
4. go back to Xcode and add the .xcdatamodeld file again

Voila – now all your unnecessary Model Versions are gone. Perhaps in a future version of Xcode there will be an easier way to do this, but as of Xcode 4.6.2 (April 2013) there is not.

Further Reading

Thanks to David Avendasora for this wonderfully simple explanation on Stack Overflow: http://stackoverflow.com/questions/7708392/how-to-delete-an-old-unused-data-model-version-in-xcode-4

Sometimes however we need to create and transition to View Controllers we’ve defined in code. For example, if you want to transition to a view as part of displaying a search result.

We can do this by creating a new UIStoryboard object and then asking it to create a View Controller defined in it. For this to work you need to give your View Controller a unique identifier using the Identity Inspector (under Identity, set a Storyboard ID).

This example assumes we have a Storyboard file called MainStoryboard.storyboard in which there’s a View Controller called DetailView. Here’s how we create it and push it onto a stack of Navigation Controllers:

// create the Storyboard object
UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"MainStoryboard" bundle:nil];
DetailViewController *detailView = [storyboard instantiateViewControllerWithIdentifier:@"DetailView"];

// set properties you'd like the detailView to have (optional)
detailView.someProperty = @"This is great";

// push the new detailView onto the stack
[self.navigationController pushViewController:detailView animated:YES];

Note that you define the Storyboard without its extension. If the bundle parameter is nil (as it is here) then the compiler assumes your main bundle.

This example assumes you have a Table View (self.tableView) to which you’d like to add a Search Bar and Search Display Controller at the top. We do this by utilising the Table View’s tableHeaderView property:

// create a new Search Bar and add it to the table view
UISearchBar *searchBar = [[UISearchBar alloc]initWithFrame:CGRectMake(0.0f, 0.0f, 320.0f, 44.0f)];
self.tableView.tableHeaderView = searchBar;
        
// we need to be the delegate so the cancel button works
searchBar.delegate = self;
        
// create the Search Display Controller with the above Search Bar
self.controller = [[UISearchDisplayController alloc]initWithSearchBar:self.searchBar contentsController:self];
self.controller.searchResultsDataSource = self;
self.controller.searchResultsDelegate = self;

Your View Controller also needs to conform to the UISearchBarDelegate Protocol for this to work properly.

Most commonly you’ll want to call a URL with parameters which will return some data. You take this output and tell Objective-C that it’s JSON, then typecast the return to an array or a dictionary which in turn lets you access the data. It’s genius!

Here’s an example:

// create the URL we'd like to query
NSURL *myURL = [[NSURL alloc]initWithString:@"http://domain.com/jsonquery";
        
// we'll receive raw data so we'll create an NSData Object with it 
NSData *myData = [[NSData alloc]initWithContentsOfURL:myURL];
        
// now we'll parse our data using NSJSONSerialization
id myJSON = [NSJSONSerialization JSONObjectWithData:myData options:NSJSONReadingMutableContainers error:nil];
        
// typecast an array and list its contents
NSArray *jsonArray = (NSArray *)myJSON;
        
// take a look at all elements in the array
for (id element in jsonArray) {
    NSLog(@"Element: %@", [element description]);            
}

What you’ll get back depends on your individual JSON structure of course. This can be quite complex, for example you could receive an array full of dictionaries, each of which could be full of dictionaries. JSON data can be mapped to an NSArray, NSDictionary, NSNumberand NSNull.

Once you have access to the top level elements you can then loop through each one, examining what’s in it and access what you need.

Further Reading

• More details about the JSON Format: http://www.json.org/
• NSJSONSerialization Class Reference: http://developer.apple.com/library/ios/#documentation/Foundation/Reference/NSJSONSerialization_Class/Reference/Reference.html
• JSONKit Framework: https://github.com/johnezang/JSONKit

Some of Apple’s pre-written methods use whats known as a Selector. Here’s an example method that uses a selector:

// create a bar button item
UIBarButtonItem *linkButton = [[UIBarButtonItem alloc]initWithTitle:@"My Title" style:UIBarButtonItemStyleBordered target:self action:@selector(myMethod)];

Notice how the selector is created on the second line. All it wants to know here is the method name really. Imagine you had a method called myMethod in the current class (hence the use of self here), this is how it gets called via the action parameter.

If you were to call this method just by itself, you’d use the usual

[self myMethod];

For more information and how to build your own selectors, check out the Cocoa Core Competencies section on Selectors.

    NSString *complete = @"12345";
    NSString *cutOff = [complete substringFromIndex:1];
    NSLog(@"%@", cutOff);
    // cutOff is now 2345

substringFromString takes only one parameter which specifies where to start the new string. The first character is 0 based, like in arrays. The parameter can’t be longer than the original string’s length for obvious reasons.

Here’s how you can retrieve one of those in code:

    // create a fetch request from template
    NSFetchRequest *fetchRequest = [self.managedObjectModel fetchRequestTemplateForName:@"MyFetch"];
    
    NSArray *fetchedObjects = [self.managedObjectContext executeFetchRequest:fetchRequest error:nil];
    for (Event *event in fetchedObjects) {
        NSLog(@"%@", [event.timeStamp description]);
    }

Note that to retrieve your Fetch Request Template you need a reference to your Managed Object Model as well as your context. The easiest way to grab hold of it in an iOS app is to pass it in on a property, just like we did with self.managedoObjectContext.

Let’s first illustrate a basic NSFetchRequest. For the following examples I’m using the iOS Master/Detail template which provides an Entity called Event with a property called timeStamp. I’ve created custom subclasses for this entity. Press the add button a few times so we have some data, then quit the application.

Basic Fetch Request

Here’s how we can retrieve all our values using a basic Fetch Request:

    // create a fetch request
    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Event" inManagedObjectContext:self.managedObjectContext];
    [fetchRequest setEntity:entity];

    // fetch all objects
    NSError *error = nil;
    NSArray *fetchedObjects = [self.managedObjectContext executeFetchRequest:fetchRequest error:&error];
    if (fetchedObjects == nil) {
        NSLog(@"Houston, we have a problem: %@", error);
    }

    // display all objects
    for (Event *event in fetchedObjects) {
        NSLog(@"%@", [event.timeStamp description]);
    }

The easiest way to get this code is by using a code snippet from the Xcode library (search for fetch, the first one is a “basic fetch”).

Note that the results are unfiltered, which means they’re not necessarily in the order you would like them to be in. To remedy this, you can use a Sort Descriptor:

Fetch Request with Sort Descriptors

    // create a fetch request
    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Event" inManagedObjectContext:self.managedObjectContext];
    [fetchRequest setEntity:entity];

    // define a sort descriptor
    NSSortDescriptor *descriptor = [[NSSortDescriptor alloc]initWithKey:@"timeStamp" ascending:YES];
    NSArray *scArray = [[NSArray alloc]initWithObjects:descriptor, nil];

    // give sort descriptor array to the fetch request
    fetchRequest.sortDescriptors = scArray;

    // fetch all objects
    NSError *error = nil;
    NSArray *fetchedObjects = [self.managedObjectContext executeFetchRequest:fetchRequest error:&error];
    if (fetchedObjects == nil) {
        NSLog(@"Houston, we have a problem: %@", error);
    }

    // display all objects
    for (Event *event in fetchedObjects) {
        NSLog(@"%@", [event.timeStamp description]);
    }

You can pass more than one Sort Descriptor, hence we need to pass an NSArray to the fetch request. A usage example would be “list all employers alphabetically, in order of which they’ve started working”. To do this, create another sort descriptor, then add both to the array.

The easiest way to get this is to use the Xcode Code Snippets again, this time select the “fetch with sorting” and it will have all this code ready for you.

Fetch Request using a Predicate

Predicates are filters with which you can specify conditions, such as “is this date older than x”, “does the first name contain steve”, and so forth. I have written a more in-depth article on Predictates elsewhere on this site and won’t go into the details.

Here’s how you create a Fetch Request with a Predicate, combined with a Sort Descriptor:

    // create a fetch request
    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Event" inManagedObjectContext:self.managedObjectContext];
    [fetchRequest setEntity:entity];
    
    // setup a predicate
    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"timeStamp < %@", [NSDate date]];
    
    // give the predicate to the fetch request
    fetchRequest.predicate = predicate;
    
    // define a sort descriptor
    NSSortDescriptor *descriptor = [[NSSortDescriptor alloc]initWithKey:@"timeStamp" ascending:YES];
    NSArray *scArray = [[NSArray alloc]initWithObjects:descriptor, nil];
    
    // give sort descriptor array to the fetch request
    fetchRequest.sortDescriptors = scArray;
    
    // fetch all objects
    NSError *error = nil;
    NSArray *fetchedObjects = [self.managedObjectContext executeFetchRequest:fetchRequest error:&error];
    if (fetchedObjects == nil) {
        NSLog(@"Houston, we have a problem: %@", error);
    }
    
    // display all objects
    for (Event *event in fetchedObjects) {
        NSLog(@"%@", [event.timeStamp description]);
    }

If you don’t need the Sort Descriptor, just remove that code from the example. This snippet is also available from Xcode and is called “fetch with predicate”.

For more information on Predicates, check out Apple’s Predicate Programming Guide.

Here’s an example for an Entity named Event with two properties (myKey and anotherKey):

// create a managed object
NSManagedObject *myObject = [NSEntityDescription insertNewObjectForEntityForName:@"Event" inManagedObjectContext:self.managedObjectContext];
    
// set its attributes
[myObject setValue:@"This is my value" forKey:@"myKey"];
[myObject setValue:@"My other value" forKey:@"anotherKey"];

If you have created custom NSManagedObject subclasses for your Entity then you can create an object like this:

// create a managed object from my custom class
Event *myObject = (Event *)[NSEntityDescription insertNewObjectForEntityForName:@"Event" inManagedObjectContext:self.managedObjectContext];
    
// set my object's properties
myObject.myKey = @"This is my value";
myObject.anotherKey = @"My other value";

The KVC method will always work, regardless if you have custom classes or not. Custom Classes have the advantage that you can add custom behaviour (i.e. methods), and of course code completion in Xcode.

Note that these snippets will create an object, but it your values are only stored once you save the Managed Object Context:

[self.managedObjectContext save:nil];

For a save action to make sense we need to have some data to save, so in this example we will copy an existing file (self.myURL) to the new URL that the save panel returns. We’ll let the NSFileManager just create a copy with a new name that the user specifies using the save panel:

- (IBAction)saveFile:(id)sender {
    
    // create the save panel
    NSSavePanel *panel = [NSSavePanel savePanel];
    
    // set a new file name
    [panel setNameFieldStringValue:@"NewFile.png"];
    
    // display the panel
    [panel beginWithCompletionHandler:^(NSInteger result) {
        
        if (result == NSFileHandlingPanelOKButton) {
            
            // create a file namaner and grab the save panel's returned URL
            NSFileManager *manager = [NSFileManager defaultManager];
            NSURL *saveURL = [panel URL];
            
            // then copy a previous file to the new location
            [manager copyItemAtURL:self.myURL toURL:saveURL error:nil];
        }
    }];
    
}

The only alien looking thing here is the use of a Block (like it is in the NSOpenPanel). This is the equivalent to an anonymous function in JavaScript, basically a block of code that runs upon completion. As it’s part of the method call, the closing ] is way at the bottom.

Further Reading

Apple’s NSSavePanel Class Reference:

• https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSSavePanel_Class/Reference/Reference.html

A Short Practical Guide to Blocks:

• https://developer.apple.com/library/mac/#featuredarticles/Short_Practical_Guide_Blocks/

In this example we invoke the panel from a button in the main window, then display the returned URL in a textLabel:

- (IBAction)loadFile:(id)sender {
    
    // create an open documet panel
    NSOpenPanel *panel = [NSOpenPanel openPanel];
    
    // display the panel
    [panel beginWithCompletionHandler:^(NSInteger result) {
        if (result == NSFileHandlingPanelOKButton) {
            
            // grab a reference to what has been selected
            NSURL *theDocument = [[panel URLs]objectAtIndex:0];
            
            // write our file name to a label
            NSString *theString = [NSString stringWithFormat:@"%@", theDocument];
            self.textLabel.stringValue = theString;
            
        }
    }];
    
}

Further Reading

Apple’s NSOpenPanel Class reference:

• https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSOpenPanel_Class/Reference/Reference.html

However, when you embed your top view controller in a Navigation Controller, and perhaps that one is also embedded in a Tab Bar Controller, then this array isn’t quite so easy to figure out (and I must admit that I always forget how to do this when a new challenge arises).

So here’s how this works. In this example, the thing that’s displayed is called MyViewController, which is embedded in a Navigation Controller. I’m passing it the App Delegate’s self.managedObjectContext which is defined as a property on MyViewController.

// grab our own navigation controller
UINavigationController *navigationController = (UINavigationController *)self.window.rootViewController;
    
// grab our table view controller
MyViewController *myViewController = (MyViewController *)navigationController.topViewController;
    
// pass in whatever data you need (such as this):
myViewController.managedObjectContext = self.managedObjectContext;

We call this in the applicationDidFinishLaunching method, just before the return statement.

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
    return [[self.fetchedResultsController sections] count];
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    id <NSFetchedResultsSectionInfo> sectionInfo = [self.fetchedResultsController sections][section];
    return [sectionInfo numberOfObjects];
}

Note that this is designed as a one-off operation to create a new store file which can be used in another application. Once run, comment the code out and either change your store file, or take the store file and use it in another app.

Add this code to the AppDelegate.m file in the persistenStore method (just before the return statement):

// convert this thing to SQL
NSURL *sqlstore = [applicationFilesDirectory URLByAppendingPathComponent:@"NewStoreFile.sqldata"];
NSPersistentStore *xmlstore = [coordinator persistentStoreForURL:url];
    
[coordinator migratePersistentStore:xmlstore toURL:sqlstore options:nil withType:NSSQLiteStoreType error:nil];

For more information on how to do this in context, check out Simon Allardice’s superb course Core Data for iOS and OS X on Lynda.com.

You provide the user controls you need in Xcode, then control-drag your way to extensive functionality and happiness. Before I forget, I thought I’d better make some notes.

Here’s a step-by-step list:

• Using Xcode, create a new Mac Cocoa Application with Core Data
• Setup your entities and properties in your Core Data Model (.xcdatamodeld)
• Create relationships between Entities if desired
• Select all Entities and create custom classes from them (using Editor – create NSManagedObject Subclasses)

Drag our friend the Array Controller onto the Object’s Bar. If you have multiple Entities, you need a separate Array Controller for each one. Change the labels to tell them apart (select a different file and go back to the xib in order for those labels to be visible – it’s a bug in Xcode).

Now bind the Array Controller and Core Data Managed Object Context together:

• Select your Array Controller, then go to the Bindings Inspector (second from the right)
• Under Parameters, head over to the Managed Object Context and bind to the App Delegate (as that’s where Xcode has kindly prepared our Core Data stack)
• In Model Key Path, type self.managedObjectContext (this should self complete)
• In the Attributes Inspector, tell the controller that we’re using an Entity instead of a Class, then enter the Entity (it’s the one you’ve created in the data model)
• While you’re here, tick the “Prepares Content” check box if you want the table view to be populated automatically

Add a Table View to your window and bind it to the Array Controller:

• Select the Table View (inside the Scroll View) and head over to the Bindings Inspector
• Under Table Content, select Bind To your Array Controller
• Now select the actual Table Column you want to fill with data, and still inside the Bindings Inspector under Value, bind the column to your Array Controller
• In the field for Model Key Path, type the attribute/property you’d like to see in this column (you’ve defined this in the data model)
• Repeat the process for each column you want to fill with data

To add data to your table:

• Add a couple of Gradient Buttons to your window
• Make one the “Add” and one the “Delete” button
• Hook up each button to the Array Controller via control drag, selecting add and remove respectively

Congratulations: You’ve just created an editable Table View, hooked up to Core Data without a single line of code!

Let’s create a functional SAVE menu item

If you quit the app (rather than running it again from Xcode), all your data will save. However we can implement a manual save action with ease. The menu item itself is there by default, all we need to do is hook it up to the App Delegate and bind it to the save function.

In the Object Sidebar, select Main Menu, then select File – Save (which will expand the item in the sidebar too). From the save menu option, control drag to the App Delegate and select saveAction.

Imagine your app is calculating a value. We can check if the value is as we had expected it to be:

    // NSAssert Example (nothing happens)
    int i = 47;
    NSAssert(i == 47, @"That didn't work");

In this case, everything is fine and we don’t see any log output. Let’s change the value to something else, and see our message together with a rather intimidating stack trace hit our log:

    // NSAssert Example (will cause an exception)
    int i = 48;
    NSAssert(i == 47, @"That didn't work");

You can also pass values and print them to the log. Depending on how many variables you pass, add a number to NSAssert like so:

    // NSAssert Example (pass one value)
    int i = 48;
    NSAssert1(i == 47, @"The real value is %i", i);

Use NSAssert2, NSAssert3 and so forth for more than one value.

Well that’s because at those unhelpful times, Xcode is technically picking up an “exception”, but it tries to continue to run the programme. That’s when we end up with an error message which isn’t related to the actual problem.

An Exception Breakpoint can help. It’s something we can set and therefore force Xcode to stop when the problem occurs, not several lines later. Here’s how we do it:

• with the Navigator pane open, select the 6th tab from the left (the Breakpoint Navigator)
• at the bottom left, click the plus sign to add a breakpoint
• from the context menu select Add Exception Breakpoint
• leave all default values and hit Done

Next time Xcode will not try to be heroic and keep going. Instead, expect a more helpful error message.

Also check out: https://developer.apple.com/library/ios/#recipes/xcode_help-breakpoint_navigator/articles/adding_an_exception_breakpoint.html

    // version 1:
    [self.searchBar becomeFirstResponder];

    // version 2:
    [self.searchDisplayController setActive:YES animated:YES];

The benefit of version 2 is that if we perform it “in vision”, we can use the animated option and make it look all swish.

Version 2 of course also has a reverse with which we can deactivate the controller:

    [self.searchDisplayController setActive:NO animated:YES];

Note that this will not affect the UISearchBar associated with the search display controller; you need to deal with that separately.

        NSString *something = @"12345";
        something = [something substringToIndex:(something.length - 1)];
        
        // something is now 1234

        NSString *something = @"123456789";
        NSRange myRange = NSMakeRange(2, 3);
        something = [something substringWithRange:myRange];

        // something is now 345

You create a range by specifying where the substring should start (the first character is 0, like in an array), then specify how many characters from there you want to use.

To grab just the first character you’d specify a range like this:

        NSString *something = @"123456789";
        NSRange myRange = NSMakeRange(0, 1);
        something = [something substringWithRange:myRange];

        // something is now 1

// create a typedef of int
        typedef int yourInt;
        yourInt yourValue = 57;
        
        NSLog(@"Your value is %i", yourValue);

Now you have your own variable type called youInt which behaves just like an int.

The power of typedef becomes clearer when combined with enumerations we were discussing previously. You can create your own data type of enum, creating and addressing your values more easily. Let’s stick with the drink size example from earlier:

// create a typedef of enum drinkSize
        typedef enum drinkSize {
            smallDrink = 1,
            mediumDrink = 50,
            largeDrink = 100
        } drinkSize;
        
        // declare a variable from my typedef enumeration set
        drinkSize myDrink = largeDrink;
        drinkSize juliasDrink = smallDrink;

Xcode will code complete all available values, making your life a bit easier when coding.

Many of Apple’s pre-defined super long complex types are created this way. Think of all those NSDateFormatter values you can use, such as NSDateFormatterStyleLongStyle.

Imagine you want to track drink sizes, such as small, medium and large. You can remember to just use the numbers 1, 2 and 3 for each size – but Enumeration makes it easier to declare those.

// create an enumeration
        enum drinkSize {
            smallDrink = 1,
            mediumDrink = 50,
            largeDrink = 100
        };
        
        // declare a variable from my enumeration set
        enum drinkSize myDrink = largeDrink;
        
        // compare against my own values
        if (myDrink == largeDrink) {
            NSLog(@"That's my drink!");
        }
        
        // an enum behaves like an integer
        NSLog(@"My Drink Size is %i", myDrink);

Notice the last line: when written in a string like a log message, Objective-C will track your enumeration’s numeric values instead. In my case, the log message would display “My Drink Size is 100″.

Here’s how you create an indexPath for row 0, section 0:

NSIndexPath *indexPath = [[NSIndexPath alloc]init];
indexPath = [NSIndexPath indexPathForItem:0 inSection:0];

The method takes two integers. You can even take an existing indexPath, then add or subtract values to the new indexPath, like so:

// current indexPath
NSIndexPath *indexPath = [self.tableView indexPathForSelectedRow];

// make a new indexPath and add 1 to the row of the previous one
NSIndexPath *indexPath2 = [[NSIndexPath alloc]init];
indexPath2 = [NSIndexPath indexPathForItem:(indexPath.row + 1) inSection:indexPath.section];

I’ve been working on an iOS App recently which deals with several date methods. Usually when something goes wrong Xcode displays very dry messages such as “Array out of bounds” or something rather unhelpful (like the complete stack output with no clue as to what actually went wrong).

I was accidentally passing nil into an NSDateComponents method – and instead of crashing (which is what I would have expected), Xcode displayed this super funny message in the log console:

[__NSCFCalendar components:fromDate:toDate:options:]:

toDate cannot be nil

I mean really, what do you think that operation is supposed to mean with a nil toDate?

An exception has been avoided for now. A few of these errors are going to be reported with this complaint, then further violations will simply silently do whatever random thing results from the nil.

It made me smile

I think we should have more error messages like this! Here’s a screenshot:

Xcode can be funny after all

In this example, let’s assume we want to know what date it is 5 days from today:

int daysToAdd = 5;
NSDate *today = [NSDate date];
NSCalendar *gregorian = [[NSCalendar alloc]initWithCalendarIdentifier:NSGregorianCalendar];
NSDateComponents *components = [[NSDateComponents alloc]init];
[components setDay:daysToAdd];
NSDate *futureDate = [gregorian dateByAddingComponents:components toDate:today options:0];

You can add as many and diverse components you like, such as

• setEra:
• setYear:
• setMonth:
• setDay:
• setHour:
• setMinute:
• setSecond:
• setWeek:
• setWeekday:
• setWeekdayOrdinal:
• setQuarter:
• setCalendar:
• setTimeZone:
• setWeekOfMonth:
• setWeekOfYear:
• setYearForWeekOfYear:

Check out the NSDateComponents Class Reference for more information.

In fact, under the hood an NSDate object is the amount of seconds that have elapsed since the 1st of January 2001 (or 1970), in milliseconds. So really it’s a massive floating point number. You can see what it is with this code:

NSLog(@"Since 1970: %f", [today timeIntervalSince1970]);
NSLog(@"Since 2001: %f", [today timeIntervalSinceReferenceDate]);

To save you the trouble, it’s bee roughly 1362585768.752258 seconds since 1970. But I digress…

Sometimes you want the date objects you’re dealing with not to regard “time” and really only deal with dates. As such, all dates – to be comparable – need to have the very same time, say midnight. Otherwise you may get the wrong results. Imagine adding three date objects that each have noon as their time, that’s an extra day and a half clouding your results right there.

Here’s some code that will normalize your NSDate object by setting its time to midnight:

// normalizing a date
NSDate *yourDate = [NSDate date];
NSCalendar *gregorian = [[NSCalendar alloc]initWithCalendarIdentifier:NSGregorianCalendar];
NSDateComponents *dateComponents = [gregorian components:(NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit) fromDate:yourDate];
        
yourDate = [gregorian dateFromComponents:dateComponents];
        
NSLog(@"Now your date starts at midnight: %@", yourDate);

In a nutshell, we “explode” the date into its year, month and day components, and then recreate a new object with these and no other components.

Lucky for us there are a few other classes available that will help us do this, namely NSCalendar and NSDateComponents.

Years, Months and Days

Here’s how you can determine how many years, months and days have passed between two NSDates:

NSDate *earlier = [[NSDate alloc]initWithTimeIntervalSinceReferenceDate:1];
NSDate *today = [NSDate date];

NSCalendar *gregorian = [[NSCalendar alloc]initWithCalendarIdentifier:NSGregorianCalendar];

// pass as many or as little units as you like here, separated by pipes
NSUInteger units = NSYearCalendarUnit | NSDayCalendarUnit | NSMonthCalendarUnit;

NSDateComponents *components = [gregorian components:units fromDate:earlier toDate:today options:0];

NSInteger years = [components year];
NSInteger months = [components month];
NSInteger days = [components day];

NSLog(@"Years: %ld, Months: %ld, Days: %ld", (long)years, (long)months, (long)days);

The above example returns Years: 12, Months: 2, Days: 5.

In a nutshell we split the date into “components” such as years, months and days, and let the NSDateComponents class give us those as NSIntegers (i.e. long integers). For the class to calculate this correctly we need to put our days into the context of an NSCalendar (gregorian in our case). This is important because different calendars may return different time intervals.

Just the Days

If you’re interested in just one particular item (days for example) just leave out any other component on this line:

// just the days
NSUInteger units = NSDayCalendarUnit;

How about other units?

You can pass as many of those fast enumeration units as you like, separated by pipes. For a full list of available values check out the NSCalendar Class Reference

Further Reading

• NS Calendar Class Reference: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSCalendar_Class/Reference/NSCalendar.html
• Date and Time Programming Guide: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/DatesAndTimes/DatesAndTimes.html

If you want to go back exactly one view controller, here’s how you can do it programmatically:

    // pop back to previous controller
    NSArray *myControllers = self.navigationController.viewControllers;
    int previous = myControllers.count - 2;
    UIViewController *previousController = [myControllers objectAtIndex:previous];
    
    [self.navigationController popToViewController:previousController animated:YES];

First we access the array of all view controllers and count it. We subtract one (because arrays are 0 based), and another one to go back in history – hence we go “minus 2″. Then we pop to view controller just behind the current one.

Test if the returned value is less than zero though…

If you want to go back all the way to the root view controller, there’s a method for that:

    // pop back to root controller
    [self.navigationController popToRootViewControllerAnimated:YES];

AppDelegate *myAppDelegate = (AppDelegate *)[[UIApplication sharedApplication]delegate];
[myAppDelegate saveContext];

No reference to fetchedResultsController or managedObjectContext or any complex &error statements.

I didn’t know the storyboard could do this, but it can:

Select the Navigation Bar in question, then check the Attributes Inspector:

In Code

To set the title in code, you need to address the self.navigationItem.backBarButton property of your view controller and pass it a new UIBarButtonItem. Here’s one way of doing it:

// set a different back button for the navigation controller
UIBarButtonItem *myBackButton = [[UIBarButtonItem alloc]init];
myBackButton.title = @"Custom Text";
    
self.navigationItem.backBarButtonItem = myBackButton;

Alternatively we can use a much longer init method which will set the title in one line:

// set a different back button for the navigation controller
UIBarButtonItem *myBackButton = [[UIBarButtonItem alloc]initWithTitle:@"My Text" style:UIBarButtonItemStyleBordered target:nil action:nil];
    
self.navigationItem.backBarButtonItem = myBackButton;

One Thing of Note

The back button (and its text) is only displayed in the NEXT view controller on the stack. So changing the back button in the detail view controller for example doesn’t change what’s displayed when the detail view controller is displayed. You must change it one step earlier, in the master controller’s navigation bar.

Consider a view controller that brings up another view controller via a modal segue. Let’s call them ViewController and DetailViewController. When it comes to dismissing that DetailViewController, he could do it himself via

[self dismissViewControllerAnimated:YES completion:nil];

However, the first ViewController wouldn’t be in charge of that process. If we wanted to make that happen, we can define a protocol on DetailViewController, then have ViewController conform to it and hence be in charge of the dismissal.

Let’s make it happen!

Defining the Protocol

Most of the work happens in the header file of DetailViewController:

#import <UIKit/UIKit.h>

@protocol DetailViewDelegate;

@interface DetailViewController : UIViewController

@property (nonatomic, weak) id <DetailViewDelegate> delegate;

- (IBAction)dismiss:(id)sender;

@end


@protocol DetailViewDelegate

- (void)detailViewDismiss;

@end

Right after the import statement, we say “we’ll define a protocol in here”. Next we setup a weak property called delegate so that we can declare a delegate elsewhere (other than self).

After the first @end statement we define one method that the delegate must confirm to. By default, all methods we define are “required” by the delegate – if we don’t implement them all, then we’ll get a yellow warning mark in Xcode.

We don’t have to define these methods in the implementation file. Instead, we would define where we would like our delegate to execute them. I have one method which will get called when a button on DetailViewController is pressed:

- (IBAction)dismiss:(id)sender {
    
    [self.delegate detailViewDismiss];
}

All we do here is say “yo delegate, call my dismiss method and do in it whatever you like”.

Confirming to the protocol

We’ve done this countless times with built-in classes, and the process is exactly the same for our own protocols:

- add the delegate protocol in to ViewController’s header file
- implement the methods in the implementation file

Here’s the very simple ViewController.h header file (ie “the guy who’s in charge”):

#import <UIKit/UIKit.h>
#import "DetailViewController.h"

@interface ViewController : UIViewController <DetailViewDelegate>

@end

And in the implementation file we’d define our only delegate method:

- (void)detailViewDismiss {
    
    [self dismissViewControllerAnimated:YES completion:nil];
}

The only remaining thing is to tell DetailViewController who the delegate is. In case of a modal segue like ours this can be done in the prepareForSegue:sender method:

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
    
    DetailViewController *detailView = (DetailViewController *)[segue destinationViewController];
    detailView.delegate = self;
    
}

Consider this standard table view method to display cells:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"Cell"];

    // populate your cell
    
    return cell;
}

Where do we actually ever create a UITableViewCell? All we’re asking here is “do we have reusable ones available” – but if the answer is “no”, then somehow these get created without an error message. Other times (such as when using an overlay table view courtesy of the search display controller) we get an error message.

This brings me to the point that perhaps Xcode and iOS create as well as dequeue cells automatically – but when they don’t, here’s how we can do this manually.

Let’s amend the above code snippet:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"Cell"];
    
    if (cell == nil) {
        cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Cell"];
    }

    // populate your cell
    
    return cell;
}

Now we properly create a cell should a dequeueable one not be available.

I haven’t had to use this, and the if statement never seems to get called if inserted into the Master/Detail template, yet I find this may be something to keep in mind for future projects.

You can do this by adding the following code to your viewWillAppear method:

    - (void)viewWillAppear:(BOOL)animated {

    // scroll the search bar off-screen
    CGRect newBounds = self.tableView.bounds;
    newBounds.origin.y = newBounds.origin.y + self.searchBar.bounds.size.height;
    self.tableView.bounds = newBounds;

}

Now it’s hidden, users make a search, hit cancel… and then it comes back into view. Wouldn’t it be nice if we could hide it again after users are finished with their search? And sure we can! We’re already conforming to the UISearchBarDelegate protocol, so all we need to do is to implement the following method and react to the cancel button:

- (void)searchBarCancelButtonClicked:(UISearchBar *)searchBar {

    [self viewWillAppear:YES];

}

We could implement the same code as above, or just call the viewWillAppear method again.

Note that you have to set the search bar’s delegate to your class for this to work. Searches are working fine when it’s not set, but to react to the cancel button it needs to be set (either in code or via the Connections Inspector in Interface Builder).

You can find a full demo project on GitHub: Table Search 2013

This process isn’t very well documented from what I could find, so here’s how I did it successfully. Works fine in iOS 6.

For iOS 5 compatibility please see my comment at the end.

This new controller “switches out” the standard table view and overlays a new one (the search display). Since the data for the search view is more or less the same as what was already powering the original table view (only “filtered”), the search view often uses the same data source as the original table view.

Speaking of filtering the original data: this is done with something called a predicate (NSPredicate). First time I’ve heard of this was in regards to Core Data. A predicate is a rather powerful yet mysterious thing and rest assured you don’t need to understand it in order to use it.

Let’s go through this step by step: from creating a standard table view with some dummy data, then adding a search function and slowly making it work.

Creating the Table View

I’ll start with a Single View Application project (with Storyboards and ARC selected), removing the single View Controller from the Storyboard. Delete both ViewController h and m files too.

Next we’ll drag a UITableViewController into the Storyboard. Select the cell and set its reuse identifier to “Cell”. Next we’ll create a new Cocoa Touch Objective-C Class called TableViewController, naturally being a sub class of UITableViewController. Before we do anything else, let’s set this custom class in our Storyboard.

We’ll also create two properties in our h file:

• an NSArray called allData, holding all our data
• an NSMutableArray called searchResults which will hold our filtered results

Before we forget, let’s initialize the latter in our viewDidLoad method:

self.searchResults = [[NSMutableArray alloc]init];

Creating some Dummy Data

Here’s a small method that initializes our data: 24 written out numbers. This could be anything really:

- (void)createData {

    self.allData = [[NSArray alloc]initWithObjects:@"One", @"Two", @"Three", @"Four", @"Five", @"Six",
                    @"Seven", @"Eight", @"Nine", @"Ten", @"Eleven", @"Twelve",
                    @"Thirteen", @"Fourteen", @"Fifteen", @"Sixteen", @"Seventeen", @"Eighteen",
                    @"Ninteteen", @"Twenty", @"Twentyone", @"Twentytwo", @"Twentythree", @"Twentyfour",
                    nil];
}

Let’s call this method in our viewDidLoad so it’s ready for use as soon as the app starts:

[self createData];

Populating the Table View

Let’s make our table view show those items: take out the two #warnings and all commented code to make our class a bit more readable. Next set the tableView:numberOfSections to 1 as we wont be dealing with sections here.

The tableView:numberOfRowsInSection needs to be the amount of our allData array, so we’ll make it look like this:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    // Return the number of rows in the section.
        return self.allData.count;
}

And the final method we need to amend is the tableview:cellForRowAtIndexPath method so that text gets displayed in each cell:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"Cell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

        // Configure the cell...
        cell.textLabel.text = [self.allData objectAtIndex:indexPath.row];

    return cell;
}

Note that since Xcode 4.6 the template for a new Table View class has changed to incorporate an extremely annoying addition: right after the line with dequeueReusableCellWithIdentifier, we find “forIndexPath:indexPath”. This makes your app crash in iOS 5 and sometimes in iOS 6. Remove it to reflect my code above – you’ll avoid a lot of hair pulling later!

Run the app to see all our values listed as expected.

We’re not dealing with selecting them, but we’ll see next how we can make the view change into search mode.

Bring on the big Search Bar

This is where things get interesting: back in the storyboard, drag a UISearchDisplayController to the very top of your table view, so that it sits above the dummy cell. Switch to Assistant Editor mode and control drag a reference into your h file so we can address this thing.

Notice that when you do this you will only be able to create an outlet to a UISearchBar – that’s fine, it’s part of the UISearchDisplayController. Call it searchBar.

Setting up our Predicate

Back in the TableViewController.m file we need to add a couple of helper methods. The first one is a method called filterData. We will call this repeatedly so a small method will work best for us:

- (void)filterData {

    [self.searchResults removeAllObjects];
    NSPredicate *predicate = [NSPredicate predicateWithFormat:@"self CONTAINS [cd] %@", self.searchBar.text];
    self.searchResults = [[self.allData filteredArrayUsingPredicate:predicate] mutableCopy];

}

This method will take what’s in our search bar and compare it to our allData array. Matching items are placed into our searchResults array (which we clear out at the beginning of this method). The [cd] statement means we don’t want to know about caSe sEnSitiVity or “diacritics” which are things like the Umlaut Dots above a letter and such.

The great thing for us is that after calling this method, we know how many matches we have and hence how many cells we need to display. We want to call this method every time someone adds a single letter to our search bar. And in order to know when that is, we better conform to the

UISearchBar Delegate Protocol

If we’re the Search Bar’s delegate, then we can implement a method that tells us when our search text changed. This is what we want! Head over to your TableViewController.h file and add the protocol declaration to the top:

@interface TableViewController : UITableViewController <UISearchBarDelegate>

Back in the m file add this method, which in turn will call our filterData method:

- (void) searchBar:(UISearchBar *)searchBar textDidChange:(NSString *)searchText {

    [self filterData];
}

There’s no need to setup the delegate; since we’ve implemented a Search Display Controller, this has been done for us already.

Dealing with the Search Display Controller

This controller is rather clever: rather than bringing up a modal view or anything visually disruptive, the Search Display Controller “overlays” his own table view above out existing one, dimming the latter out. It’s slick alright – but therefore also a tad confusing. Because out of a sudden, we have TWO table views to deal with.

So when we tell the usual data source methods how many sections, rows and cells we need to display, we need to do so via an if-then statement so see which table view is requesting the data.

We’ll start with the tableView:numberOfRowsInSection method:

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    // Return the number of rows in the section.
    if (tableView == self.tableView) {
        return self.allData.count;
    }
    [self filterData];
    return self.searchResults.count;
}

Here we ask: if it’s the “normal” table view, show the number of our allData array. If that’s not the case, we’ll be asked by the Search Display Controller. In which case, call the filterData method, then see how many items are, and then count those.

We need to do the same for our cellForRowAtIndexPath method:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"Cell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier];

    if (!cell) {
        cell = [[UITableViewCell alloc]initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"Cell"];
    }

    if (tableView == self.tableView) {
        // Configure the cell...
        cell.textLabel.text = [self.allData objectAtIndex:indexPath.row];
    } else {  
        cell.textLabel.text = [self.searchResults objectAtIndex:indexPath.row];
    }    
    return cell;
}

Again if the “standard” table view is asking, display an object from the allData. If it’s the other guy, display it from searchResults (by which time we would have just called the filterData method so we’re not calling it again).

One other point of note here is the if(!cell) statement:

Leaving this out makes the table view crash as soon as you hit a letter. For some reason cells don’t automatically create themselves as needed, which works fine in a standard table view. So if there aren’t any, we just create as many as needed.

Full Project Code

You can get the entire project on my repository on GitHub: Table Search 2013

Further Reading

• TableSearch – Apple’s Demo Code, last updated in 2010 and features iOS 4, does not make use of predicates (at the time of writing)
• Predicates Programming Guide
• UISearchDisplayController Class Reference

But sadly you forget to select “Action” from the drop down menu and instead create an outlet.

No biggie you think, deleting the outlet code. You go back and create the action properly, run the app… and get an error message such as this one:

*** Terminating app due to uncaught exception ‘NSUnknownKeyException’, reason: ‘[ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key badAction.’

Yikes! Unless you’re using Version Control, there is no way to undo adding that bad outlet. So you ask yourself: Will I have to start from scratch, or is there a way to fix your app?

Yes this is fixable – all we need to do is examine our storyboard file in Source Code mode, then find the problem and eliminate it. Here’s how you do it:

• With the left pane open (Navigation Inspector, showing all your files), select your storyboard and right click/control click to bring up the context menu. Select View as Source Code

This will allow you to see what the storyboard actually looks like in XML. Hit Option+F to bring up the Find in Context menu. Now search for whatever is causing you a headache, then delete the entire line. Make sure the opening and closing brackets are selected too.

In my case, all this needs to go:

<outlet property="badAction" destination="4R8-F9-Xhb" id="8xN-t2-22c"/>

You may see more than one occurrence of your action in this file – we only want to get rid of the “outlet”reference here. If you delete all occurrences it’s not a big problem, but you will have to re-connect your actions to the code later.

Once you’re done, run the app again and all should be fine.

To display the storyboard in the visual editor again, just control-click the file file again, and select “Open as – Interface Builder, iOS Storyboard”.

NSString *myString = @"47";
int myInt = [myString intValue];

To do the reverse, you can use the initWithFormat method:

int myInt = 32;
NSString *myOtherString = [[NSString alloc]initWithFormat:@"%i", myInt];

// build an array
NSArray *myArray = [[NSArray alloc]initWithObjects:@"One", @"Two", @"Three", @"Four", nil];
// loop through every element (dynamic typing)
for (id tempObject in myArray) {
    NSLog(@"Single element: %@", tempObject);
}

You don’t have to use dynamic typing if you know the types of objects you’re using. In our example this would work just as well:

// build an array
NSArray *myArray = [[NSArray alloc]initWithObjects:@"One", @"Two", @"Three", @"Four", nil];
// loop through every element (static typing)
for (NSString *tempObject in myArray) {
    NSLog(@"Single element: %@", tempObject);
}

Fast Enumeration also works with NSDictionaries of course:

// build a dictionary
NSDictionary *myDictionary = [[NSDictionary alloc]initWithObjectsAndKeys:@"One", @"1", @"Two",@"2", @"Three", @"3",nil];
// loop through it (dynamic typing)
for (id tempObject in myDictionary) {
    NSLog(@"Object: %@, Key: %@", [myDictionary objectForKey:tempObject], tempObject);
}

int i = rand()%10+1;
NSLog(@"Random Number: %i", i);

This generates an integer between 1 and 10. Alternatively you can use the arc4random function:

int i = arc4random() % 10;
NSLog(@"Random Number: %i", i);

This will generate a random number between 0 and 9.

One thing of note is that often this function will generate the same number multiple times in a row which may not be what you want.

If you search the Xcode documentation you’ll also find a link to Apple’s Randomization Services. Read it and weep here: http://developer.apple.com/library/ios/#documentation/Security/Reference/RandomizationReference/Reference/reference.html.

// get a reference to our file
NSString *myPath = [[NSBundle mainBundle]pathForResource:@"myfile" ofType:@"txt"];

// read the contents into a string
NSString *myFile = [[NSString alloc]initWithContentsOfFile:myPath encoding:NSUTF8StringEncoding error:nil];

// display our file
NSLog("Our file contains this: %@", myFile);

It is likely that instead of a long list of text we’d rather have each line in a separate string.
Thankfully there’s a method for this:

// split our string into an array
NSArray *mySplit = [myFile componentsSeparatedByString:@"\n"];

// display any one of them like this
NSLog(@"Third Position: %@", [mySplit objectAtIndex:2]);

I hate that! This is such a basic function on an always-connected device that I find it appalling not to have this available to all developers without hassle at all times.

Apple do give us some example code called Reachability in their documentation, which – like so many things – is hopelessly outdated and doesn’t work with ARC anymore: http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html

Thank god for the wonderful Tony Million who has updated the project and made it available on GitHub: https://github.com/tonymillion/Reachability – works with ARC and everything. It’s a simple drop-in class, exactly what we all want and need.

I salute you, Tony! Thank you very much

Here’s how to add it to your project step by step:

1. add both Reachability.h and Reachability.m to your project
2. add the SystemConfiguration.framework to your project
3. in the class that needs to check for network connectivity, #import Reachability.h
4. create a method such as this to check which network connection you’ve got:

- (void)checkForNetwork
{
    // check if we've got network connectivity
    Reachability *myNetwork = [Reachability reachabilityWithHostname:@"google.com"];
    NetworkStatus myStatus = [myNetwork currentReachabilityStatus];
    
    switch (myStatus) {
        case NotReachable:
            NSLog(@"There's no internet connection at all. Display error message now.");
            break;
            
            case ReachableViaWWAN:
            NSLog(@"We have a 3G connection");
            break;
            
            case ReachableViaWiFi:
            NSLog(@"We have WiFi.");
            break;
    
        default:
            break;
    }
}

Obviously check which host you’d like to reach. There are several other methods in this class, such as reachabilityForInternetConnection. Check out Tony’s examples on GitHub for more:

https://github.com/tonymillion/Reachability

// get reference with path and filename
NSString *filePath = [[NSString alloc]initWithFormat:@"Documents/myFile.txt"];
NSString *deleteThis = [NSHomeDirectory()stringByAppendingPathComponent:filePath];
// now delete the file
[[NSFileManager defaultManager]removeItemAtPath:deleteThis error:nil];

This does not work with wildcards in the file name (for example *.jpg).

NSString *myFile = [NSHomeDirectory() stringByAppendingPathComponent:@"Documents/myFile.txt"];

Before accessing it we can determine if it exists or not:

BOOL fileExists = [[NSFileManager defaultManager] fileExistsAtPath:[NSHomeDirectory()stringByAppendingPathComponent:myFile]];

~Library/Application Support/iPhone Simulator

You’ll be presented with a list of iOS Versions, each of which has several folders to explore. To access data that your apps have written, head over to Applications and see a list of cryptic folders, each one corresponding to one of your apps. In each you’ll find your BundleID.app, indicating which folder belongs to which app.

The Documents folder for example would contain all files that your app has saved to its local Document folder.

Library only comes up in finder by holding down the Option key, then clicking Go from the top menu.

At the same time a Release goes public, previous Betas expire – requiring them to be replaced on the iOS device in question.

Just like Beta Versions can downloaded at http://developer.apple.com, Release Versions can be downloaded there too (.ipsw files) once they become available. Here’s how to install them via iTunes:

1. download the .ipsw for your device model (there are a growing number, so double-check)
2. open iTunes and connect the device via USB
3. Option-Click the “Check for Update” button
4. this brings up a dialogue that lets you select the .ipsw file

The same procedure goes if a new Beta is released. This will put your device into recovery mode, and even though it’s a rather distressing process, if all goes well no data is lost in the process.

What if this doesn’t work?

Sometimes I’ve encountered that my device STILL can’t activate after doing the above. If that’s the case, repeat the above, Option-Clicking on Restore. This will also let you choose the .ipsw file, however it will erase all your data.

You can choose to click Restore without Option, which will download the latest firmware for you.

// calls the updateLabel method in 5 seconds
[NSTimer scheduledTimerWithTimeInterval:5.0 target:self selector:@selector(updateLabel) userInfo:nil repeats:NO];

However, you won’t be able to stop it without a reference. This is fine for one-off timers, but you need one if you want to stop a repeating timer.

To start a repeating timer self.myTimer:

// calls the updateLabel method every 0.1 seconds
self.myTimer = [NSTimer scheduledTimerWithTimeInterval:0.1 target:self selector:@selector(updateLabel) userInfo:nil repeats:YES];

And to stop if:

// stop the timer
[self.myTimer invalidate];

Here’s a working example on GitHub: https://github.com/versluis/TimerFun