Code:

NSUInteger       newIndex[]   = {0, row};
NSIndexPath	*newPath      = [[NSIndexPath alloc] initWithIndexes:newIndex length:2];

There is quite a few things assumed in these 2 simple lines of code. Let's break it down into newbie terms.

First you must understand that a "section" is an area of grouped rows in a tableview. You see this in many iPhone apps. Think about the "Settings" app. Click around in it and you will see sections.

Next you must understand that a tableview assigns the property "cellForRowAtIndexPath" with a NSIndexPath value. In short this property looks at the NSIndexPath's first value for the section the row is in and then the second value for the row itself for the value you are trying to retrieve. 

The 0 in the "newIndex[]" is for the "section" in the tableview, stating this will be the 1st section (in this case the only section). and the "row" is for the...well row in the section within the tableview.

So in the next next line with "*newPath" you have the code assigning the "newIndex" with a "length" of 2. What you are reading here is that tableview should look two nodes deep in your array of sections with each node in your section array caring an array of row nodes (think nested arrays).

The first node is the section array and the second node is the row.
So in our example:
Node 1 = specific node in section array (here its node 0), 
Node 2 = specific node in row array nested in Section array.

If the above is italicized text is confusing see screen shot I attached. The picture may make it easier to understand. Array 0 is the array of section nodes, where each section node contains an array of rows.





An different way to create the NSIndexPath that might be easier to read is to use this function.

Code:

NSIndexPath *myPath = [NSIndexPath indexPathForRow:myRow inSection:mySelction];

Here is the exact definition from Apple Documentation, with the knowledge I gave you above it should be a bit more clear now. A "category" by the way, is, in short, a way to add extra methods to a class without subclassing it.

Many methods of UITableViewDelegate take NSIndexPath objects as parameters and return values. UITableView declares a category on NSIndexPath that enables you to get the represented row index (row property) and section index (section property), and to construct an index path from a given row index and section index (indexPathForRow:inSection: method). Because rows are located within their sections, you usually must evaluate the section index number before you can identify the row by its index number

I found myself wondering what the difference between these two items are in Objective-C and when exactly to use them. In short, you should use @class in your header file and #import in your implementation file with the exception of conforming to a protocol (interface in .net) in your header file, in which case you need to use #import not @class in your header file, but of course there is a little more to it than that. Here is the best answer I got from stackoverflow.com -- I added a few things to make the below statement a little easier to read, because we don't all speak nerd.

Use a forward declaration (AKA "@class")  in the header file if needed, and #import the header files for any classes you're using in the implementation. In other words, you always #import for the files you're using in your implementation, and if you need to reference a class in your header file use a forward declaration as well.

The exception to this is that you should #import a class or formal protocol you're inheriting from in your header file (in which case you wouldn't need to import it in the implementation).

There you go the simple and easy explanation on when to use @class and #import. Now back to the code.

Have you ever seen a silk teddy bear. They're nice, soft, smooth and comforting. They take something scary and unmanageable like a grizzly bear, and make the animal manageable, gentle and silky smooth.

In the just-released Beginning iPhone 4 Development, authors Jeff LaMarche and David Mark team up with Jack Nutting to take the ever-growing and changing iOS and break it down into manageable chunks. In this informative and light-hearted read, the authors bring the new edition with updates to key subjects like Core Data, Grand Central Dispatch and iPad/iPod programming specifics. Full of step-by-step instructions and intuitive pictures, Beginning iPhone 4 Development serves as a perfect guide for the novice yet remains effective as a quick reference to the experienced developer. In the end it's all about having fun, making an app you want and not about getting frustrated at trying to understand the idiosyncrasies of iOS. With their latest offering, LaMarche, Mark and Nutting get you on the right path.

Problem:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Popovers cannot be presented from a UIBarButtonItem that is not in a toolbar or navigation bar already.'

Solution:
You can get the error for a number of reasons, but I'm betting it's because you didn't declare your UIBarButtonItem correctly in either your header file or your implementation file. You might have done something like this in your header file.

@interface TestInterface : UIViewController <UIPopoverControllerDelegate, UISplitViewControllerDelegate>
{
    UIButtonItem    *button
}

@property (nonatomic, retain) IBOutlet UIBarButtonItem *Button;

