Wednesday, April 22, 2009

Creating Location-Aware iPhone Applications with CoreLocation

The inclusion of GPS on the iPhone opened up a world of possibilities for application developers. Developers could now create location-aware applications: applications that take into account the user's location when determining what action to take or what content to display. The cornerstone of this location support is Apple's CoreLocation API. This article provides a look at how you can develop location-aware applications using CoreLocation.

CoreLocation functions using several different mechanisms for determining a user's location. This includes GPS, cell-tower triangulation, and (according to reports) Wi-Fi network location databases. In older hardware that does not support GPS, this mechanism is expectedly missing. Each of these mechanisms varies in their accuracy, with GPS generally being considered the most accurate. However, regardless of what your target hardware supports, you can generally get a good sense of a user's location using CoreLocation.

Before you can begin developing your application with CoreLocation, you need to add the CoreLocation framework to your XCode project. This framework is located at:

/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator2.0.sdk/System/Lbrary/Frameworks

You may change iPhoneSimulator2.0.sdk to match your application's target platform. Once this framework is included, you can begin developing location-aware applications.

The CLLocation object represents the actual location information. This includes not only latitude/longitude, but also speed, course, and altitude information. The CLLocation object is generated and returned by the CLLocationManager object. The CLLocationManager is used to deliver location events to your application via the CLLocationManagerDelegate protocol.

The CLLocationManager class allows you to specify various parameters to be used when determining location information. The distanceFilter parameter specifies how much a device must move laterally before a location update event is triggered. For example, if you were writing an application that tracks how far you drive over a period of time, you may want to have a larger distance filter set than you would for an application that tracks how far you walk over a period of time. Of particular importance is the desiredAccuracy parameter. This parameter specifies how accurate the location returned should be. There are 5 supported values for this parameter: kCLLocationAccuracyBest, kCLLocationAccuracyNearestTenMeters, kCLLocationAccuracyHundredMeters, kCLLocationAccuracyKilometer, and kCLLocationAccuracyThreeKilometers. The desired accuracy is one of the things that must be taken under consideration when scoping the requirements of your application. If you are looking for course grained location information -- that is, what city a user is in as opposed to which street corner they are standing at -- then you may not need to incur the penalties that highly accurate location information comes with. Performance is of key importance when determining what accuracy to require. This includes processing performance, battery life performance, as well as the amount of time required to provide the location. When you initially request a location, the CLLocationManager provides the quickest -- and least accurate -- location available. It then works to further refine the location to ensure it is the most accurate. If getting a rough location quickly is more important to your application than pinpointing exactly where your user is, then you may want to use a less accurate measure than someone else developing a geocaching application.

Now that we've discussed some of the basics of CoreLocation, let's take a look at how to include it within your application. To start, whatever object will be making use of the location information must implement the CLLocationManagerDelegate protocol. This protocol contains 2 methods:

- (void)locationManager:(CLLocationManager *)manager didFailWithError:(NSError *)error

and

- (void)locationManager:(CLLocationManager *)manager didUpdateToLocation:(CLLocation *)newLocation fromLocation:(CLLocation *)oldLocation

The didFailWithError method is called whenever location services are unable to determine a user's location. This includes situations where a user denies your application permission to determine the location. The didUpdateToLocation method is called whenever a successful location has been performed. The newLocation parameter provides the new coordinate information, while the oldLocation parameter has the previous location information. If this is the first time that didUpdateToLocation has been called, oldLocation will be nil.

To start using CoreLocation, you must instantiate a CLLocationManager object like so:


#import

...snip...

CLLocationManager *locationManager = [[CLLocationManager alloc] init];

// Set the delegate
locationManager.delegate = self;

// Set your accuracy and filter parameters here
locationManager.distanceFilter = ...
locationManager.desiredAccuracy = ...

[locationManager startUpdatingLocation];

...snip...


The startUpdatingLocation method begins the process of determining the user's location based on the specified parameters. When a successful location is determined, it will call didUpdateToLocation on the specified delegate object. We can now write out our delegate methods:


- (void)locationManager:(CLLocationManager *)manager
didUpdateToLocation:(CLLocation *)newLocation
fromLocation:(CLLocation *)oldLocation
{
// Disable future updates to save power.
[locationManager stopUpdatingLocation];

NSLog(@"oldLocation : %@", oldLocation);
NSLog(@"newLocation : %@", newLocation);
}

