Entries Tagged 'Cocoa' ↓

If you think you are ready to sink your teeth into Core Data, you should definitely start with Scott Stevenson’s tutorial.

Granted, you may want to use XCode 2.x for the tutorial, since that is what the tutorial is in. The differences between Interface Builder with XCode 2.x and XCode 3.x are pretty huge. The workflow is very different. (not to mention the interface, no pun intended)

I myself am still getting acquainted with XCode 3.x and my new Intel-based MacBook is in the shop, so I’m on the reliable old G4 iBook today, so it is an exercise I can work on in the interim.

Although you don’t need to be an expert at Cocoa Bindings, and there’s a strong chance you’re not. (not many people are) You will want to at least have covered the frustration of trying to work with bindings a little bit before sticking your nose into Core Data. And, as always, I will say if you’ve worked with Ruby on Rails and Active Record before, you will find Cocoa, Cocoa Bindings and Core Data a little less frustrating, but don’t expect it to be the same thing. It does still work like ORM (object relational mapping) so having a basic understanding how CRUD (create, retrieve, update, destroy) applications work with databases will help you a lot.

I’m now diving into XCode 3, thanks in no small part to my new black MacBook! One thing I had been looking forward to is the syntax highlighting that shows you the scope of the function or method or code block. Beautiful stuff. I had envisioned it myself several years ago, when I first learned CSS. (I’m sure I’m not the first and obviously not the only…)

Now that XCode 3 finally has code folding, though not as slick as TextMate’s code folding, it will flash the scope depth highlighting colors. But it goes away quickly. Here is how to turn it on to stay (it isn’t obvious or self-apparent).

View>Code Folding>Focus Follows Selection

Or a picture …

What’s the secret to getting good results from Icon Composer?

That’s actually very easy to answer. Most of all, a good design that follows the ideals set forth in Apples HIG (Human Interface Guidlines). But aside from that, you need to use Photoshop for the final image. Regardless of how you design the initial image, in Photoshop, create two layers. One for the image, one for a black shape that is the same outline as the image. Make sure you’ve got a square canvass in Photoshop also. Then, Save As… select TIFF as the format, with no compression and preserve layers.

Now drop that tiff file onto icon composer. You’ll get as good as possible at this point.

So, you, like me, want to make your own buttons in interface builder? I too struggled with this. Sometimes the help menu in Interface Builder just sucks. Well, generally it sucks. The problem you may have had, the problem I have had, is simply that your button graphic when clicked gets a white rectangular background during mouse down. Well, I finally figured it out! (This is for XCode 2.x and I don’t know how it goes in XCode 3, but I imagine it is similar.)

First off, of course, you need a graphic of your own. PNG format is best. Make it pretty in Photoshop, export it as a PNG with transparency, and at the desired size. Now, drag it into the XCode window, into the Resources group. Next, open your NIB file in Interface Builder. Add a button to the window. In the inspector palette, with the button selected, you need to change a few options. For Type: choose Square Button. Now, click on the Images tab in the window that holds Instances, Classes, etc… Drag your image onto the button you created. Then, with the button selected, uncheck the Bordered checkbox. Next, change the inspector from Attributes to Size, and resize the button to take up the amount of space you like. Finally, change the inspector palette back to Attributes, and change Behavior: to Momentary Change.

Try it out with command+R. Click your button and see it change the way you expected! No more white background on mouse down!

As an aside, if you don’t want the default shaded button on mouse down, create the alternate appearance in Photoshop. Save it like before as a PNG of the same size, but with a slightly different name. (just append ‘down’ to the end of the name) Add the button to the XCode project’s Resources group like before. In Interface Builder, it should now appear in the Images. Select your button. In the inspector palette, just copy the image name as it is in the Icon: field and paste that into the Alt. Icon: field and append ‘down’. Or, just type the name of the image minus the .png extension. Test it out. Your button should change exactly as you like with a mouse down action.

If you want more complex changes or animation, you’ll probably do well to use the Core Graphics API and build it yourself with that.

Back in the days before OS X came out, there was Yellow Box. If it were available today, it could easily be described as XCode and Cocoa for Windows. There was also Red Box back then, essentially the same as what we’ve got now: OS X on Intel processors. To make things interesting, it is well-known that iTunes exists for Windows, and (somewhat infamously) also known that Safari exists for Windows. Apple even makes a utility for Windows to manage AirPort base stations.

