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.
Thursday, January 29, 2009
Ah, the rosy memories of Palm
I am an ex-Palm programmer. It's been years, but I loved the whole programming culture that Palm had created. I loved their UI design philosophies, their hardware, the conventions, the fantastic API support, I loved it all. I was a Palm freak. Then not too long after the IPO'd, it got kinda sad there at Palm, it seems. There was no more love being pumped into their wonderful products. The kool-aid had gone sour for me (that, and the project I was working on that I so adored got cancelled), so I bailed out and found other new-fangled toys to play with (which was never quite as enjoyable). But here, now, many years later, Apple has restored my faith in the idea that you can indeed have an exquisite, easy to use interface on a handheld device. And more importantly you can provide excellent developer support at the same time. Or at least that's how it seems to me for now... I reserve the right to be cynical. I've eaten from the Cupertino tree many times in the past; not all its fruit are sweet and delicious.
Music Scales
I was practicing my scales up until last night when I ever so smartly cut the tip of my finger. Now I can't play until the skin grows back. Oh, well.
But before that, I was practicing my major scales. I now finally understand the Circle of Fifths/Fourths. Basically, starting with C, you can move clockwise to determine the number of sharps or counterclockwise for the number of flats you'll have in the major scale. Moving clockwise, you determine the next note by the fifth of the previous note. So, from C, you get D (2), E (3), F (4), G (5). The scale of G has one sharp in it. Which note is sharp, then, you ask?
Well, the scale always takes the form of whole, whole, half, whole, whole, whole, half intervals. On the C scale, which has neither flats or sharps, this is: C D EF G A BC. See? C >> D >> E > F >> G >> A >> B > C, where >> is a whole interval and > is a half interval.
Let's do the same with G: G >> A >> B > C >> D >> E >> F# > G. Two wholes, one half, three wholes, one half. Since E to F is normally a semitone, we have to use F# instead to make a full interval. Thus G has one sharp, and that sharp is F#.
Similarly, going backwards in fourths from C, the next note in the circle (going counter clockwise is F: C (1), D (2), E (3), F (4). F has one flat in it: F >> G >> A > Bb >> C >> D >> E > F. Normally, B to C is a semitone. But to get from A to "B?" (where ? is either normal, flat or sharp), you must use a half interval, which is the note of A#/Bb. Since you have already used up the letter A in the scale alphabet, it is more clean to use Bb.
An additional point to not forget is that the circle progresses forward based on the the previous note. So in the above examples, the next note to consider from F is Bb (the fourth note) and from G is D (the fifth note) and that each progression adds an additional flat or sharp.
Here's an interesting tidbit: in musical notation, you can tell which key you are in by the number of sharps or flats that are drawn next to the clef symbol. Of course, you have to know which notes will be flat or sharp, but I haven't figured out how to easily memorize all of that yet. I just understand the patterns.
But before that, I was practicing my major scales. I now finally understand the Circle of Fifths/Fourths. Basically, starting with C, you can move clockwise to determine the number of sharps or counterclockwise for the number of flats you'll have in the major scale. Moving clockwise, you determine the next note by the fifth of the previous note. So, from C, you get D (2), E (3), F (4), G (5). The scale of G has one sharp in it. Which note is sharp, then, you ask?
Well, the scale always takes the form of whole, whole, half, whole, whole, whole, half intervals. On the C scale, which has neither flats or sharps, this is: C D EF G A BC. See? C >> D >> E > F >> G >> A >> B > C, where >> is a whole interval and > is a half interval.
Let's do the same with G: G >> A >> B > C >> D >> E >> F# > G. Two wholes, one half, three wholes, one half. Since E to F is normally a semitone, we have to use F# instead to make a full interval. Thus G has one sharp, and that sharp is F#.
Similarly, going backwards in fourths from C, the next note in the circle (going counter clockwise is F: C (1), D (2), E (3), F (4). F has one flat in it: F >> G >> A > Bb >> C >> D >> E > F. Normally, B to C is a semitone. But to get from A to "B?" (where ? is either normal, flat or sharp), you must use a half interval, which is the note of A#/Bb. Since you have already used up the letter A in the scale alphabet, it is more clean to use Bb.
An additional point to not forget is that the circle progresses forward based on the the previous note. So in the above examples, the next note to consider from F is Bb (the fourth note) and from G is D (the fifth note) and that each progression adds an additional flat or sharp.
Here's an interesting tidbit: in musical notation, you can tell which key you are in by the number of sharps or flats that are drawn next to the clef symbol. Of course, you have to know which notes will be flat or sharp, but I haven't figured out how to easily memorize all of that yet. I just understand the patterns.
Monday, January 19, 2009
On Musical Triads
I'm teaching myself guitar. Today, reading "The New Complete Guitarist," I got to the part on scales and chord theory. I already know how to play basic open and barre chords, but I feel I need to learn the details before I can advance my skills. Not unlike how I learn how to program. I very much expect this to change as I learn more, but here is what I am starting with.
1st: Major scales have a "root" note. C is the typical main scale (due to characteristics to be described later) and so its root is of course: C.
2nd: Intervals on the major scale occur between the notes. This gives us either a "tone" or a "major second" such as C to D or a "semitone" or a "minor second" such as E to F. The concept of a "second" refers to the ordinal position relative to the base note being references (C and E in the above examples).
3rd: Interval jumps (second, third, fourth, etc) on the C major scale are organized thusly:
5th: The concept of the "dominant seventh" describes the addition of the seventh interval, though I am not sure why. "Dominant" refers to the fifth chord on the major scale.
1st: Major scales have a "root" note. C is the typical main scale (due to characteristics to be described later) and so its root is of course: C.
2nd: Intervals on the major scale occur between the notes. This gives us either a "tone" or a "major second" such as C to D or a "semitone" or a "minor second" such as E to F. The concept of a "second" refers to the ordinal position relative to the base note being references (C and E in the above examples).
3rd: Interval jumps (second, third, fourth, etc) on the C major scale are organized thusly:
- A single tone jump is a "major second"
- A single semitone jump is a "minor second"
- A double (three notes total, including the base note) jump that is entirely made of tone is a "major third." If there is a semitone in it, it is called a "minor third."
- With four tones or semitones, it is called a "perfect fourth."
- With five tones or semitones, it is called a "perfect fifth."
- For six and seven tones or semitones, it is called a "major sixth" and "major seventh" respectively.
- A: A BC D EF G A
- B: BC D EF G A B
- C: C D EF G A B
- D: D EF G A BC D
- E: EF G A BC D E
- F: F G A BC D EF
- G: G A BC D EF G
5th: The concept of the "dominant seventh" describes the addition of the seventh interval, though I am not sure why. "Dominant" refers to the fifth chord on the major scale.
Sunday, January 18, 2009
Loathing of Emacs
I try to stay out of the editor wars; I'm a firm believer in the adage that you should pick a text editor for programming and stick with it. Learn it as best you can (and as it suits your needs) and use it everywhere. But a couple of recent experiences have caused me to really loathe Emacs. Okay, not really Emacs itself, since I know so little about it, but I really dislike the Emacs' "force it on you" attitude I've encountered recently.
First issue was in my attempt to gently learn Common Lisp. The book I was reading insisted on using Emacs... for the basic reason it allegedly helps in tracking parentheses. No. Don't write a book (or a programming language) on the assumption that a newbie will have to learn not only the new language, but also an entirely new (and non-intuitive) text editor.
Second issue was reading a book that used Oz (via Mozart) as its primary source for programming examples. Not a problem, so long as you teach me a little about the language. I even d/l the interpreter for my Mac OS. When I launched it, it insisted that I have Aquamacs installed. What? Why? And why that particular version of Emacs? I already have Emacs on my Mac to begin with! I don't want another one. So, I install Aquamacs and run it (independent of Mozart). Fine, now I see what it looks like. But how the hell do I exit? Why does't Cmd-Q work? Why is Aquamacs insistent on not letting me shoot myself in the foot and letting my Mac handle the quit routine? C-x C-c didn't work either. I had to force quit my way out of Aquamacs.
Anyway, the whole past couple of events have been really frustrating. I know how hard Vim is to learn, but I never, ever had a problem killing the app in a GUI environment, nor has any language book insist that I use it for that particular langauge. I also know I don't know Emacs itself at all, but why are there people out there so gung-ho on it that I can't possibly use an alternative? My hope in reading these books was to learn a new language or two, not struggle with installing software. So, I'm off to learn some other programming techniques instead. Maybe one day I'll come back to those books, after I've sufficiently learned Emacs on my own terms.
First issue was in my attempt to gently learn Common Lisp. The book I was reading insisted on using Emacs... for the basic reason it allegedly helps in tracking parentheses. No. Don't write a book (or a programming language) on the assumption that a newbie will have to learn not only the new language, but also an entirely new (and non-intuitive) text editor.
Second issue was reading a book that used Oz (via Mozart) as its primary source for programming examples. Not a problem, so long as you teach me a little about the language. I even d/l the interpreter for my Mac OS. When I launched it, it insisted that I have Aquamacs installed. What? Why? And why that particular version of Emacs? I already have Emacs on my Mac to begin with! I don't want another one. So, I install Aquamacs and run it (independent of Mozart). Fine, now I see what it looks like. But how the hell do I exit? Why does't Cmd-Q work? Why is Aquamacs insistent on not letting me shoot myself in the foot and letting my Mac handle the quit routine? C-x C-c didn't work either. I had to force quit my way out of Aquamacs.
Anyway, the whole past couple of events have been really frustrating. I know how hard Vim is to learn, but I never, ever had a problem killing the app in a GUI environment, nor has any language book insist that I use it for that particular langauge. I also know I don't know Emacs itself at all, but why are there people out there so gung-ho on it that I can't possibly use an alternative? My hope in reading these books was to learn a new language or two, not struggle with installing software. So, I'm off to learn some other programming techniques instead. Maybe one day I'll come back to those books, after I've sufficiently learned Emacs on my own terms.
Subscribe to:
Posts (Atom)