The year ahead for Apple: the iPad dominates (and one more thing...)

With 2012 barely a week old (and possibly the last year ever), I thought it would be a good time to make some prognostications for the tech industry in the year ahead. As an iOS developer, I pay a lot of attention to Apple, so I'll concentrate on what I think is in store for the Cupertino company. Love them or hate them, they're certain to continue to make their presence felt in 2012.

iPad continues to dominate
Apple will announce the iPad 3 in March, to begin selling sometime in late May. It will be an iteration of the existing iPad design, but a little thinner, sleeker and sporting a 2048x1536 Retina display. Tech pundits will give it mixed reviews, repeatedly pointing out that there is no LTE version, but consumers will embrace the device and Apple will again have problems meeting strong demand. In addition, Apple will keep the iPad 2 around, slashing the price of the base model to US$299. With Apple's BOM costs for the iPad 2 now falling under US$200, they maintain their profit margins and whittle away at the value proposition of competing tablets, most notably the Kindle Fire.

This isn't a big deal for Amazon; the Kindle Fire is their razor handle and Amazon's digital books, music, movies and apps are the blades. Amazon will continue to improve their Kindle line, updating the Kindle Fire software and introducing a follow-on color tablet device in a larger form factor that's more suitable for viewing movies, magazines and textbooks. The Kindle doesn't need to appeal to everyone, only to Amazon's best customers, and ensure that Amazon has a path to their digital customers outside of Apple and Google. Amazon is happy to be the Schick to Apple's Gillette in the tablet market.

For the Android tablet makers, that large sucking sound you hear is Apple continuing to vacuum up all the mobile device profits in developed countries. With Apple using their billions in cash to lock up the best values in the supply chain, Android tablet makers will be hard pressed to match the iPad's juicy margins. Making it up in volume won't be possible: with Android lacking any compelling value proposition for the general consumer, Android tablets will remain the province of open source zealots, tinkerers and Apple-haters, and sales will be anemic in developed countries. The story will be a bit different in emerging economies where US$100 is too large a differential for most consumers, but razor thin profit margins will make Android tablets a money loser for all but the most nimble device makers. The story will be brighter for Android in the phone market, where Android's "openness" aligns closely with the mobile carriers' desire for total control of their customers, but here too Apple will continue to soak up the lion's share of profits on mobile phone sales.

The sad passing of Steve Jobs won't slow Apple down this year; if anything, his spirit will continue to haunt One Infinite Loop and energize the company. Though Tim Cook is no Steve Jobs, he doesn't have to be; ultimately Apple's products will speak for themselves, as they always have. And while we will all miss watching Jobs unveil Apple's latest and greatest, there will still be one more thing...the new Apple TV.


Television, the Apple way
With all the rumor and speculation swirling around the forthcoming Apple TV device, from Jobs' cryptic comment in his biography that "I finally cracked it" to talk of a 50-inch Apple branded television, it's hard to see where this one might go. I'd be surprised if they announce this early in the year; Apple needs to line up enough content owners behind the new device for it to be compelling to consumers and seem inevitable to the rest of the industry. The movie studios are scared of change and will draw out negotiations. I would look for a big announcement in the late summer or early fall.

A lot of speculation focuses on what kind of UI the device might have, with talk of Siri-style voice control, but I don't think that's the most interesting thing here: I'm sure the UI will be butter smooth and easy to use, whatever form it takes. When Jobs said "I finally cracked it", I believe he was thinking at a higher level. Apple has had the technology to build a nice TV set for a long time, but they haven't because there's no money to be made there, and simply building some pretty on-screen menus isn't interesting enough. Changing the way people perceive television and building a new business model behind that is what's interesting to Apple.

