The @quantity@ and @itemName@ methods were removed from @ShoppingListItem.m@ when you added the
@property declarations in Chapter 11 (inside section 11.6, subsection “Declaring Properties”). What was the build error you were getting when they were still left around?
Order of code in implementation files
As far as the order in which methods are listed is concerned, in general no it doesn’t matter. One exception is if you include a method in an implementation file but don’t have a separate signature for it in the
@interface. Any method which calls this “private” method needs to be listed after it in the implementation, or you’ll get a warning (there are ways to avoid being tied to this order, like declaring a class extension at the top of the implementation file to list any “private” methods that are only called from within the class’s own implementation and not by any other class).
You’ll find different Objective-C coders have different patterns for how they lay out their implementation files. Some just add methods in the order they code them, others have very a prescribed order.
I tend to use this order:
# Primary functionality for the class
# General helper methods/utility stuff to support the primary functionality
# Delegate methods when an instance is used as a delegate to some other object
# Initialization methods, then the @dealloc@ method
@synthesis, then any custom getters/setters
This order means that I can see the basic functionality in a class implementation the moment I open the file; the predictable stuff like properties and @init@ method(s) goes right at the bottom, as most of this can be deduced just by looking at the class’
@interface. Often, this means working from the bottom up, as properties etc are generally added pretty soon after I create a class. Occasionally I may stray from this order, such as if the delegate methods are the primary functionality of the class.
I also split these sections using
#pragma mark lines:
#pragma mark -
#pragma mark Properties
@synthesize someProperty = _someInstanceVariableName;
#pragma doesn’t mean anything when compiled, but is used amongst other things by Xcode in the drop-down box to jump to a method (it’s along the top of a code file, the right-most part of the items on the left…). The first line with a hyphen inserts a horizontal line, the second line inserts a bold heading. This makes it really easy to see at a glance what’s in this particular file.
Going back and learning C may well be a helpful step, but it depends how motivated you are! In some ways, a book dedicated entirely to C will spend a lot of time covering things that are needed pretty rarely in Objective-C applications, at least while you’re still at the early stages of Cocoa programming. My suggestion would be to look at Stephen Kochan’s Programming in Objective-C 2.0 (2 ed) as this will give you a thorough understanding of necessary bits of the C language in an Objective-C context.
I’d also suggest delving further into Cocoa, not necessarily by buying more books. Have a think about some suitable first app projects with reasonable goals (perhaps basic internet connectivity or ways to utilitize different facets of the basic Cocoa AppKit visual interface controls). Take a look at the documentation available from Apple, which will in general be called something like “X Programming Guide”, where X is the general topic. This will give you an idea of the gaps in your knowledge. I’d perhaps suggest not looking at Core Data just yet, as it makes use of various advanced topics that can turn it into a bit of a black box for beginners. On the other hand, it’s a good technology to aim for!
Above all else, learn by experimentation. If that means throwing yourself right in at the deep end, do it, on the understanding that you’ll come across lots of things that you’re going to need to spend time learning. Download some of Apple’s sample code projects (there are lots so try to look for something that might achieve something you’re looking to learn next) to see how things work. I’d also suggest looking at other people’s code on e.g., Github. Start with a few smaller open source projects and pull them apart to see how they work. BUT don’t expect every piece of code you find to be “doing it right”. Some of the larger Open Source applications, particularly those that have been ported from other platforms, do some extremely weird and wonderful things with lots of low-level trickery.
If you’d like more Cocoa books, then take a look at these (in no particular order):
If you’re surprised there are so few books on Mac programming in particular, then you should have seen what it was like 10 or 15 years ago. Trust me, the market is comparatively flooded right now!