What are the key concepts for an iPhone Developer to learn? [closed]

Answer 1

For developing successful iPhone apps, you need to know more than the typically offered Objective C best practices. Of Objective C practices, knowing the delegation pattern and memory management rules is very important for iPhone development.

There are lots and lots of APIs in the Cocoa Touch framework. The more APIs you are familiar with, and have played with, the better. That alone can take a significant amount of time.

You should learn that an event driven framework such as Cocoa Touch mostly calls your app, not vice versa.

You should learn how UI design works differently on touch based devices with tiny displays. Too few developers see if their grandma (et.al.) wearing thick tri-focals can even see some of their icons. Or whether a UI control can be operated while using a device one-handed while walking around. Etc.

You should learn how to design for constrained system. A mobile device likely does not have seemingly infinite amount of backing swap memory. So you need to learn how to measure and strongly control an app's memory footprint. And the battery on a small device will last a lot longer if your apps can leave the CPU mostly idle. So you will want to learn how to profile your algorithms and how to pick efficient ones.

I suggest getting an older slower iOS device, and learning how to make apps work well under those limitations first. (I've heard that Apple used to do that internally as part of their training.)

Answer 2

There are a number of concepts which make up the basics of iOS development. There coding patterns, techniques and some general tidbits that you should know about.

Coding Patterns:

• Key Value Observing (KVO): Allowing one object to respond to changes of another object's properties by registering the "Observer" with the "target" object. For more on KVO, see Apple's Key-Value Observing Programming Guide.

• Model View Controller Pattern: In the Model View Controller Pattern (MVC) objects generally fit into one of three roles. You have the Model, which is, at the most basic level, your data. (Or, more accurately, how the data is structured.) You have the View, which is what the user sees on the screen. Lastly, you have the Controller, which coordinates between the the model and the view. The controller is where your business logic usually goes. Apple has documentation on MVC as well.

• The Singleton Pattern: Singleton classes (that's an oxymoron, "singleton classes") are classes which can only have one instance of them in an application at a time. Singletons are good for "factory classes", or objects that you won't want two of. The UIDevice class, for example, is a singleton class. (Your iPhone isn't an iPad and an iPhone at the same time, now is it?) In the iOS SDK, singleton classes often have a special initializer. Instead of the usual [[Class alloc] init], singletons often use [SingletonClass sharedInstance]. ("shared"Instance, since the instance is "shared" across your application.) Note that Singleton classes work a little differently in regards to memory management.

Coding Techniques:

• Delegation: Many objects in the iOS SDK have delegate objects, that respond to certain "events" of the object that they are "delegating" for. For example, you could have a UIPickerView (a scrolling wheel with a bunch of choices on it). When the user chooses a date, the delegate, ( a different object than the UIPickerView) will implement – pickerView:didSelectRow:inComponent:, which will allow that object to do something in response to the action.

• Memory Management: Unlike many languages, be it Java, Javascript, or anything in between usually manage memory for you. On iOS, Objective-C does not do this. You need to keep track of all of your objects and release them when you are finished with them. The rule of thumb is that for every alloc, retain, new, and copy, you must have a corresponding release, or autorelease. (A note about autorelease: People often have trouble with understanding autorelease. Generally speaking, local "autoreleased" objects are guaranteed to be around until the end of method call. No more, no less. Of course, if you retain the object elsewhere, it will still have a reference from that point.)

• ARC: With the iOS 5 SDK, Apple introduced Automatic Reference Counting. It's important to understand the basics of how this works, even if you plan on working with manual reference counting. You never know when you'll run into ARCified code that you'll need to work with.

• Data Persistence: Many folks who are getting started also have a challenge with saving data in between launches. You have three options, depending on the type of data. You can use NSUserDefaults, the Documents Directory (or one of a few other folders in your App's directory hierarchy, or Core Data. You also use these in conjunction with each other, as they are not mutually exclusive.

Basic Concepts:

• IBOutlets and IBActions: IBAction and IBOutlet are typedefs for void. IBAction methods return void and are marked as IBAction so that Interface Builder can allow you to attach them to objects in your NIB files. IBOutlets are "placeholders" in code that are used to allow you to set properties, or otherwise interact with objects in your NIB files via Objective-C code.

• The @ symbol: The @ symbol represents Objective-C constants, since Objective-C is a superset or Framework on top of C. In C, a string constant would be "My string is cool.". In Objective-C it would be @"My string is cooler in Objective-C." Other examples of the @ symbol being used to distinguish between C and Objective-C are keywords like @implementation, @property, @class and @end.

• Pointers: Dave DeLong explains this in his answer, but this is something else to make sure you know as well.

Finally, I leave you with a word of advice:

Although you have StackOverflow, and it really is a wonderful resource, know how to use the Apple Documentation. Enjoy your journey and good luck Getting Started!

Good luck!

Answer 3

These aren't necessarily specific to iPhone development, but without them, you will not ever get it.

• Pointers - know what a pointer is. Know why we need the dynamically allocated memory versus statically allocated memory. (I know this may sound trivial, but in my experience, this is the #1 thing that newcomers have the most trouble with) This is because you'll never* deal with raw objects in Objective-C. You always deal with object references. (ie, you never deal with an NSString, but always an NSString *) However, there are things that look like objects, but aren't actually. NSRects are structs and they can be stack-allocated. NSInteger is simply a typedef for a primitive int. If you don't know what a pointer is, you'll go crazy wondering when you're supposed to put in a * and when you're not.

• Memory Management - the iPhone does not have garbage collection. You must manually manage your memory. Accept that and move on. The rules for memory management conventions in Objective-C are trivial. Memorize them, and always remember to use them.

_{* the only time you'll deal with stack-allocated objects are blocks (^{ ... }) or when you're doing something fiendishly devious.}