How many of you remember the first Motorola ROKR? That was the first "Apple phone", a Motorola mobile phone with a built-in iPod, released in September 2005 to widespread yawns and poor sales. It's no coincidence that Apple and Motorola parted ways not long after, with Apple announcing the iPhone in January 2007. The ROKR was a learning experiment on Apple's part, a way for them to get an understanding of mobile phone technology and the business model behind it. The genius of the iPhone was in seeing what a mobile phone could be. In 2006, a mobile phone was a commoditized product that let you make phone calls, painfully type out text messages on a cramped telephone keypad and take tiny, fuzzy pictures. Most consumers just took the cheapest device they could get from their mobile carrier. In 2007, a mobile phone became your portable connection to the internet, people lined up at the Apple store to buy it and happily switched carriers to make it work. Apple makes handsome margins on the device and a little pocket change on media sales through iTunes, the carrier attracts deep pocket customers who gladly pony up US$80 a month or more for an expensive data plan, and consumers get a clean, easy to use device that gives them Internet access on the go. Making phone calls becomes almost an afterthought. While the iPhone may not be in the carrier's best interests long term, the prospect of all those free-spending Apple customers in the short term was enough to sign up one carrier in every big market.

In 2011, teevee consists is a giant flat panel with a rat's nest of wires to a craptastic cable box, DVD player and game console, along with four inscrutable 57-button remotes lying on the coffee table. People pay US$100 or more per month to their monopoly cable company for access to hundreds of streams of random programming interspersed with twenty minutes of 100 decibel commercials per hour. Consumers pay attention to exactly 3.5 hours of programming a week; the rest of the time they flick channels endlessly, searching for something good. The flat panel screen is a commodity, as are the cable box and DVD or Blu-ray player; the game console is a barely differentiated loss-leader. Apple has been playing around the periphery of this miserable, steaming technology stack for several years with their "hobby", the little Apple TV box, that lets you watch movies and TV bought on iTunes and stream Netflix. They're learning about building UIs for giant flat panels and figuring out how to negotiate with the studios to get compelling content.

Apple has a lot of interesting pieces in place. iOS devices are already eating away at the hand-held game market. Sales and rentals of videos though iTunes have value to both the content owners and consumers with disposable income: the studios get flexible pricing and detailed sales metrics, consumers get their favorite programs without the commercial, movie previews or FBI warnings and the can watch at home or on their mobile device. Content distributors like MLB and Netflix can create custom apps for both iOS and Apple TV that give them greater control over how their content is distributed. In many ways, apps are the channels of the future. Facetime video chat is a great app, especially on iPad. The Airplay feature of iOS devices is a hidden gem here, effectively turning that big flat panel into a flexible video terminal for your iPhone, iPad or iPod touch, allowing you to project your favorite movie, TV show, game or app onto the big screen for all to enjoy. Apple TV sales figures may be modest when compared to other iOS devices, but the couple of million little Apple TV boxes sold in 2011 could be just the tip of the iceberg. The killer app for Apple TV is the ability to effortlessly bore friends and neighbors with all those bad vacation photos you took.

Apple could take the Apple TV platform in a number of directions. While I would love for them to do something that would allow me to ditch my collection of 57-button remotes, more likely Apple views the DVD/Blu-ray player, cable box and game console as legacy -- they will all go away on their own soon enough. Imagine Steve Jobs watching television, cross-legged on the polished hardwood floor of a nearly empty room with just a Tiffany lamp and a sleek, 50-inch Apple branded flat screen, the slim, silver seven-button Apple remote in his hand. You wouldn't need or want anything else. If Apple does produce their own television set, simplicity will be it's main value proposition to consumers. It will be designed to stand alone rather than integrate with all those legacy devices. You won't need to hire Geek Squad to set it up, but it won't appeal to people who are heavily invested in all those legacy devices. The tech press will complain about it being closed and limited, but it will strike a chord with certain buyers, particularly the 9% of US consumers that have dropped their cable television service. I'm sure Apple has a mature prototype television set sitting in Sir Jony Ive's office in Cupertino; whether Apple thinks the world is ready for it is the real question.