- (void)locationManager:(CLLocationManager *)manager didFailWithError:(NSError *)error {

[locationManager stopUpdatingLocation];

NSLog(@"ERROR : %@", error);
}


You notice here that we call stopUpdatingLocation as soon as a location is determined. This is to preserve battery life, as location services do draw quite a bit of power. If you have specified a high level of accuracy, you may not want to stop updating immediately, as it takes a while to get very accurate location results.

This was a quick introduction into how the CoreLocation classes work. With the 3.0 firmware including Google Maps support, you should be able to get map-based applications up and running with little effort. If you can't wait until then, take a look at Route-Me for an EXCELLENT mapping component for your iPhone or iPod Touch. I'm using it in one of my applications, and can't recommend it highly enough.

Thursday, April 16, 2009

4 (+1) Priceless iPhone Development Blogs

If you're like me, you'll find the best way to learn new technologies or techniques is not by reading the "official" product documentation, but by studying the works of others. I've learned most of what I've learned about iPhone development not by reading Apple's developer documentation, but by studying what other developers have done with their apps. To that end, I've compiled a list of the most useful iPhone development blogs that I've found. I'm sure you'll find yourself writing much better code after you look at some of the things these developers have done.

0. iDev4iPhone

(aka This Blog) Yes, it's shameful that I plug my own blog in this post. However, it's worth subscribing to. I strive to regularly post on useful topics, but I also know the value of posting links to valuable resources I've come across. I'll be sure to share the knowledge whenever I get the chance.

1. iCodeBlog

iCodeBlog has some very detailed information, particularly with respect to game development. Game development is one of the hottest areas in Apple's AppStore, but there really isn't as much useful documentation about it on the web. Although iCodeBlog doesn't have as much content as some other sites, what is there is very useful and easy to understand.

2. iPhone Developer Tips

iPhone Developer Tips contains a wealth of information on several different topics. The content is not iPhone specific, in spite of its name. This blog also includes numerous tips on general Cocoa/Objective-C development. The XCode hints and tips, alone, make this site worth subscribing to.

3. iPhone SDK Articles

iPhone SDK Articles provides some of the most practical articles on iPhone development around. Many of them are targetted to new developers, making this one of the most valuable resources when beginning your first project. This blog also covers a lot of topics that are often overlooked, such as how to make advanced use of SQLite or Internationalization.

4. Mobile Orchard

Mobile Orchard is one of my favorite iPhone development blogs because of the shear volume of information it provides on a broad range of topics. The focus is not just on "How to Code X, Y, or Z." There is also tons of practical information on the AppStore and general programming topics. Their article on avoiding AppStore rejection should be required reading for all new iPhone developers.


Good luck!

Thursday, March 26, 2009

Easy iPhone Data Storage using SQLitePersistentObjects, Part 2

Yesterday, we discussed SQLite Persistent Objects (SPO) and how it can make data persistence quicker and easier in your iPhone application. We covered the basics of how to setup your database, setup your data model objects, and perform basic save/retrieval on those objects. Today, we'll go over some of the more advanced functionality that SPO provides, and how you can leverage it in your application.

For our discussion, we will reuse the data model objects we defined yesterday:


@interface PersonModel : SQLitePersistentObject {

NSString *name;
NSString *nickname;
NSDate *dateOfBirth;

AddressModel *address;
}



@interface AddressModel : SQLitePersistentObject {

NSString *street;
NSString *city;
NSString *state;
NSString *zipCode;
}


1. Querying by Property

When you persist an object using SPO, dynamic class methods are automatically added, allowing you to query by any persisted property. This reduces the amount of SQL code you would have to write, since you no longer need to write your own "SELECT * FROM ..." statements. For example, if we wanted to get a list of all of the people in our database who were named "John Smith", we could write:


NSArray *smiths = [PersonModel findByName@"John Smith"];


That's all there is to it. We can query by any property that is persisted by calling the findByXXX method.

2. Querying by Criteria

What if we wanted to retrive objects using arbitrary criteria? SPO provides methods for that, too. The SQLitePersistentObject class includes a method findByCriteria that allows us to specify our search criteria. For example, to locate all people named "John Smith" that also have the nickname "Johnny", we could write:


NSArray *people = [PersonModel findByCriteria:@"WHERE name = 'John Smith' AND nickname = 'Johnny'"];


