Posts Tagged ‘cocoa’

Development Links: Redux

Monday, December 28th, 2009

This is an update to my previous post

Below is a list of my subscribed developer feeds along with a link to each home page.

At the end of the post you will also find an OPML file if you are so inclined

Enjoy!

First are the Aggregators:

All development feeds:

And if you would like to add these straight to your favorite feed reader, here is the OPML file:

google-reader-subscriptions.xml.zip

Lastly, I used this little web app to parse my opml file.

Open Source iPhone: Resources

Wednesday, November 18th, 2009

Great Resource, tagged and organized:

http://cocoaheads.byu.edu/resources/open-source

Originally suggested in this Stackoverflow question.

Quick Code – AppleScript from Cocoa

Wednesday, September 23rd, 2009

This is just something I picked up over the weekend to interface with Terminal.app via AppleScript:

NSString *s = [NSString stringWithFormat:@"tell application \"Terminal\" to do script \"cd %@\"", folderPath];
NSAppleScript *as = [[NSAppleScript alloc] initWithSource: s];

[as executeAndReturnError:nil];

The intent is pretty easy to pick up (Also, please feel free to handle the error). The question and answer can be found on StackoverFlow.

Understanding the Objective-C Runtime

Sunday, September 13th, 2009

The runtime has been a bit of a mystery to me.

To be sure, I have yet to explore some of the more dynamic aspects of Objective-C/Cocoa in my applications.

In fact, as many know, you can move along quite happily though your Cocoa/iPhone programming without directly daling with it. Others might not realize what’s “under the hood”.

If you really want to have some fun, you will need some fundamentals.

To this end, Mobile Orchard last podcast featured Rogue Amoeba’s Mike Ash who gave an overview of the runtime.

MDN also released episode 7 of the MDN Show which goes into more depth in an interview with Jonathan Dann of Sofa.

If these podcasts wet your appetite, Mike Ash has also produced a nice series of blog posts on the subject as well.

I’m sure you will find other great resources in the community as well, but this should give you a good head start.

…And The Dot Syntax Battle Rages On

Monday, August 10th, 2009

I find the manner in which programmers vehemently defend and deride coding style preferences absolutely fascinating.

I personally feel that dot syntax serves a worthwhile purpose.
In fact, I have been refactoring old code to conform to this convention.

In the end, I feel these types of debates speak to the health and growth of the Cocoa/Objective-C community.

Help out your NSDates

Friday, July 17th, 2009

If you are like me, you really appreciate those nice, neat classes that make your most tedious work a little more bearable.

Billy Gray over at zetetic has done just that with his NSDate+Helper category.

if allows you to completely forget about NSDateFormatter and easily format dates in just about any format you need. it also has some nice convenience methods built in to it.

You can find it on here on GitHub.

Private Properties

Wednesday, July 15th, 2009

Objective-C 2.0 properties are pretty useful.

They not only save you time, but also help “automate” memory management on the iPhone. They save you from screwing up your accessors.

Another benefit, is the orthogonal relationship with dot notation. Dot notation short hand makes it extremely quick to change the state of an ivar with minimal keystrokes.

There are (too) many debates about whether this syntax is “ugly”, “tacked on”, etc… This post makes a great case for using dot notation to differentiate the intent of your code.

In fact, properties used in concert with dot notation are so convenient that there is little excuse to ever access instance variables directly. Another bonus is the “automatic” memory management. Well as automatic as you can expect in a reference counting situation.

You may be opposed to creating a property for an ivar you want to be private since doing so allows unrestricted access. This creates an encapsulation problem, but one that is easily circumvented with another Cocoa trick: anonymous categories.

By declaring your private property within an anonymous category in the implementation file, you effectively hide it from other classes.

It is still true, that you can peek in the implementation and find these hidden properties. But it will be readily apparent to you, or anyone else, that they should be left alone since they reside within the implementation file.

I use this technique to clean up my interface files (along with placing private methods in the category as well). This gives your classes a nice, neat, and more importantly, easy-to-understand interface.

Another issue is when you need to react to state changes of an ivar. This can be mitigated using KVO. By observing properties, you can react easily such changes.

Do you use dot notation or do stick with brackets? Do you create properties for all of your ivars or do you prefer to handle their memory management in the implementation?