Using Cocoa to resolve Unix file paths with tildes


Posted by Jaime | Posted in Coding | Posted on 30-07-2007

Quick! How do you expand a file path that has a tilde in a program? Luckily, you can use NSString to resolve the path for you. So, if you path looks like “~/Library”, you can use the stringByExpandingTildeInPath method to resolve the tilde to the full path: “/Users/johndoe/Library/”. Here is s snippet of code to show that:

NSString *myString = [[NSString alloc] initWithString:[@”~/Library” stringByExpandingTildeInPath]];

Of course don’t forget that you need to allocate memory for the string and initialize it! Now, if you need to use this function within a C++ App, don’t fret. You can add the above listed code to a C++ file and so long as you set the file to compile as a sourcecode.cpp.objc file,in the File Type drop down list in the “Info” dialog box, you should be good to go.

Click here for the Objective-C project

Creating writting made easier…


Posted by Jaime | Posted in What's New | Posted on 19-07-2007

So what is new? Something old actually. English is what I am referring to and I have found a new way to think about the written word!

My wife picked up some stuff at the local pharmacy and with that stuff there was a copy of ‘Mac Life’, a magazine dedicated to all things Macintosh for the people who use Macintosh at home. It was cool that my wife was thinking of me, and it was even cooler when I found out about a program called Scrivener.

This program is for helping people write. It is not like Microsoft Word. It is not a Word processor. Instead, it is a thought organizer, helping your piece together the normally disconnected pieces of research, sticky pads, etchings, website bookmarks, etc, etc, etc… You get the idea. Now… How useful is this product? Very! I have been using it to write my articles and it even has the capability of exporting my articles to HTML or even Microsoft Word!

I suggest that anyone who needs a tool that will help them organize their thoughts into the written word should look at this tool. At 35 dollars you really can’t go wrong!

Objective-C and C++: Friends or Foes?


Posted by Jaime | Posted in Coding | Posted on 16-07-2007

For many developers like myself, I learned a language as a means to create a program on a specific platform. Back in the early 90’s, I learned Pascal because that was the language that PC and Macintosh’s used. Later in the 90’s, I learned C++ because this was the buzzword language that BeOS, the powerful multimedia rich operating system, used. I learned other languages throughout my career, like Java and C#, but none has stood out more than Objective-C.Objective-C was used by NeXT and later by Apple when NeXT was acquired by them in 1996. Apple needed a next generation operating system badly and they needed one that was easier to develop for than Mac OS 7. Truthfully, programming on the Mac early in my career was a painful experience, littered with bugs, crashes and painful debugging sessions. Pascal as a programming language was not fun for me. C++ in MetroWerks looked really cool, but a program made with the PowerPlant library still had problems because of the nature of Mac OS 7.

When Windows 95 came out, Microsoft introduced an easier way to create programs for a platform. I got sucked into MFC, which was built in C++, and I created programs as soon as I learned how to subclass CWindow.

So how does this bring me here, to Objective-C and Mac OS X? Well, when Steve Jobs came back to Apple in 1996, he brought into the company one of the greatest accomplishments he and his team at NeXT created: an Objective-C based framework named OpenStep. Although Microsoft had MFC, which seemed so much better than programming with the Win32 API, OpenStep, later renamed Cocoa, was a radical departure from conventional object oriented programming.

MFC, which stands for Microsoft Foundation Classes, was built in C++ and allowed developers to create programs using reusable modular code and event messaging. A dialog class would respond to messages sent to it via a series of macros created by the compiler. Those who are familiar with programming with MFC and Visual Studio know about the event map macros. Objective-C and Cocoa were different in that you didn’t have to create a subclass in order to gain functionality in a particular module, or that you didn’t have to worry about sending a message to an object method that doesn’t exist. You see, for those who didn’t catch that last statement, that is probably one of the biggest distinctions between Objective-C and C++. In Objective-C, you are actually sending a message to an object. Even if the method doesn’t exist in the object, that’s ok in Objective-C. In MFC, built around C++, you are actually calling a function. In order to call that function, you must first declare it somewhere in your code. Messages aren’t really sent to objects in C++, but many frameworks create message-like mechanisms by storing an array of functions that would respond to a particular message posted to an event class. This is what MFC does when Visual Studio embeds your code with macros that insert extra event functionality.