“So, what!?”, right?

No. It’s bigger than that. What Apple is tinkering with more and more in their skunkworks is the development environment formerly known as Yellow Box. That technology never went away. It may have languished with time somewhat, but thanks to Microsoft’s determined support for backwards compatibility, most of what was ever in Yellow Box still works. Sure, some of it is crufty and all that, but the recent developments with Safari and on-going development of iTunes for Windows is indicative enough that they’re definitely toying with the idea of releasing Yellow Box once again.

This makes perfect sense. Macs run on Intel. Windows runs on Intel. Mac users can install Windows on a Mac. Why not develop the same application on a Mac, in Mac OS X, in XCode, then compile it for both operating systems at once!? That’s right. That’s exactly one of the things you will see coming out of Cupertino in the next year or two. If they don’t announce it at this year’s WWDC, you can expect it at the following year’s WWDC.

NSNotification and NSNotificationCenter are two super useful classes in Cocoa. Like so many things in Cocoa, they are well thought out. But notifications can be a source of hard to track down bugs. You will find them, because often they prevent your application from doing things that should be seen visually in the interface. The question is, how quickly will you find them…?

This code (from the Hillegass book, Cocoa Programming For Mac OS X, 2nd ed.) shows an NSDocument subclass implemented and registering each instance of itself as an observer of particular notifications:

 
@implementation MyDocument

- (id)init
{
    self = [super init];
    if (self) {
		employees = [[NSMutableArray alloc] init];
		NSNotificationCenter *nc;
		nc = [NSNotificationCenter defaultCenter];
		[nc addObserver:self
			   selector:@selector(handleColorChange:)
				   name:@"JJColorChange"
				 object:nil];
    }
    return self;
}

…

And here we have another object’s method that sends the notification our document class is interested in observing and acting on:

 
...
- (IBAction)changeBackgroundColor:(id)sender
{
	NSColor *color = [sender color];
	NSData *colorAsData;
	colorAsData = [NSKeyedArchiver archivedDataWithRootObject:color];
	NSUserDefaults *defaults;
	defaults = [NSUserDefaults standardUserDefaults];
	[defaults setObject:colorAsData
				 forKey:JJTableBgColorKey];

	NSNotificationCenter *nc;
	nc = [NSNotificationCenter defaultCenter];
	[nc postNotificationName:@"JJColorChanged" object:self];
}
…

I did take out all NSLog lines to make it a bit easier to follow the code itself. There is nothing special or spectacular or unusual about any of it. This is just an example of where naming things can be a big deal. NSNotifications can also indeed be a bit like the infamous GOTO statements. Let’s face it, eventually object orientation can lead to its own brand of spaghetti code, too. As convenient and useful as they are, they are a bit fragile, since the names are important, generally hard-coded, and I haven’t yet seen or come across a nice category/protocol style way of simply declaring an object to be an observer of some set of notifications. Even with it, you still need to act explicitly on a notification, so it does require some care to make sure things are spelled right.

Did you find it yet? I hope so. With a lot more code surrounding things, it can be a bit tougher to locate, but the difference is between:

    @"JJColorChange"

and:

    @"JJColorChanged"

Only one letter. Conceptually, they’re also very close. Observing both the action (noun) and the completed action (regular past tense verb). Either one could be a valid, short announcement! Both could be part of a larger English sentence respectively, and still express the same thing.

Perhaps this is why Cocoa engineers seem to use “Did” instead. A lot easier to spot the difference between:

    @"JJColorDidChange"

and:

    @"JJColorChange"

Why? It is a subtle effect of the way the human brain actually reads and recognizes words. We do not read each letter. Our brain scans text for the general shape of whole words and phrases. That’s the developmental difference between somebody who can read, and somebody who is
still
learning
to
read
and
reads
like
this.

Thus, if you have a choice you want to choose the added word in the middle that changes the shape of the whole thing. This same effect occurs with CamelCase or the_underscores_in_ruby. But look at these examples as well:

    @"CamelCase"
    @"CamelCased"

    @"CamelCase"
    @"CamelDidCase"
    @"CamelWillCase"
    @"CamelByCase"

Notice now, how the last bunch make a lot more sense and are easier to distinguish visually. What some people initially believe is verbose and hard to read is made with some thought in mind. So now you see classic Steve Jobs/Apple thinking in the design even of Cocoa. (ok, ok, NeXT, but even then, same bunch of brilliant people and same culture)