For the rest of us, Apple will continue to make the inexpensive little Apple TV box. They may update the hardware this year to add Siri-style voice control, but I'm expecting the real innovation will be on how content is bought and delivered. The rumor that Apple plans to bid for rights to broadcast English Premier League soccer is intriguing. The Apple TV already comes with apps for NBA, NHL and MLB as well as the Wall Street Journal. What would your television viewing experience be like if all your cable channels became apps on Apple TV, with in-app purchase or subscriptions for premium content? How would you divvy up that US$100 a month you currently spend on cable TV among all those apps? If enough of your favorite shows were available on Apple TV, canceling your cable TV subscription would be a no-brainer. I'll bet that many of the content owners would be happy to cut out the cable companies and have better control over their relationship with viewers.

Whatever Apple does around teevee this year, you can bet that critics will deride it as too limited, closed or incompatible, just as critics derided the first iPhone and iPad. Meanwhile, Apple will be laser-focused on making their customers happy and earning generous profits in the process.

Avoid agile dogma: recommendations not rules

Years ago as a developer working mostly solo, I got interested in automated testing and unit testing, which in turn lead me to extreme programming (XP) and agile software methodologies. I've had the wonderful good fortune of working for Pivotal Labs a number of times in recent years and been a part of a number of successful agile projects. I know that an agile approach to project management can work well in many situations and I think I have a good understanding of how and why. But I'm not an agile zealot -- agile isn't appropriate for every type of project or organization and a good team can usually succeed using any process. Still, I think working on an XP project is more fun and rewarding for everyone involved.

I've talked with many developers who range from agile skeptic to agile detractor. They often react negatively to a particular XP or agile practice, with pair programming and unit testing being the two most common ones. Some developers are drawn to programming because they get great satisfaction from grappling with interesting intellectual challenges in solitude; agile doesn't have much to offer an individual developer when this is their top priority. If you're this kind of developer and you've found a place that gives you the freedom to work solo on cool stuff, more power to you!

More often, I talk to developers who recoil from the dogmatic pronouncements of agile proponents.

Software developers are a funny bunch. We are prone to seeing the world in very black or white, zero or one terms, and we generally have finely tuned bullshit filters. We prefer a world that is rational, measurable and repeatable to one where truth is determined by politics, personality and political correctness. When confronted with admonishments to pair program, write unit tests, use Pivotal Tracker or pat your head while rubbing your belly, we ask, "Why?" All too often, agilistas respond by implying that you can't possibly succeed in software development without doing all these things, and more: this is just padawan stuff, just wait 'till you become a full-fledged Jedi! At this point, the bullshit filter is engaged and anything that smacks of "agile" is permanently tagged with bozo, to be called up later when a target for ridicule is needed.

That's a shame, because agile methodologies like XP and Scrum really aren't about writing software, but about managing complex projects where the goal is to build something unique and novel. And it's a rare software project that doesn't have uncertain requirements, technical risk, deadlines and limited budget. Software project planning and management is far too often dominated by the politics, personality and political correctness that software developers eschew. The core idea of agile methodologies is to turn project planning and management into something more rational, measurable and repeatable. Blanket prescriptions that you must write code a certain way, use a particular tool or hold certain kinds of meetings aren't helpful; in fact, they can be actively harmful to a functioning development team.

Mike Cohn (the author of one of my favorite books, Agile Estimating and Planning) made a New Year's resolution to "Make recommendations not rules". Mike lays out his view of the core rules that make a software development team "agile" in his eyes. It's a short list, just five points, but it gets at the heart of good project management, whether you call it agile or not. "Beyond that, it’s much more about recommendations," Mike states, and I agree.

If you're an agile proponent, try to keep in mind that each team's pain is unique, and there are many different paths to success. User stories or planning poker may be the shiny new candy to you, but most people just want to get their work done. Pushing strange new techniques on people and organizations that are unready or unreceptive is ineffective at best and counterproductive at worst. Making sure the right people are having the right conversations at the right time is at the heart of any successful project. Agile methodologies like XP and Scrum are frameworks for making this happen, but they're not the only way. Avoid agile purity tests, adapt to local circumstances and prefer recommendations over rules.