We can make this call as simple or as complex as necessary. Include equations, NULL checks, etc. The findFirstByCriteria method works in the same way, however it only returns the first object that matches the search criteria, as opposed to an NSArray of objects.

3. Indices

If we're going to be querying by name, it's important that we define indices so that our SQL queries execute quickly. We can add indices by overriding the indices class method in our data model objects. To add an index for the name property, we would simply write:


+(NSArray *) indices {
NSArray *index1 = [NSArray arrayWithObject:@"name"];
NSArray *indices = [NSArray arrayWithObject:index1];

return indices;
}


This method returns an NSArray comprised of NSArrays that contain the properties that should be used in building the index. Once this is added, our name property will be indexed, and we should see a performance increase when dealing with larger datasets.

4. Transient fields

What if there are properties we do not want persisted? SPO also provides a mechanism for marking properties as transient, thereby not including them within the database. To mark a field as transient, we need to override the transients method in our data model objects. To make the nickname property transient, for example, we would write:


+(NSArray *)transients {
return [NSArray arrayWithObject:@"nickname"];
}


If you examine your database structure after making this change, you will see that the nickname property is no longer stored in the database. This is useful when you wish to make calculations or other values accessible as properties, but want to obtain them at runtime, rather than from the database.

5. Determine if Objects Exist in the Database

The existsInDB method allows us to determine if our data model object has been persisted to the database. For example:


PersonModel *p = [[PersonModel alloc] init];
p.name = @"Joe Blow"

BOOL saved = [p existsInDB]; // Should return NO

[p save];

BOOL savedYet = [p existsInDB]; // Should return YES


This convenience method allows us to determine if our changes have been saved already.

6. Object Deletion

SPO provides 2 methods for deleting objects: deleteObject and deleteObjectCascade. The deleteObjectCascade also allows us to specify whether the child rows associated with the deleted object should also be deleted.

7. Reverting Changes

Often, it is necessary to revert changes that have been made to an object, but not saved to the database yet. SPO provides us with 3 methods for performing an "undo", of sorts. These are: revert, revertProperty, and revertProperties. The revert method will revert all changes made to an objects since the last save to the database. The revertProperty and revertProperties allow us to revert changes to one or more properties, respectively, by name.

This concludes our 2-part introductory lesson on SQLitePersistentObjects. If the rumors are true, iPhone 3.0 will include support for CoreData for data persistence, so it remains to be seen how much of this will be necessary once most users move to iPhone 3.0. In the meantime, however, these tips should help you get your application developed quicker and with far fewer headaches.

Wednesday, March 25, 2009

Easy iPhone Data Storage using SQLitePersistentObjects

In a previous article, I briefly discussed one of my favorite supplemental iPhone development libraries, SQLite Persistent Objects (SPO). SPO provides object-relational persistence for the iPhone in a manner similar to what Hibernate provides for the Java crowd. For simple applications that don't need overly complicated SQL statements, SPO makes getting a functional application written much quicker. This article is part 1 of a 2-part series on SPO that I will be doing. Part 1 focuses on getting started with SPO, including setting up your project and database. Part 2 will focus on some of the additional functionality that SPO will add to your data objects and how you can take advantage of them in your application.

1. Getting the SPO source

The SPO project page () is the starting point for working with this library. I encourage you to take a look at the Wiki to get an idea of how the library works and what it is capable of. While there is a snapshot available for download, the easiest way to get a copy of the source is to download it via Subversion. Go to the Source tab on the project page for more information on the SPO repository.

Grab a copy of all of the SPO classes and add them to your project. For a clearner project structure, I tend to group these classes together to keep them out of the way.

2. Configure your project

Before we can compile and use the library, we need to add the SQLite framework to our project. SQLite is built in to the SDK, so it's just a matter of referencing it within our project. To do this, right-click on the Frameworks folder in XCode and select Add->Existing Framework. The framework you should be looking for is named libsqlite3.0.dylib.

That's all there is to it. We should now be able to begin our database development using SPO.

3. Setup your database

SPO will need to locate a database that is part of your project. It will not create an empty one for you. Luckily, creating a database is very simple if you have installed XCode correctly. Simply open a terminal window and type:

sqlite3 .sqlite

This will create the new database in your current working directory. To add this file to your project, simply drag and drop it into the Resources folder within your project.