So, I am assuming that if you have read the article to this point that you are most likely a C or C++ developer who is looking into Objective-C and trying to understand it more. If you were like me, you probably bought the Objective-C book published by Apple or downloaded the PDF( available from the Apple Developer Connection and either forced yourself to learn the language and accept it or gave up on trying to understand it altogether. If that is the case, I don’t blame you for feeling a little lost. Honestly, I felt that same way too. I learned the language and I compared it to every other language that I have learned, wondering why Apple choose such a strange language. When Cocoa became available in Java, I headed down that path since it is more like C++ and much more familiar to me than Objective-C. However, I quickly learned that programming with Java and Cocoa was not optimal for me or for my projects.

The first problem was that I really didn’t understand Objective-C. The second problem was that I constantly compared it to C++, thinking it was weird. The solution to both of these problems was understanding how Objective-C worked and not comparing it to C++. The first and most important attribute to learn about Objective-C is that programs built in this language can have dynamically loaded code. You might think, “big deal! I can do that with a DLL!”, but what you don’t realize is the mechanism that sits behind DLL usage: in order to use a DLL, you have to reference the DLL in your project and link you application to it via the compiler. When you compile your application, the compiler links the code into the binary executable, effectively copying the code into the application. Even if you are using a dynamically linking the library, there is only a reference to the DLL on the file system, however, if the DLL is different or missing, your application will not launch. In Objective-C, you don’t have to link to a library at compile time: you can wait until your program is running to load the library and call the functionality that is inside of it. If the library is different or missing, your program will still launch and execute.

This is hard for a lot of developers to understand, but this is similar to the COM interface in Windows. You can call invoke code within another file using an Interface class to understand the contents of that code. Objective-C is built around the Interface concept, which is evident when you declare a class in Objective-C: class declaration has 2 parts: the interface portion (in the header file) and the actual code declaration part(in the implementation file). In C++, you would declare a class as follows:

class MyClass



int _someVariable;


int _someOtherVariable;


MyClass(); // constructor

~MyClass(); // destructor

int CheckCPU();

int CheckHardDisk();


The CheckCPU function would be coded in a separate .cpp file as follows:

int MyClass::CheckCPU()


// do some work

return 0; // return an int


Objective-C is a little different: 2 keywords are used in the declaration of a class and the implementation of the methods: @interface and @implementation. To declare the above listed class in Objective-C, you would type the following:


@interface MyClass : NSObject {


// declare my class variables


int _someVariable;


int _someOtherVariable;



// declare my class methods






To implement the CheckCPU function, you would type the following:

#import “MyClass.h”


@implementation MyClass




// do some work

return 0; // return an int




Notice the usage of @interface in the .h file and @implementation in the .m file. Each one of the keywords is terminated by the @end keyword. It’s different, but very powerful!

At first glance, what might also seem odd is how methods are built. When you look at them, they look like typecasted C variables:


The minus(-) sign in front of the method indicates that the method is an instance method. Obj-C uses a plus sign (+) to indicate that a method is a class method. An instance method is one where you have to create a new instance of a class in order to use the method. A class method is like a static function in C++ where you don’t have to create an instance of a class in order to use the method.

Objective-C is a simple language that can be learned in a day. However, if you are a seasoned C++ developer, you might find it hard to absorb Objective-C and accept it. I have worked with Objective-C and Cocoa for quite some time now and there is a lot of good reasons to use this combo in your next Mac OS X project.

Now, I’m not saying that Objective-C is the end-all language, but it is certainly very impressive. Although there are a lot of features that C++ has that Objective-C doesn’t have, Apple certainly has made up for some of those lacking features in the frameworks they have built. For those of you like me, where you have written a ton of code in C++, there is good news. Most of that code can be reused in your Mac OS X project since applications built in Cocoa/Objective-C can call C++ code as well. Although Objective-C classes cannot inherit from a C++ class, it is good to know that you do not have to scrap your code for this awesome programming language.

Take a look at the resources listed below and the articles listed on There are sample projects listed on the website showing you how to use C/C++ with a Cocoa project and likewise, articles to further educate you on Objective-C and other topics related to the language. Once you start effectively working with the language, you will understand why it has become such a popular language in the developer community. Happy coding!

Additional Resources:

XBox 360 and the Red Ring of Death


Posted by Jaime | Posted in What's New | Posted on 09-07-2007

What a day! For the first time in a long time I had some time to kill, so what better way to do that then to play Gears Of War! I fired up my Xbox 360 and instead of giving me it’s usual chime and startup movie, I get three flashing red lights 🙁 I pick up my phone, dial dialed away and after spending 45 minutes on the phone with Microsoft, I end up having to send the console back to them, where it “may take 2 to 6 weeks” for Microsoft to send the unit back to me.

This all comes a couple of days after Microsoft made an announcement that anyone who has suffered from the red lights of death may have their warranty extended for up to 3 years. There’s more to Microsoft’s generosity then just the warranty extension, but you can just as easily look it up.

So, with more time on my hands, I turn my faithful PowerBook G4 on and type type type away in TextEdit!

This month is Mac OS X programming month and I aim to write articles specific to Objective-C/C++ programming for Carbon and Cocoa. The articles that I am going to post will focus on any Image processing related topics.

As always, if you are looking for a specific example or have comments, feel free to contact me by clicking on the More Info link on the bottom of this page!