original link

Getting more from NSLog()

In a series of recent blog posts, John Muchow of iOS Developer Tips shows how to create your own wrapper around NSLog() to add useful debugging information to your log output like file name and line number:

• Filename and Line Number with NSLog: Part I


• Filename and Line Number with NSLog: Part II


• Objective-C Expressions for Debugging

Some great tips and tricks, check it out!

Objective-C Tuesdays: more NSArray sorting

Welcome to another Objective-C Tuesdays. Last week, we looked at sorting C arrays and NSArrays. Today, we will continue looking at sorting NSArrays using NSSortDescriptors.

As we saw last week, the sorting methods of NSArray require you to specify a comparator in one form or another. When sorting an NSArray of simple objects like NSStrings or NSDates, the comparators are usually pretty simple to write and common objects often have useful comparator methods like -caseInsensitiveCompare: and -localizedCompare:.

When sorting NSArrays of more complex objects, writing comparators is often more tedious and error-prone. Here's the interface for simple Person class:

// Person.h
@interface Person : NSObject

@property (strong) Address *address;
@property (strong) NSDate *birthdate;
@property (copy) NSString *firstName;
@property (copy) NSString *lastName;

@end

And here's the Address class used by Person:

// Address.h
@interface Address : NSObject

@property (copy, nonatomic) NSString *street;
@property (copy, nonatomic) NSString *city;
@property (copy, nonatomic) NSString *state;
@property (copy, nonatomic) NSString *country;
@property (copy, nonatomic) NSString *postalCode;

@end

If we have an NSArray of Person objects, we may want to sort them in country, lastName, firstName order. Here's one way to do that, using a comparator block:

// sort Person objects by lastName, firstName
Person *frodo = [Person new];
[frodo setFirstName:@"Frodo"];
[frodo setLastName:@"Baggins"];
// ...
[[frodo address] setCountry:@"Shire"];

Person *bilbo = [Person new];
[bilbo setFirstName:@"Bilbo"];
[bilbo setLastName:@"Baggins"];
// ...
[[bilbo address] setCountry:@"Shire"];

Person *legolas = [Person new];
[legolas setFirstName:@"Legolas"];
[legolas setLastName:@"Greenleaf"];
// ...
[[legolas address] setCountry:@"Mirkwood"];

NSArray *people = [NSArray arrayWithObjects:frodo, bilbo, legolas, nil];
NSArray *sortedPeople = [people sortedArrayUsingComparator:^(id item1, id item2) {
  Person *person1 = item1;
  Person *person2 = item2;
  
  // NSComparisonResult is a typedef for int
  NSComparisonResult result = [[[person1 address] country] compare:[[person2 address] lastName]];
  if (result) {
    return result;
  }
  
  result = [[person1 lastName] compare:[person2 lastName]];
  if (result) {
    return result;
  }
  
  result = [[person1 firstName] compare:[person2 firstName]];
  if (result) {
    return result;
  }
  
  return NSOrderedSame; // NSOrderedSame == 0
}];
// sortedPeople contains:
// Legolas Greenleaf (Mirkwood)
// Bilbo Baggins (Shire)
// Frodo Baggins (Shire)

The general pattern of a multi-field comparator is simple: check each field in turn, stop and return the comparison result if non-zero; if all fields are equal, return zero (or NSOrderedSame to be more descriptive). This quickly becomes tedious when you have many fields to sort by or you need to dig down into child or grandchild objects for fields.