Whether you're working with SPO or not, you need to make sure that the database is properly setup and accessed at the runtime of your application. Apple's SQLiteBooks example gives boilerplate code that you can copy and paste right into your AppDelegate class. This code will determine if a database exists for the application and, if not, create one for you by copying the default database out of your Resources folder. We have made a couple of small changes to ensure that SPO is also notified of your database location. Simply paste the following code into your AppDelegate class to get started:


- (void)createEditableCopyOfDatabaseIfNeeded {
// First, test for existence.
BOOL success;
NSFileManager *fileManager = [NSFileManager defaultManager];
NSError *error;
NSArray *paths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES);
NSString *documentsDirectory = [paths objectAtIndex:0];
NSString *writableDBPath = [documentsDirectory stringByAppendingPathComponent:@".sqlite"];
success = [fileManager fileExistsAtPath:writableDBPath];
if (success) {
[[SQLiteInstanceManager sharedManager] setDatabaseFilepath:writeableDBPath];
return;
}
// The writable database does not exist, so copy the default to the appropriate location.
NSString *defaultDBPath = [[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:@".sqlite"];
success = [fileManager copyItemAtPath:defaultDBPath toPath:writableDBPath error:&error];
if (!success) {
NSAssert1(0, @"Failed to create writable database file with message '%@'.", [error localizedDescription]);
}
[[SQLiteInstanceManager sharedManager] setDatabaseFilepath:writeableDBPath];
}


Make sure you replace ".sqlite" with the appropriate name before compiling. Once this is in place, add the following line to your applicationDidFinishLaunching method to setup the database:


[self createEditableCopyOfDatabaseIfNeeded];


SPO and your database are now ready for business.

4. Create your data object

With our database setup out of the way, we can now begin working with SPO. We will create a couple of simple data model classes to demonstrate how SPO provides object persistence. If you choose to implement this code in your project, make sure you define your @property statements correctly. We have omitted them for sake of time. Our data model interfaces look like this:


@interface PersonModel : SQLitePersistentObject {

NSString *name;
NSString *nickname;
NSDate *dateOfBirth;

AddressModel *address;
}



@interface AddressModel : SQLitePersistentObject {

NSString *street;
NSString *city;
NSString *state;
NSString *zipCode;
}


You'll notice that all we had to do to SPO-enable our data model classes was to extend SQLitePersistentObject. This will take care of the primary key, as well as provide all of the helper methods we will make use of later on.

Now that our models are setup, we want to save an entry to our database. We can create our PersonModel object like this:


PersonModel *p = [[PersonModel alloc] init];
p.name = @"Joe Blow";
p.nickName = ...
p.date = ...

AddressModel *a = [[AddressModel alloc] init];
a.street = @"123 Main St."
...

p.address = a;


To save the PersonModel object to the database, all we need to do is call:


[p save];


That's it. No need to worry about opening a connection or any other SQL statements necessary. Our AddressModel object that is associated with the PersonModel object will also be saved with this call. There is no need to save it with a separate call. To load all of the PersonModel objects stored in the database, we simply call:


NSArray *people = [[PersonModel class] allObjects];


This will return an NSArray containing all of the PersonModel objects and their associated AddressModel objects.

Conclusion

As you've seen, SQLite PersistentObjects makes SQLite development on the iPhone much quicker. Stay tuned for Part 2, where we'll investigate some more advanced functionality that SPO provides, including queries and indices.

Tuesday, March 24, 2009

One more iPhone library...

Hot on the heels of my post on iPhone Development Libraries, Joe Hewitt has announced an initial release of his newest project, The 320 Project. This library incorporates open-sourced components from the Facebook iPhone application. Those of you who have played around with Facebook on the iPhone know that a lot of work has gone into developing this application. So, open-sourcing the components that make up much of the user interface is sure to be appreciated by the developer community.

One of the components I'm most excited to play around with is the TTPhotoViewController, designed to display photos in a similar way to Apple's Photo app. Its ability to pull in photos from multiple datasources -- not just the iPhone photo library -- is sure to provide a great deal of flexibility to developers.

Go ahead and check out the code. Joe warns that it's in alpha quality right now, but I'm sure it's going to improve rapidly.

Monday, March 23, 2009

iPhone Development Libraries and Frameworks you Need

The strength of a development platform is often tied to the number of third-party libraries that are available to enhance that platform. The iPhone is certainly no different. The Cocoa Touch classes and other libraries provided by Apple as part of the iPhone SDK provide a great starting point for application development. However, as always, there are missing pieces that other developers have been able to fill in. This article provides a brief overview of some of my favorite third-party -- and, most importantly, free/open-source -- libraries for iPhone development.