Notice the Button variable is declared with one "B" capitalized and the other "b" is not.

And then in your implementation file you tried to call the button by using the non-capitalized declaration.
Like so:

[poc presentPopoverFramBarButtonItem:button ...];

Explanation:
Usually what causes this is, what I would consider, but technically is not, a syntax error. You tried to call a variable that doesn't exist, kinda. The real kicker is there is no compile error. Which is correct, as you should be able to declare code as such in the header file, it just makes it easy for the user to reference the incorrect variable name.

I'm done! After a summer of surprises, swings, and roadblocks I finally finished this book, a few months behind schedule, but it's done. The last objective-C book I read was by the de facto in Mac OS X development Mr. Hillegass, (my post) I embarked on the journey of reading a book on iPhone development with the man in iPhone teaching Jeff LaMarche. Jeff is every bit as good at breaking down complex topics and making them seem easy as my .Net home skillet Scott Hanselman. In short these dudes are just smart, but they'll never tell you that and they write some good books.

This book is an easy read and provides hands on examples on how to use many of the tools provided with the iPhone SDK 3. The book is spot on with it's examples, but I'm betting new Objective-C users might have trouble following along when  xCode 4 comes out. xCode 4 is quite a bit different graphically than 3 and may render the step by step instructions in this book out of date.

Overall if you are into programming on the iPhone, this is a great book to start, given you have a base working knowledge of Objective-C and an advanced understanding of programming in general.

 

Error Readout:
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'interface'

Fix:
Added a semicolon.

Explanation:
It's important to remember that this was occurring before the interface tag, which meant it was happening in a file I was importing. In this case it was a header file with an enumeration in it that were not showing an error with a missing semi colon.

It's a good question.

There are some types that are not derived from NSObject, these types are called "Primitive Types." Some examples of these types are

1. int
2. bool
3. short
4. long
5. double
6. char

Sooooo basically any type that is not derived from the NSObject class is a Primitive type and does not require a "*".

Now I bet you are wondering how do I figure out if it's a primitive type or not.

1. An easy way is to look at the color of the syntax in xCode, is it deep blue or a sky blue? Deep blue = primitive type, but this is not entirely reliable as the standards for coloring syntax can fluctuate or change.
   




2. You can option-click on the object after you have typed it in xCode, click the little book in the upper right hand corner, when the class reference viewer comes up, look and see if it inherits from NSObject. If it doesn't it's Primitive and you don't need a "*".
   
   
   
   
   

Note:
There are some alternatives to using the primitive type int, such as the reference type NSInteger, which has some nice baked in functionality of distinguishing between 32 bit and 64 bit, but not all primitive types have an alternative reference type in Objective C.


Just for fun:
In .Net they have primitive types too(I believe they call them value types), kinda. The compiler recognizes traditional primitive types and therefore lets you use the syntax

int i = 5;

But despite the compiler letting you do this, this type still maps back to System.Int32. All things in .Net are mapped back to System.Object. Everything is a reference type, but .Net lets you keep the traditional syntax instead of writing:

System.Int32 i = new System.Int32(5);

UPDATE: Enumerations types also do not use a * (star) and they have the sky blue coloration that may make you think you need a *.





When starting a new project you have the ability to  select a template of premade projects. Two examples of this are
    1. Navigation Based Application
    2. View Based application

When these templates are selected xCode will create the appropriate base controller for you in interface builder, such as "Navigation Controller" or a "View Controller" it will also create the appropriate classes for you with some of the most commonly used delegate and datasource methods along with the appropriate methods to override.

With a new project and selecting Window-based application, you are simply creating a blank slate in which you have to create nearly everything. It's rarely advantageous to use this unless, you are creating something outside the templates offered or you are learning how all the pieces fit together.

The Problem:
I was getting a white screen with no data in a UITableView on it in the iPhone simulator.

The Solution:
I had my initialization code for the array in the the "loadView" method and not the "viewDidLoad" method

Explanation:
Don't read self.view in -loadView. Only set it, don't get it. The self.view property accessor calls -loadView if the view isn't currently loaded. There's your infinite recursion. I'm guessing UITableView calls a View [pretty good guess since "view" is in the name. :)] which in turn caused my recursion.