Fortunately, there's an easier way to do this. NSArray has a method called -sortedArrayUsingDescriptors: that takes an array of NSSortDescriptor objects. Each NSSortDescriptor specifies a key path and sort direction (ascending or descending). The order of NSSortDescriptors in the array determines the precedence of each field. If you're not familiar with Key Value Coding (KVC), you may not have encountered key paths before. KVC is similar reflection in Java and other dynamic languages. KVC allows you to get and set fields on an object using the field names as strings, called keys. To access fields on child objects, you use keys separated by dots to form a key path; KVC knows how to drill down your object graph and access fields on child objects. There are a lot of interesting things you can do with KVC, but today we will stick to building an array of NSSortDescriptors:

NSSortDescriptor *byCountry = [NSSortDescriptor sortDescriptorWithKey:@"address.country" 
                                                            ascending:YES];
NSSortDescriptor *byLastName = [NSSortDescriptor sortDescriptorWithKey:@"lastName" 
                                                             ascending:YES];
NSSortDescriptor *byFirstName = [NSSortDescriptor sortDescriptorWithKey:@"firstName" 
                                                              ascending:YES];
NSArray *sortDescriptors = [NSArray arrayWithObjects:byCountry, byLastName, byFirstName, nil];

Notice that the byCountry sort descriptor uses the key path @"address.country": it will first get the value of the address property of the Person object, then get the country property of the address. Key paths can be as deep as your object graph.

Using the array of sort descriptors is easy:

NSArray *sortedPeople = [people sortedArrayUsingDescriptors:sortDescriptors];
// sortedPeople contains:
// Legolas Greenleaf (Mirkwood)
// Bilbo Baggins (Shire)
// Frodo Baggins (Shire)

This certainly makes creating complex sort criteria much easier, and you're not limited to the default comparator for a field. You can specify a selector for a comparator method on the field this way:

// specify a method to call on the lastName object
NSSortDescriptor *byLastName = [NSSortDescriptor sortDescriptorWithKey:@"lastName" 
                                                             ascending:YES
                                                              selector:@selector(caseInsensitiveCompare:)];

Or for more specialized comparisons, you can pass in a NSComparator block this way:

// sort descriptor using length of last name
NSSortDescriptor *byLastNameLength = [NSSortDescriptor sortDescriptorWithKey:@"lastName" 
                                                                   ascending:YES 
                                                                  comparator:^(id item1, id item2) {
  NSString *lastName1 = item1;
  NSString *lastName2 = item2;
  // cast result to NSComparisonResult so that the 
  // compiler infers the correct return type
  return (NSComparisonResult) ([lastName1 length] - [lastName2 length]);
}];

Specifying complex sort orders with NSSortDescriptors is the type of higher level, declarative code that is easy to write, easy to read and easy to maintain, and in most cases you should consider using NSSortDescriptor rather than writing your own comparator methods, functions or blocks.

Next time, we will look at sorting NSMutableArrays in place, rather than producing a sorted copy like the various -sortedArray methods.

iPhone owners upgrading to iOS 5 rapidly

Less than two months after the release of iOS 5, nearly half of all iOS device owners have upgraded. Marco Arment, the developer of Instapaper (one of my favorite and frequently used apps), periodically releases iOS metrics he gathers from Instapaper users detailing the breakdown of iOS versions and iOS device types.

The tl;dr conclusion: nearly 99% of Instapaper users have iOS 4.0 or later, and nearly 95% have an iPhone 3GS-class processor or better. This jibes with what we see at Able Pear. We're planning to only support iOS 4.0 and later for all future app releases.

This is one of the things that Apple really does right with iOS. iPhone, iPad and iPod touch users upgrade their devices pretty rapidly; with iOS 5 allowing you to upgrade the OS directly on the device without connecting to iTunes, this will become that much easier and adoption of the latest OS versions will only improve in the future. As an app developer, there are pluses and minuses to Apple's tight control, but as an iOS user, this is a very solid plus -- upgrades are easy and developers rapidly support the latest iOS goodies rather than target some very old lowest common denominator OS version.

Check out the complete breakdown in .

original link

Great Geek Gift: Making Embedded Systems