1. SQLite Persistent Objects

One of my favorite third-party libraries for the iPhone is SQLite Persistent Objects. (We'll call it SPO, for short) SPO is to SQLite on the iPhone as Hibernate is to other relational databases on the Java platform. SPO allows for developers to persist normal Objective-C objects to the database, without the need to write SQL code or manage SQL connections. All that is needed for an object to be persistable is for it to extend the SQLitePersistentObject class. From there, a simple [save] call will allow you to save this object to the database for retrieval later.

By including SQLite within the iPhone OS, Apple has provided a simple mechanism for storing and retrieving data. However, many developers don't want to waste their time writing SQL code, especially when the data being written/read is not terribly complex. Using a library like SPO allows you to hit the ground running and make progress very quickly. Even more impressive is the querying capability that SPO provides. For example, if we have a data object called Person with first name and last name fields, we can query for people whose last name is 'Smith' simply by calling:

NSArray *people = [Person findByLastName:@"Smith"];

That's all there is to it! These query methods are dynamically added to the class, without the need for custom code. We can even execute arbitrary SQL in a query by calling the findByCriteria or findFirstByCriteria methods.

SPO provides a very powerful framework for object persistence. Take a look at it, and you will see it will dramatically cut down your development time. In the coming weeks, I will post a detailed tutorial on how to use SPO within your application, as well as provide some things you need to keep in mind when doing so.

2. GData Objective-C Client

Google web services and the iPhone seem like a match made in heaven. The wealth of information that Google can serve up can provide almost limitless possibilities on a device like the iPhone. Google's official GData Objective-C Client makes this functionality to OS X and iPhone developers, alike. Included in this library are classes for accessing Blogger, Google Calendar, YouTube, and many other Google properties.

The GData library is easy to use, with a great deal of features for developers of all types of applications. Most important to new developers is the inclusion of numerous sample applications. This framework makes developing complex applications for the iPhone almost effortless. Imagine combining the GPS built into the iPhone with a Blogger client or YouTube to post detailed information about an event or activity. Use the built-in camera and OCR to provide an easier way to perform web searches. You name it, this library can assist with it.

3. JSON Framework

As we discussed with the GData Objective-C Client, web services can provide some amazing capabilities to the iPhone. Many services choose to avoid complex web services protocols like SOAP in favor of REST-based or other types of web services. The JSON Framework provides a mechanism for parsing and generating JSON (JavaScript Object Notation) data for accessing webservices.

Like the SQLite Persistent Objects library, the JSON Framework makes working with JSON easy by extending your existing Objective-C objects. The included parser also makes it easy to create Objective-C objects from their JSON representation. In cases where there is no native, Objective-C client for a web service, the JSON Framework makes it easy to work with online services.

4. Simple iPhone Image Processing

The iPhone is never going to make your Mac Pro obsolete when it comes to image editing. However, the Simple iPhone Image Processing library does provide some basic image processing functionality to your application.

According to the project page, this library provides:

  • Canny edge detection
  • Histogram equalisation
  • Skeletonisation
  • Thresholding (adaptive and global)
  • Gaussian blur
  • Brightness normalization
  • Connected region extraction
  • Resizing

Combined with the iPhone semi-decent camera, this library can greatly extend your ability to process and enhance images in your application. The library is designed to perform well within the hardware constraints of the iPhone, and seems to be very careful when it comes to memory management to ensure it plays nicely with your application.


This is just a brief rundown of some of the libraries I've had the pleasure of working with. Have you encountered any other useful libraries? Post them in the comments! I'd love to take a look at them!

6 Tools for Beginning iPhone Development

Before we can discuss the ins-and-outs of developing for the iPhone, we first need to identify the tools you'll need to get your application written. Like any platform, there are some great (and not-so-great) tools at your disposal to get your application written, tested, and debugged. This article will identify some of my favorites, which should set you well on your way to developing for the iPhone.

0. An Apple Developer Account

Before you get started writing for your iPhone, you'll need an account on Apple's developer site. I often hear some confusion from people new to iPhone development who do not understand how the system works. An account on Apple's developer site is free. You can download the tools, write applications, and run them in the iPhone simulator at absolutely no cost. However, if you want to run your application on real hardware, you'll need to pay $99 for a program account. This gets you the ability to digitally sign your code for both development and, eventually, production. Once you've completed development and your code has been approved by Apple, you can start selling your creation on the App Store. As I'm sure you're aware, Apple takes 30% off the top, but if your app is worthwile, the remaining 70% will let you recoup the $99 developer cost in no time.

1. A Mac

Like it or not, the development tools for the iPhone require a Mac. Not just any Mac, mind you. You'll need to be running one of the (somewhat) newer Intel-based Macs. While this may be a pretty substantial barrier to entry for most folks, it is one you'll need to get past if you ever want to successfully develop for the iPhone. I own a 2.4GHz MacBook Pro that I use as my development machine. I maxed out the RAM to 4GB, which makes all the difference, particularly when you're running multiple tools at once. Most likely, you won't need to have a beast of a machine to get your application written. Most developers won't need an 8-core MacPro with 32GB of memory just to get their application up and running. An iMac, MacBook Pro, or even a MacBook should be more than adequate for your needs.

2. XCode Developer Tools

The only supported development environment for the iPhone is Apple's own XCode. Coming from the Java world, I've been spoiled with great development environments like Eclipse, Netbeans, and IntelliJ IDEA. XCode is not one of these environments. The interface seems a bit clunky, and it lacks a lot of the features I've gotten used to with Java development, such as refactoring. But, it does include the excellent Interface Builder for laying out user interfaces. While Netbean's Matisse still takes the cake in that department, Interface Builder is more than sufficient, and perfect for iPhone development.

XCode does include a number of built-in utilities for performance monitoring and finding memory leaks, so you will have a range of tools in your arsenal. In addition, you probably want to download some of the tutorials on Apple's developer site. These will give you a good starting point for developing your application.

The most useful piece of the XCode environment is the iPhone simulator. The simulator allows you to develop and test your application prior to spending $99 for a program membership. There are some issues with the simulator, and it's not 100% identical to running your application on real hardware. The one thing I know I failed to keep in mind was that my iPhone does not have a 2.4GHz processor and 4GB of RAM. I was unpleasantly surprised when my app repeatedly crashed and took 10 seconds between view changes. You'll definitely want to test your application on real hardware at some point, but developing for the simulator will get you headed in the right direction.

3. SQLite Manager for Firefox

Now that we've got the basic tools out of the way, we're ready to start examining some of the additional utilities you should use when writing your application. The first of these is the SQLite Manager plugin for Firefox. This browser plugin allows you to view and manipulate SQLite database files. The iPhone OS contains SQLite out-of-the-box, so it has become the de facto method for data storage. Using SQLite Manager, you can prepare your database for testing and deployment without having to resort to SQL creation scripts. This is a really useful tool in getting your application started.

4. SoapUI

Some of the most popular iPhone applications make use of web services to enhance their functionality. Many of these web services make use of SOAP, the Simple Object Access Protocol, for sending and receiving data. SoapUI is a graphical utility that allows you to test web service connectivity and prepare for SOAP development. Using SoapUI, you can prepare your request objects that are used to get information from the service, and inspect the response object you receive. SoapUI provides a great resource for beginning with web services development.

5. Subversion

Repeat after me..."Version control is your friend." Using version control allows you to track changes made to your source code, tag changes as a release, and revert back to previous versions if necessary. While there are a number of different utilities for version control -- PVCS, CVS, Git, etc. -- I make use of Subversion. It's easy to install and get started with. Plus, Google Code and Sourceforge also allow developers to use it for their project hosting. Regardless of which package you use, you definitely want to have a good revision control system in place before you start writing serious code.

6. LLVM/Clang Static Analyzer

As I mentioned before, your iPhone is not your MacBook Pro. It has a finite amount of memory, so you need to make sure you're using it responsibly. The primary language for iPhone development is Objective-C. This is not Java. You don't have the benefit of automatic garbage collection. As a result, you need to ensure you're allocating and deallocating memory properly. The LLVM/Clang Static Analyzer performs static analysis on your code to identify programming errors, hidden memory leaks, and naming schemas that violate the Objective-C naming convention. Static analysis is not foolproof. There are a lot of false positives to deal with, and understanding the output can be difficult. However, if you're developing a complex application, a static analysis tool will help you to ensure that you're squeezing every bit of performance out of it that you can.


This is just a short list of tools you can use to get started with iPhone application development. Later on, I'll examine some of the more useful libraries and frameworks that will help you get your application up and running in no time.