Just a side note... I find this very handy under Xcode->Preferences:
Automatically insert closing "}"
I don't know why it's not checked by default, but there you go.
Wednesday, September 30, 2009
Auto Insert Closing Braces in Xcode
Just a side note... I find this very handy under Xcode->Preferences:
Automatically insert closing "}"
I don't know why it's not checked by default, but there you go.
Basics of Xcode
My buddy already knows the Mac well enough to move around and has installed Xcode before. I'm not going into the install process; the instructions are clear enough. After the install, you can launch Xcode from Developer:Applications:Xcode.app.
On first launch, you'll see the Xcode News; I usually uncheck the display again box. You can restore it from under the Help menu. Close it for now.
Click File->New Project. You get something like this:
Lots of options to choose from. In the selection column on the left, you can pick from iPhone OS and Mac OS X options, as Xcode is used to develop software for both platforms. We're interested in the iPhone OS section for now. Under "Library" you can produce a static library, which is basically a collection of code that you can create to re-use across multiple application and share with your friends and family. That's a topic for another day.
Under "Application," there are a variety of choices. They are all ways to quickly generate a foundation of pre-written code for specific needs. You could choose any one of them and by adding and removing the write code, create another one from the list. There is nothing special about any of the project templates other than the fact they generate extra code for you that you might have needed to write anyway.
That said, choose the "Window-based Application," click on "Choose...," name the project something like 'MyCoolApp' and save it. This should pop up:
There's a lot to look at. Here's the high level things we're concerned with:
Groups & Files is where the source code, resources, libraries and lots of other things live. You'll be spending much of your time in the Classes group. You add, move, and remove groups as you desire in order to best organize the project. A well organized project is a happy project.
The contents of whatever is highlighted here will show up in the upper, right side, dual-colored pane. Any files that you highlight will show up in the lower right side editor pane, including pictures and plists, but not the likes of xib/nib files.
It's useful to go backwards up the Groups & Files list, starting with Frameworks.
By default, the Frameworks group contains the basics: UIKit, Foundation and CoreGraphics. These libraries give you the basic tools to start writing sophisticated code. You'll end up using at least one thing out of each of them 99% of the time, so Xcode puts them there automatically.
Under Resources, you get a the MyCoolApp-Info.plist (or just Info.plist in some cases) and the MainWindow.xib. The plist is the property list for the application and is used to set, as would be expected, various properties concerning your application, including the name that is to be displayed on the iPhone (otherwise, your app would be named the same as your project, i.e. "MyCoolApp").
The xib file (called a 'nib' file, despite the spelling; Mac OS X uses nibs while iPhone uses xibs. Coding for the Mac has been around longer and the name has stuck, since nibs and xibs essentially do the same thing) contains "freeze-dried code." Without going into too much detail, it part of the system (which launches the Interface Builder app) where you can easily layout your user interface without having to write code. However, you will need to write code to actually get your nifty new layout to do anything when the user taps on the screen.
The Other Sources group never gets touched. You can look at the two files in it, but don't touch them. I may mention somethings about 'main.m' in a later post.
And lastly, the Classes group is where you will do the main bulk of your work (unless you create another group that you'd prefer to work in). Under the Window-base Application template, there are two files, MyCoolAppDelegate.h and MyCoolAppDelgate.m.
The .h file is a header file; it is in essence a public view into the code. If someone is interested in how your code works (as located in the .m file), they would look at the .h file (because the .m file is typically not available for viewing). The .m file is the source code itself and where all the work happens. You will have multiple .h and .m files in any app that is of reasonable complexity.
That's it for now. More coming soon, hopefully.
On first launch, you'll see the Xcode News; I usually uncheck the display again box. You can restore it from under the Help menu. Close it for now.
Click File->New Project. You get something like this:
Lots of options to choose from. In the selection column on the left, you can pick from iPhone OS and Mac OS X options, as Xcode is used to develop software for both platforms. We're interested in the iPhone OS section for now. Under "Library" you can produce a static library, which is basically a collection of code that you can create to re-use across multiple application and share with your friends and family. That's a topic for another day.
Under "Application," there are a variety of choices. They are all ways to quickly generate a foundation of pre-written code for specific needs. You could choose any one of them and by adding and removing the write code, create another one from the list. There is nothing special about any of the project templates other than the fact they generate extra code for you that you might have needed to write anyway.
That said, choose the "Window-based Application," click on "Choose...," name the project something like 'MyCoolApp' and save it. This should pop up:
There's a lot to look at. Here's the high level things we're concerned with:
Groups & Files is where the source code, resources, libraries and lots of other things live. You'll be spending much of your time in the Classes group. You add, move, and remove groups as you desire in order to best organize the project. A well organized project is a happy project.
The contents of whatever is highlighted here will show up in the upper, right side, dual-colored pane. Any files that you highlight will show up in the lower right side editor pane, including pictures and plists, but not the likes of xib/nib files.
It's useful to go backwards up the Groups & Files list, starting with Frameworks.
By default, the Frameworks group contains the basics: UIKit, Foundation and CoreGraphics. These libraries give you the basic tools to start writing sophisticated code. You'll end up using at least one thing out of each of them 99% of the time, so Xcode puts them there automatically.
Under Resources, you get a the MyCoolApp-Info.plist (or just Info.plist in some cases) and the MainWindow.xib. The plist is the property list for the application and is used to set, as would be expected, various properties concerning your application, including the name that is to be displayed on the iPhone (otherwise, your app would be named the same as your project, i.e. "MyCoolApp").
The xib file (called a 'nib' file, despite the spelling; Mac OS X uses nibs while iPhone uses xibs. Coding for the Mac has been around longer and the name has stuck, since nibs and xibs essentially do the same thing) contains "freeze-dried code." Without going into too much detail, it part of the system (which launches the Interface Builder app) where you can easily layout your user interface without having to write code. However, you will need to write code to actually get your nifty new layout to do anything when the user taps on the screen.
The Other Sources group never gets touched. You can look at the two files in it, but don't touch them. I may mention somethings about 'main.m' in a later post.
And lastly, the Classes group is where you will do the main bulk of your work (unless you create another group that you'd prefer to work in). Under the Window-base Application template, there are two files, MyCoolAppDelegate.h and MyCoolAppDelgate.m.
The .h file is a header file; it is in essence a public view into the code. If someone is interested in how your code works (as located in the .m file), they would look at the .h file (because the .m file is typically not available for viewing). The .m file is the source code itself and where all the work happens. You will have multiple .h and .m files in any app that is of reasonable complexity.
That's it for now. More coming soon, hopefully.
Starting from Scratch
A co-worker of mine is interested in learning Objective-C. He has literally no coding experience at all, so I'm going to try and help him along. As you can imagine, I'm starting with the absolute basics. He is computer savvy, so that makes it a bit easier since I can often hand wave application level topics (like what a 'Group' is in Xcode and how to add files to it for example).
I think that Objective-C is a actually a fairly reasonable first language to start with (compared to C/C++/Java). Xcode and Interface Builder hide a lot of the nitty-gritty away from the user, so the ramp up time to get something fun and meaningful going is fairly short. You still have to take time to understand the concept of pointers and memory management which I think is a good thing. I always have been very conscientious my stack and heap issues and I think it has made me a better programmer. Luckily, memory management is very well defined (here), and the basic concepts are quick to grasp.
My plan is to get him up and running with the basics of computer science and present to him some best practices early on so that if he takes to it like a fish to water, he is got a solid foundation.
I think that Objective-C is a actually a fairly reasonable first language to start with (compared to C/C++/Java). Xcode and Interface Builder hide a lot of the nitty-gritty away from the user, so the ramp up time to get something fun and meaningful going is fairly short. You still have to take time to understand the concept of pointers and memory management which I think is a good thing. I always have been very conscientious my stack and heap issues and I think it has made me a better programmer. Luckily, memory management is very well defined (here), and the basic concepts are quick to grasp.
My plan is to get him up and running with the basics of computer science and present to him some best practices early on so that if he takes to it like a fish to water, he is got a solid foundation.
Subscribe to:
Comments (Atom)