Integrating AppleScript and Cocoaby Brad Dominy
Welcome back! Last time, we introduced some of the ideas behind why a developer would want to add AppleScript support to their applications. A scriptable application can be integrated with other scriptable applications to accomplish a series of tasks in a autonomous and intelligent manner. This adds value to an application by making it part of a greater scheme, one controlled by the user to accomplish their work.
While this has always been true of scriptable applications, the ability to implement scripting was much more difficult under the classic Mac OS and the Mac ToolBox API. Mac OS X introduces a new set of programming tools and frameworks that include scripting from the ground up, so to speak. The tools are Project Builder and Interface Builder, that are used to write your programming code and design your user interface.
Cocoa is the advanced set of frameworks inherited from the days of NeXTStep, and you should think of it as a collection of objects that you can arrange, along with objects of your own, to create your application. By using these new technologies, you gain a lot of scripting support for free. We demonstrated how to create a scriptable application in four steps last time, by simply turning on the built-in scripting support found in Cocoa.
This time we are going to peek behind the curtain and describe the overall scripting system found in Cocoa, and how it relates to this built-in scripting. We will start writing some ObjC code to support more of this built-in scripting.
An "Objects" Refresher for Both Cocoa and AppleScript
To begin, everyone should understand what objects are and how they are used in object-oriented programming, since both AppleScript and Cocoa are object-oriented in nature. You can think of an object as a container for programming code that has a particular use within the application. These objects may contain variables that are used to capture the state of the object, and they define the methods that operate on them. You can think of the state of an object as its properties. A common example from the real world is a car, which has a particular make, model, color, VIN, price, etc. The methods are actions that do something with the object. In our car example, "accelerate" would be a method that increases the velocity of a car, and the velocity is a property of this particular car.
This introduces two new ideas, those of classes and instances. Classes are the generic type of objects being created. The class "car" encompasses all kinds of four-wheeled motorized transports and it does not, in object-oriented speak, refer to any one car, but it acts as a template from which particular cars will be made.
The objects created from the class definition are called instances, and they each contain all of the pieces that are described in the class definition. You should also remember that classes are, for the most part, abstract ideas that shape what the objects will look like. It is the instances of those objects that actually do something in your programs.
One last idea about Object Oriented Programming (OOP) we need to discuss is the idea of inheritance. Sticking to our car example, a car is an abstract description of a type of vehicle. A vehicle could be a car, but it might also be a truck, or a plane or anything that moves around. So a vehicle class would be the superclass, or the class from which the car class descends from. The car class is a subclass of the vehicle class. Similarly, the vehicle class may have a superclass itself, like, say, an abstract class called "transport." This can continue over and over again, but eventually the proccess must end at the highest superclass, which is just the root object class. You can't get more general than that!
In Cocoa, the root object class is called
NSObject, and all other
Cocoa objects are subclasses of it. This superclass-subclass
relationship between objects is refered to as an object hierarchy, with
the top of the hierachy always being
NSObject and more and more
specific classes descending from each other. You would define a
different type when you want to separate generic objects from each
other; this is how you could separate cars from trucks or planes, which
would all be vehicles, but know that not every vehicle is a car, for example.
|Brad covered lots of ground here. What are your comments and observations?|
By now, you are probably wondering, "What is the point of having all these classes if I just want to make a car?" The idea is that objects inherit properties and methods from their superclasses, which means you could define common properties or actions in the superclass, and not have to worry about them when you create instances of the subclass.
So the vehicle class could define a variable to hold its velocity as a number, and also define a method called "accelerate" that increases that variable by some amount. Then when I create the subclasses of car, truck, train, plane, etc., they all inherit the velocity variable and the accelerate method. So I can set their velocity and increase it with the accelerate method, with no additional code.
Of course, you can overide the methods in the subclasses; for instance, if you want to limit the velocity of a car to 80 mph, the car class would define its own accelerate method that has a check to make sure the current velocity is no more than 80.
There are many other aspects of object-oriented programming, but the most important parts, as far as scripting is concerned, are the object heirarchy and the inheritance of variables and methods from superclasses.