Tag Archives: Computer Science

Adventures in Objective-C – Part 2

On the subject of the Stanford University (iTunes U) iPhone Programming class.

I had a professor at university who walked in the door on the first day, slammed a book on the podium, and in a loud Germanic accent bellowed, “There will be no stupid questions in this class! The only stupid questions are the ones you don’t ask.”

To my young, impressionable 17 year-old mind, it made so much sense that I thought it almost profound.

The problem is, youthful idealism can be rapidly eroded away.

There are stupid questions. The ones that used to particularly annoy me were when a fellow student would ask the professor a question that had just been covered or had just been asked by a different student and answered by the professor.

I remember sitting in class thinking, “Pay attention next time. You’re wasting my time.”

These unpleasant memories all came flooding back to me during the first few videos of the Stanford iPhone class and I really thought I might have to give the whole endeavor a miss. When I was 17, I didn’t have to take blood pressure medicine.

Fortunately, within the first few classes either the offending students were gone, or they’d gotten with the program. Since then, it’s really been invaluable to my study of iPhone programming. Typically, books have never worked well for me hen learning a new programming language/paradigm/whatever.

Hands on is what works for me but even that needs some “seeding” with some information. The iPhone developing environment/community was stifled for some time. Apple’s (some say) draconian non-disclosure agreement for early developers prevented source code and discussions from appearing on the net. It even prevented books on the subject from being printed. Thorough as Apple’s documentation is, it’s better as a reference than as a starting point. There hasn’t been a whole lot out there until recently.

I’ve completed plowing through “Beginning iPhone Development: Exploring the iPhone SDK” (Dave Mark, Jeff LaMarche) and am most of the way through initial development of my first iPhone application – more on that another day – so I’m not coming at this class completely cold. Nonetheless, it has helped me resolve numerous logical problems with my in-development application. This is not because the detail or content of the course is far-reaching, but simply because…

Let me digress for another moment.

Here’s another thing that I learned very quickly at university. Not all professors are created equal. In the Computer Science Department in the College of Engineering they had two kinds of professors. They had staff professors who carried a typical teaching workload and they had professionals who worked at some of the local companies who came in and taught the 7:20AM classes and then nipped off to to their real jobs.

You could guarantee those 7:20 classes were the best. In Computer Science knowledge and theory are essential but there is no substitute for solid, real-world experience. The professors who had both were awesome.

So back to the class. The two lecturers, Alan Cannistraro and Evan Doll, both Apple employees working in iPhone development, really demonstrate their knowledge of the subject. It comes across best when they’re answering some of those (good and/or not-so-good) questions from the class. More than once, when they switch over to do some code on-the-fly or respond to something that’s just askew from their prepared lecture I have those, “A Ha!” moments that get me closer and closer to understanding.

I feel this class is really a good example of what iTunes U can do. While I’m not exactly sure what the incentive for universities are to put things in iTunes U, this has convinced me to check out some other courses.

I read yesterday that the Stanford iPhone class has had over a million downloads. Impressive. Of course, if that represents 1 million viewers, (which I doubt it does, but we’ll just use that number for giggles) that still means that at least 900,000 will do nothing with what they learn. That leaves a 100,000 who will try and 90-95% of the them will probably have to go buy Macs to do Xcode development on. I can see why Apple seems happy to share its employees in this project.

Adventures in Objective-C – Part 1

I’ve been trying to get my head around Objective-C and Mac/iPhone programming for the last month or so. At this point, I think I’ve got most of the major concepts down.

As an Object Oriented (OO) language, it bears a certain familial resemblance to Java, which I typically program in these days.

While I’m not going to say that Java is a “better” language, I do feel that parts of Objective-C are a capricious conglomeration of logic-unfriendly syntax.

It’s the implementation of these things that’s irritating. Obviously there’s a certain amount of familiarity and personal preference, but over this series of articles, I’ll highlight a few. I’ll start with a simple syntax example.

Generally in OO programming, you break things into programatic “objects”, which define the properties of an object and the actions that such an object could do.

In Java speak, these are properties and methods, in Objective-C they are properties and selectors. In Java you “call” a method, in Objective-C you “message” a selector. Same thing, different terminology. Clear as mud? Good, then let’s continue.