If you're looking for a great gift idea for that geek in you life (or for yourself :-) and you're interested in computer hardware as well as software, check out by Elecia White. I had the good fortune to work with Elecia on a project last year and she's a top notch engineer -- and now an O'Reilly author. In her new book Making Embedded Systems, Elecia covers everything you need to know to get started building and programming embedded devices: system architecture, reading data sheets, debugging hardware and software, IO and timers, handling interrupts, peripherals and power consumption. If you're part of the Maker Faire/Arduino/Circuit Cellar hardware hacking community, or interested in learning about it, I highly recommend you check it out! Like most O'Reilly books, it's available as a printed book or in various e-book formats that work great with Kindle and iPads.

original link

Objective-C Tuesdays: sorting arrays

Good news everyone! Objective-C Tuesdays is back! We left off a few weeks ago talking about techniques for inserting and removing items in arrays. Today we will cover sorting C arrays as well as NSArrays and NSMutableArrays.

Sorting C arrays with qsort()
The C standard library includes only one built-in way to sort C arrays: the qsort() function. qsort() is an implementation of the quicksort algorithm, a good general purpose sorting algorithm. qsort() sorts an array in place.

The qsort() prototype looks like this:

qsort(void *array, size_t itemCount, size_t itemSize,
     int (*comparator)(void const *, void const *));

If you're not experienced using function pointers in C, the declaration of qsort() will look confusing. That's because declaring a C function pointer type is confusing. I'll use a typedef to make things easier to understand:

// alternate declaration of qsort using a typedef:
typedef int (*Comparator)(void const *, void const *);

qsort(void *array, size_t itemCount, size_t itemSize,
     Comparator comparator);

Function pointers are declared in the same way that functions are declared in C, except they have a * before the function name like other pointer variables do. But there's one hitch. In a function pointer declaration, the * is ambiguous; by default, C will assume the * is part of the return type of the function. So when you declare a function pointer, you need a set of parentheses around the * and the function name in order to clue in the compiler.

// declare a function returning a pointer to an int
int *returnAPointerToSomeInt(void);
// which is interpreted as:
// (int *)returnAPointerToSomeInt(void);

// declare a pointer to a function returning an int
int (*returnSomeInt)(void);

Now that we've cleared that up, let's look at the declaration of qsort() again.

typedef int (*Comparator)(void const *, void const *);

qsort(void *array, size_t itemCount, size_t itemSize,
     Comparator comparator);

The first three parameters of qsort() specify the array to sort, the count of items in the array and the size (in bytes) of a single item. Note that the array is of type void *, which allows us to pass any type of C array into qsort().

The last parameter is the comparator function.

typedef int (*Comparator)(void const *item1, void const *item2);

The comparator takes pointers to two items from the array and returns a negative number if item1 belongs before item2, a positive number if item1 belongs after item2 and zero if the two items are equal (or have equivalent ordering). This style of comparator function is used in many languages for sorting. I think of the items positioned on a number line when trying to understand a comparator:

  item1 <=====<< item2
<-+------+-----+------+------+->
 -2     -1     0      1      2

          item2 >>=====> item1
<-+------+-----+------+------+->
 -2     -1     0      1      2

When item1 belongs before item2, the comparator function will return a negative number; when item1 belongs after item2, the comparator returns a positive number. This relationship is the difference between item1 and item2, or item1 - item2.

The C standard library doesn't include many comparator functions, but they're easy to write. Here's an example of a comparator for ints to sort them in natural order:

int compareInts(void const *item1, void const *item2) {
 int const *int1 = item1;
 int const *int2 = item2;
 return *int1 - *int2;
}

We create local variables int1 and int2 since a void pointer will automatically convert to a typed pointer in C, and we know that qsort() will actually be giving us pointers to ints. The two parameters are also const, so we can't modify the int values that the items point to (which would cause qsort() to go haywire). Then we can simply return the difference between the two int values to determine their sort order. We could do this in one line using casts and parentheses:

