In earlier blogs, I must have complained about the lack of apple support because figuring out how to talk to a USB device seemed so hard. But now I think it is amazing that I was able to use some apple code without any understanding of the structure of the code, and talk to my data both synchronously and asynchronously in USB mode. (I did not tackle the HID side of the story yet).
This is not the first time I have “lifted” some piece of code, assembler code, C functions, etc, because that code does the job, without worrying too much about how I could write that bit of code myself.
But this time, I backed off from the light stone project and I am taking the time to learn Cocoa and Objective C. Ail Ail Ail. MAMA MIA! This is not at all like learning a programming language. It is like learning a high level language like Matlab, Sas, except that it is NOT user friendly, it is programmer friendly, maybe. I have been trying to figure out why learning this “language” blocks me.
A simple example from chapter 14 from Hillegass’s book. This example is supposed to dazzle us with the ease with which we can create a graphic window and draw on it. This ease is achieved by having all the work of creating windows all done for us by functions already written by apple.
But unlike a program like Matlab which hides the bells and whistles from beginners, Cocoa requires you to grab 20 different threads and weave them together. For someone like me who functions on understanding and not on memory, this is very taxing. Not unlike a cooking recipee, except you don’t choose where the ingredients are kept. grab a project from the “File” menu, create a new class from the class menu on “main menu.nib” then grab an icon from “cocoa containers” and drag it on “window”, find the “info” option on the “tools” menu on the “interface builder” … On and on! And I am supposed to remember all this for all the different kinds of interface??? Yak.
The other thing that blocks me is the arbitrariness of the code which is nicely swept under the carpet in the book. Page 224 instructs us to enter the code
- (void)drawRect:(NSRect)rect
{
NSRect bounds = [self bounds];
[[NSColor redColor] set];
[NSBezierPath fillRect:bounds];
}
Voila, no explanation as to what this code does, how it is structured, why this particular code.
The miracle tool on the mac is AppKiDo 0.94. In the kindom of the blind, it is the stick that may just save you from axphyxiation and death from despair.
Type in the method “bounds”, and you find it belongs to NSview. It returns the windows size and coordinates.
type in the method “redColor”, and you find it is a class method which belongs to NSVview.
it is a class method because it is not applied on an instance.
OK so you have an RGB code, what does “set” do? Too many possibilities, better to go to the window, click on NSObject, click on NSColor look under all classes methods and all instances methods, and there is “set”, under instance methods. So apparently redColor applies to a class, but returns an instance, and so “set” is and instance method that says use this color for future drawing. Clear as Mud this beautiful code, no?
NSBezierPath is a class, so fillRect is a class method. it fills the rectangle with the above color. Note that NSArray is another class under NSobject. Now with NSArray, you created an instance of the class with alloc and init, before you used it. Why in this case, we would act on a class to draw in a window instance. Well that is the arbitrariness I am talking about.
At the level of the programmers, it is all very clear and beautiful and grammatical, and built with simple rules all developers can use to build these beautiful programs the user craves for her/his new Mac OSX platform. But at the level of the beginning user, it is all a medley of contradictory invocations best learned by memory. How can such a language replace basic C? YAK.