Typically, properties on an object are protected behind accessor method, such as “getXXXX” and “setXXXX” where XXXX is the property name. Sometimes these are called “getters and setters” – that’s in Java, of course, Objective-C calls them “accessors” and “mutators”. Objective-C also uses a slightly different convention. Mutators are still “setXXXX” but accessors are just “XXXX”, which can result in a little ambiguity as to whether you’re looking at the actual property variable or the accessor selector.

Java uses “dot-syntax” to refer to an object’s methods, so far example, if you have an object called “newton” and it has a method called “dropApple()”, you would access it like this:

newton.dropApple();

Objective-C uses square bracket syntax, so the same thing would be:

[newton dropApple];

…and if each one took a single parameter, they would look like this:

newton.dropApple(velocity);

vs

[newton dropApple:velocity];

It gets a little muddier when we move to two parameters.

In the example above, I’ve passed a variable called “velocity” which we’ll say is of object type “Speed”. Let’s add a second object type of “Height”, with an instance variable called “headHigh”

We would DECLARE the java method like this:

void dropApple(Speed incomingSpeed, Height incomingHeight) {

…. do stuff

}

and call it like this

newton.dropApple(velocity, headHigh);

Objective-C would be declared like this:

(void)dropApple:(Speed *)incomingSpeed dropHeight:(Height *)incomingHeight {

…. do stuff

}

and called like this:

[newton dropApple:velocity incomingHeight:headHigh];

Here’s my first irritant, Objective-C selectors use named parameters – which I like better than Java, but only on the second and subsequent parameters. The first is identified by the name of the selector. It’s just a mixed-bag inconsistency. I hate inconsistencies in my programming languages.

This same system also helps cause Objective-C messages to tend to be very long.

Java and Objective-C also share another trait, that being if a message/call returns an object, you can then, in turn message/call that object immediately without passing it through an unnecessary intermediary object variable.

Let’s say we’re somewhere inside an object that is running active code – like a program. I can always reference back to myself with the special keyword “self”, so if my program has a property of type Person, and a Person object has a property of type “phoneNumber” and a PhoneNumber has a method that returns a formatted representation of the number, we can get to that formatted string in java like this:

self.getPerson().getPhone().format();

Self being an object with a getPerson() accessor that returns a Person, which in turn has a getPhone() accessor which returns a Phone, which in turn has a format() method to return a pretty string. It’s not uncommon to see these things strung together 4 and 5 levels deep inside Java code, and it’s a bit difficult to read, but convenient, and sometimes a lot better than assigning each step to a new variable, like this:

Person aPerson = self.getPerson();

Phone aPhone = aPerson.getPhone();

String aString = aPhone.format();

How does Objective-C handle this? Like this:

[[[self person] phone] format];

Simpler, right? Yes and No. It’s irritating. Why? Because you have to know, in advance, how many layers deep you are going so that you can put the right number of square brackets on the left. If not, you have to come back later and add them, which really “breaks the stride” of typing. It may be less letters to type, but it takes longer to type.

Ah, but along comes Objective-C 2.0 with a “solution” to this: Dot-Syntax!

Oh, but it isn’t the same as Java’s dot-syntax. Objective-C’s dot-syntax only applies to properties, not selectors. (Actually, properties are selectors, you’re not seeing the actual variable, but these are special) That means you can do this:

self.person;

or

self.person.phone;

but not

self.person.phone.format;

instead it would be:

[self.person.phone format];

Why is this a problem? You don’t always know if something is a “property” or “selector”, and since the IDE (XCode in this case) helps fill this stuff in from it’s calculated list of available options, it promotes a certain natural “coding laziness” by letting the IDE do the work of remembering names for you.

So you start typing “self.pe…” and about that time it suggests “self.person”, so you hit the arrow and continue typing “.ph…” and it breaks in again and suggests .”phone” so you hit the arrow to accept and then you start “.format” and nothing happens, then you realize, “oh, it’s not a property”, so you go back and delete the period. That’s bad typing technique. And, then, of course, you have to go back to the beginning of the clause to add a “[” and the end of the line to add “]”

I know, I know. “Gripe, gripe, gripe, gripe”

Next time (probably) “Why there isn’t a consistent method for delegates, actions and ad hoc delegates”