In this entry I am going to do something a little different. Instead of showing some wicked code, I am going to reformat one of Apple’s default templates.
Apple writes some amazing code. Unfortunately a lot of their templates demonstrate simply terrible coding practices. What is worse, people take these templates and assume that they are the proper practice for coding in Objective-C and propagate that poor code into their own projects.
The first example I am going to tackle is the AppDelegate class that is auto generated in the Core Data template. This is not the Core Data Document template but the standard application template.
For most simple applications using and managing resources is handled seamlessly and you don’t ever have to intervene programatically. There are times, however, as your applications begin to mature that you need to access resources directly. Doing so is pretty straightforward, but I thought I would document it here–if for no other reason than to have it written down somewhere for the next time I need it. I hope it might be helpful to you too.
In this continuing series on my own transition from a Mac application hacker to microISV (Independent Software Vendor), I am going to demonstrate how to create your own file format for your application. You’ve probably seen these types of files in popular applications such as iMovie HD (06′) or GarageBand or even xcode in which the actual files used are, behind the scenes, folders that the operating system treats as regular files. These folders/files have a special bit set on them that tell OS X how to deal with them. The goal of this post is to demonstrate how you can do the following:
- Create your own file format with your own file extension
- Register your file format with the operating system
- Provide application loading of your file that’s been double clicked in the Finder
- Write data and preferences back out to your application file
- Add resources such as media files to your application file
May 20, 2008
The T-Shirts for delivery at WWDC have been ordered. If there is enough interest I will setup a way to purchase CIMGF T-shirts (non-WWDC) directly from the site. Please contact me at marcus at cimgf dot com if this is of interest to you.
Last year I wore t-shirts for Zarra Studios and got quite a few compliments. These days I am becoming more known for this blog than anything else. Therefore, I am doing different t-shirts this year to celebrate this blog. As a reader of this blog you have an opportunity to purchase one of these shirts. They will only be run for WWDC so they are limited edition! :)
While the design is not complete yet, here is the first public draft of the T-Shirts:
Currently, the plan is to take them with me to WWDC and hand them out to those who have purchased one right after the keynote on Monday. If you are not going to WWDC but would still like to order a T-Shirt, that is also doable but naturally shipping costs will be involved.
The price per shirt will be $20.00 US. If you are interested in purchasing one or more, please contact me at marcus at cimgf dot com and I will work out the details. Right now I am processing orders manually but if they get too crazy then I may set up an actual shopping cart. Quantities are limited so act now! ;-)
Lastly, to follow Justin’s great idea. I am interested in trading T-shirts with other WWDC attendees. If you have a NEW shirt that you would like to trade for a CIMGF shirt, please contact me at marcus at cimgf dot com to plan a swap.
All Orders must be received and paid for by the 19th of May, 2008. Any orders received after that date can be shipped but cannot be delivered to WWDC.
It is not my intention to make a profit on these t-shirts. I am offering them to readers at the approximate production cost. It is not my intent to mass produce these t-shirts with the goal of making a profit. If the production run comes close to or exceeds 500,000 t-shirts (wouldn’t that be amazing!) then the artwork on the back of the t-shirts may change due to restrictions in the license agreement.
I often find and therefore come to expect common problems in Cocoa to be easily solvable, however, there are times, like this, where I am a bit disappointed that the problem can be so difficult. All I need to do is copy a file. This is a simple task right? All you need is NSFileManager and a call to – (BOOL)copyPath:(NSString *)source toPath:(NSString *)destination handler:(id)handler and you’re good to go. Not so fast, city slicker. This one is going to take a bit more effort cause you want one of them fancy new-fangled progress indicators to show how much of the file has been copied. Well, if you want Cocoa to help you, you’re out of luck cause NSFileManager won’t do that for you, but with a little bit of effort you can get it to work with some… gulp… C APIs.