This was a stupid little error that caused me about 30 minutes of my life due to the fact I didn't get any build errors. A simple copy and paste moved me forward.

Update: I think it might be important to distinguish the differece between loadView and viewDidLoad. (below)

loadView is the method in UIViewController that will actually load up the view and assign it to the "view" property. This is also the location that a subclass of UIViewController would override if you wanted to programatically set up the "view" property. viewDidLoad is the method that is called once the view has been loaded. This is called after loadView is called. It is a place where you can override and insert code that does further initial setup of the view once it has been loaded.

When is the right time to use dot notation vs bracket notation in objective C, or should I not use dot notation at all? I searched around for information on this, read quite a few opinions, but this blog post seems to give an answer of why.  I quote the most important part; I suggest you don't read the blog post. The post is very technical and what you really want to know is right below here. If you need to know the details, eschatology does a great job at giving them.

Most important parts of blog post:

• Use dot notation to get and set objects’ state.
• Use bracket notation to invoke objects’ behavior.

Eschatology -- http://eschatologist.net/blog/?p=160

A bit of a dark name for a blog, but the name doesn't affect the quality of the post.

Things covered in the book

The Problem:
Not being able to do a simple compare in an "if statement" between two alpha or numerical statements while programing in objective C.

The Solution:
NSOrderedSame

Example Of Use:
This compares the value of "key" to the value of "support." If they are equal then you get a return value of true.

if ([key compare:Support] == NSOrderedSame)

Explanation:
For some reason Objective-C decided to make it a little bit harder to compare values. Instead of just using the traditional way "[key compare:Support]" return a true value for the if statement OR "([key compare:Support] == 0) OR "([key compare:Support] == true)" they decided to make it a little bit more complex. As demonstrated above. I'm sure the writers of Objective-C have a good reason for this, but one more level of abstraction could make Objective-C that much friendlier to it's programmers and isn't that what it's all about in the end...getting more people to develop in your language.

Some of other comparisons you might want to use are:
NSOrderedAscending -- The left operand is smaller than the right operand.
This is equivalent to using "<" in most languages.

NSOrderedDescending -- The left operand is greater than the right operand.
This is equivalent to using ">" in most languages.

Error Readout:
1st Error:
this class is not key value coding-compliant for the key managedObjectContext

2nd Error:
NSImageCell's object value must be an NSImage

Fix:
1st Error:
There is one prominent reason you could get this answer. You didn't spell your property correctly when you were binding it to....well....whatever you want to bind it to, in my case it was an Array Controller.

My problem however had nothing to do with this. When I created a new project after I upgraded to xCode 3.2 I forgot to check one very import checkbox, Create document-based application (Note: it was not a check box in older version of xCode it was a full icon selection upon creating a project). By not checking this I created a big variety of problems for myself. One of the errors occurring when I didn't check the Create document-based application, was the error this class is not key value coding-compliant for the key managedObjectContext.

2nd Error:
This error is very clear in it's issue. I was creating an entity with a property of native type binary and the compiler wanted NSImage. Grrr but I should be able to pass an image as a binary object, I would say to myself as I had urges to break my laptop and anything else in reach over my knee. My fix again was to simply create a project and remember to click Create document-based application. I know this is not your typical fix, but in case someone else runs into this issue the same way I did I hope they find this and it will be a quick and easy resolution.

Explanation:
All of this pain could have been resolved from the very beginning had I known to click Create document-based application. It was a silly little mistake that cost me a few hours. In my defense however I was under the impression of not checking Create document-based because in Hillegass's book he states that for this exercise we will not be using NSDocument, but NSPersistentDocument instead. It turns out this still means you have to check Create document-based application.

I will state that I should have known something was wrong when I didn't have a MyDocument.xib in the Resource folder after I created the project.

I've attached an image, mainly because blog posts are more fun when there is an image, but also because it shows where this one simple little check box changed my life for a hot minute.

Error Readout:
unable to read unknown load command 0x80000022

Fix:
Upgrade to xCode 3.2 with the 10.6 libraries.

Explanation:
This error doesn't do anything to your application except provide some really annoying output to your Debugger Console. File under annoying. You can get xCode 3.2 DOWNLOAD HERE for free at the apple website. It will require you to create a login.