int compareInts(void const *item1, void const *item2) {
 return *( (int const *) item1) - *( (int const *) item2);
}

Either way, now we can use our compareInts() function to sort an array of ints:

int array[6] = { 42, 17, 57, 19, 11, 5 };

qsort(array, 6, sizeof(int), compareInts);
// array now contains 5, 11, 17, 19, 42, 57

Now suppose we wanted to sort our array in reverse order? We would still use qsort() to do the job, but employ a different comparator function. Here is compareIntsReversed():

int compareIntsReversed(void const *item1, void const *item2) {
 int const *int1 = item1;
 int const *int2 = item2;
 return -(*int1 - *int2);
 // or simply return *int2 - *int1;
}

By reversing the sign of the comparator's return value, you can reverse the order of sorting.

int array[6] = { 42, 17, 57, 19, 11, 5 };

qsort(array, 6, sizeof(int), compareIntsReversed);
// array now contains 57, 42, 19, 17, 11, 5

The qsort() function is very flexible. You can sort arrays of complex types as easily as arrays of ints. To sort an array of C strings in lexicographic order, use the strcmp() function from the C standard library.

char const *array[3] = { "red", "green", "blue" };

qsort(array, 3, sizeof(char const *), strcmp);
// array now contains "blue", "green", "red"

Sorting an array of CGPoints, first write a comparator:

int compareCGPoints(void const *item1, void const *item2) {
 struct CGPoint const *point1 = item1;
 struct CGPoint const *point2 = item2;

 if (point1->x < point2->x) {
   return -1;
 } else if (point1->x > point2->x) {
   return 1;
 }

 if (point1->y < point2->y) {
   return -1;
 } else if (point1->y > point2->y) {
   return 1;
 }

 return 0;
}

Notice that we first compare the X coordinates of the points and only check the Y coordinates if the X coordinates are equal. This is a common pattern when sorting over multiple fields in a struct. Here's an example of the CGPoint comparator in action:

struct CGPoint pointArray[4] = {
 { 4.0f, 3.0f },
 { 2.0f, 1.0f },
 { 4.0f, 1.0f },
 { 2.0f, 3.0f }
};
qsort(pointArray, 4, sizeof(struct CGPoint), compareCGPoints);
// pointArray now contains:
//  { 2.0f, 1.0f }
//  { 2.0f, 3.0f }
//  { 4.0f, 1.0f }
//  { 4.0f, 3.0f }

Other C sorting functions
For most common sorting jobs, qsort() it a reasonable choice, and it's the only choice that's included in the C standard library. OS X and iOS also include a couple of other sorting functions worth mentioning: heapsort() and mergesort(), which have the same parameters as qsort() and are detailed on the qsort() man page. heapsort() is slower than qsort() but uses a limited amount of memory while sorting, whereas qsort() uses recursion and can potentially overflow the stack when sorting huge arrays. mergesort() can be significantly faster than qsort() when the array is mostly in sorted order already, but is significantly slower when the array is in random order.

Sorting an NSArray
Objective-C provides a number of ways to sort an NSArray. Because NSArray objects are immutable, all the sorting methods on NSArray return a new sorted NSArray object and leave the original one unchanged. The most basic sorting method is -sortedArrayUsingFunction:context:, which is similar to sorting a C array with qsort(). The full method declaration looks like this:

- (NSArray *)sortedArrayUsingFunction:(NSInteger (*)(id, id, void *))comparator 
                              context:(void *)context

The first parameter is a pointer to a comparator function. As we did for qsort(), I'll rewrite the method declaration using a typedef for the function pointer to make it a little easier to read:

typedef NSInteger (*Comparator)(id item1, id item2, void *context);

- (NSArray *)sortedArrayUsingFunction:(Comparator)comparator 
                              context:(void *)context

The comparator function for NSArray sorting has a few differences from the qsort() one. It returns an NSInteger, which is simply a typedef for int. Instead of two items of type void const *, it takes two items of type id since NSArrays can only hold object types. And finally, there's an extra context parameter, a void pointer that allows you to pass extra information to the comparator if you need to (but you can safely ignore it if you don't need it).

Let's write a comparator function that orders NSStrings by their length.

static NSInteger compareStringsByLength(id item1, id item2, void *context) {
  return [item1 length] - [item2 length];
}

Since we can send any message to a variable of type id, we don't even need casts or intermediate variables here. (Of course, we'll get a runtime error if we put the wrong type of objects into our array, but comparators for qsort() have the similar problems.)

And now let's see it in action:

NSArray *array = [NSArray arrayWithObjects:@"Florida", 
                    @"Texas", @"Mississippi", @"Delaware", nil];

NSArray *sortedArray = [array sortedArrayUsingFunction:compareStringsByLength 
                                               context:NULL];
// sortedArray contains:
// @"Texas"
// @"Florida"
// @"Delaware"
// @"Mississippi"

Now let's use the context parameter to make it easy to switch between normal and reversed sort order. We can pass a pointer to any kind of data we want, so we will use a pointer to a BOOL, where a YES value means reversed and a NO value means normal ordering.

NSInteger compareStringsByLength(id item1, id item2, void *context) {
  BOOL *reversed = context;
  NSInteger order = [item1 length] - [item2 length];
  if (*reversed) {
    return -order;
  } else {
    return order;
  }
}

Now we need to pass something to the context parameter when we call -sortedArrayUsingFunction:context:

NSArray *array = [NSArray arrayWithObjects:@"Florida", 
                    @"Texas", @"Mississippi", @"Delaware", nil];

BOOL reversed = YES;
NSArray *sortedArray = [array sortedArrayUsingFunction:compareStringsByLength 
                                               context:&reversed];
// sortedArray contains:
// @"Mississippi"
// @"Delaware"
// @"Florida"
// @"Texas"

Note that we use the & operator to pass the address of the reversed variable as the context.

If you target iOS 3.2, OS X 10.6 or later, you can use the block version, -sortedArrayUsingComparator:. Blocks make one-off comparator functions easier to read and understand by putting the comparator definition right along side the sort method call. We can rewrite our example this way:

NSArray *array = [NSArray arrayWithObjects:@"Florida", 
                    @"Texas", @"Mississippi", @"Delaware", nil];

BOOL reversed = YES;
NSArray *sortedArray = [array sortedArrayUsingComparator:^(id item1, id item2) {
  NSInteger order = [item1 length] - [item2 length];
  if (reversed) {
    return -order;
  } else {
    return order;
  }
}];
// sortedArray contains:
// @"Mississippi"
// @"Delaware"
// @"Florida"
// @"Texas"

Since a block copies the value of variables like reversed in the enclosing scope at the time it's created, there's no need for a second context parameter to -sortedArrayUsingComparator:. Blocks are really handy, but if you find yourself writing the same comparator block in multiple places in your code, you might be better off using a plain old comparator function and -sortedArrayUsingFunction: instead to prevent duplicate code, in keeping with the DRY principle. (Or you might consider how to restructure your code so that sorting is defined in only one place.)

Since items in an NSArray are all objects, very often the items themselves have a useful comparator method. When this is the case, the -sortedArrayUsingSelector: method is very handy. NSArrays of NSStrings are very common, as is the need to sort in a case-insensitive manner. Using NSString's -caseInsensitiveCompare: method, we can sort this way:

NSArray *tagNames = [NSArray arrayWithObjects:@"H1", 
                    @"body", @"A", @"Head", nil];

NSArray *sortedTagNames = [tagNames sortedArrayUsingSelector:@selector(caseInsensitiveCompare:)];
// sortedTagNames contains:
// @"A"
// @"body"
// @"H1"
// @"Head"

There's one more interesting way to sort an NSArray: we'll look at the -sortedArrayUsingDescriptors: method and the NSSortDescriptor class next week.