Before I continue, it’s worth noting that due to the nature of Obj C, true private methods aren’t really possible. Never the less, we can simulate them pretty well.

Here is a very basic class which we will be adding a private method to:

#import "BasicClass.h"

@implementation BasicClass
@end

As you (hopefully) already know, Objective C separates the header (.h) files from the implementation (.m) of that class. With Objective C, you can send any message to any class so technically, you could just create a method in the implementation of a class without putting it in the header, and send a message to this object when we need to use it.

Lets add a private method called secretMethod to our class. We simply add it to the implementation file and leave it out of the header file.

#import "BasicClass.h"

@implementation BasicClass
// a secret method
- (void)secretMethod {
}
@end

From any other method in the BasicClass, we could now simply send a message to the secret message as follows:

[self secretMethod];

This works great, so I guess we are done? No! it gives a compiler warning… and nobody wants compiler warnings! It also doesn’t auto-complete within Xcode which also sucks.

Solution – Use a Class Extension

#import "BasicClass.h"

@interface BasicClass()
- (void)secretMethod;
@end

@implementation BasicClass
// a secret method
- (void)secretMethod {
}
@end

What we have essentially done here is used a private category to add the secretMethod to BasicClass, but inside the implementation file. This means things now compile without warnings AND auto-complete inside Xcode but without revealing this fact within our header file.

Using a Class Extension instead of an internal named Category e.g. @interface (Private) also gives us the advantage of being warned by the compiler if we don’t implement the secretMethod.

Hope this helps and thanks to those who commented about the Class Extension! I have updated both this blog post and my knowledge!

Cheers,
Andrew

The extension will work by showing Alfred and using the keyword ‘say’ followed by some text, for example:

say wow, extending Alfred is really easy!

Step 1 – Create the extension

Open up Alfred’s preferences to the Extension tab and click the Shell Script option on the welcome screen. This will begin the process for creating an extension.

Extension 101 - Create the new extension

Alternatively, you can click the + button in the bottom left of the Extensions preferences and select “Shell Script” on the popup menu.

Step 2 – Give your extension a name

We need to name our extension so we can recognise it later if we want to edit it. We can also set some metadata so that if we later share this extension, the credit goes to the creator.

Extension 101 - Give the extension a name and icon

I’ve called this extension ‘wordy’ and filled in my name and a URL. At this point, you can also drag an icon into the little image well to the left hand side of this panel.

Step 3 – Fill in the extension details

Firstly, we want to give the extension a Title and Description. These are the things we will see in Alfred’s results when typing the extension’s keyword. The description is shown in small text under the result, much like the file path is shown for a file result in Alfred.

Secondly, we want to give the script a keyword, in this case, ‘say’.

Finally, we want to add some bash script to perform the actual extension. The bash command we are going to use is ‘say’ and pass {query} which relates to the query you type into Alfred’s search box after typing ‘say’.

Extension 101 - Fill in the extension details

Note that for the title, we can insert a special {query} phrase which will be replaced out with the query we are typing. This gives good feedback to the users of this extension.

‘Silent’ is ticked by default which doesn’t mean “don’t make any noise”, it actually means run this command behind the scenes without showing Terminal.app – this is useful for building extensions which feel more native to the OS X user experience.

In summary, we are using the following:

      Title: say '{query}'
Description: Get your Mac to Speak 
    Keyword: say
    Command: say "{query}"

Step 4 – Save and Test

Click the save button and now show Alfred and type:

say Wow, I've created my first Alfred extension!

It’s as easy as that! The only thing now is to right [option] click on Wordy in the list and export this extension for all of your fellow Alfred users, which is exactly what I did…

Download the Wordy extension if you would like to have a play with the finished extension.

Cheers,
Andrew

When I first started programming Alfred, I very quickly realised that NSLog didn’t provide me with enough granularity to be particularly useful. I wanted to separate out log messages such that in normal use, I only see significant messages, however I still have the option to see ALL logging if I needed.

Enter APLog, a utility class offering multiple levels of configurable logging to NSLog.

Logging Levels and Simple Usage

APLog supports 5 levels of logging. Tiny, Fine, Info, Warning and Error, These methods output depending on a ‘logging’ value set in NSUserDefaults as follows:

0: Only Error is output
1: Error, Warning and Info is output
2: Error, Warning, Info and Fine is output
3: Everything is output

You can decide how these different levels suit you, I generally log things I want to see often to info and scope down from there with tiny messages being very low level things you may never want to see unless something is acting up.

// error logging
[APLog error:@"Unable to connect to network"];

// warning logging
[APLog warning:@"Clipboard cache contains unexpected info, cleaning up"];

// standard logging
[APLog info:@"Application Started"];

// fine logging
[APLog fine:@"Loaded %d rows from the database", 30]; 

// tiny logging
[APLog tiny:@"Currently processing item %d of %d", 4, 20000];

The beauty of the logging granularity is that when the logging value isn’t set in NSUserDefaults, the end user doesn’t get their console log clogged up with your logging. Subsequently, by default I have my logging level set to 1 which means I only see info, warning and fine messages during development while still logging everything which may be of use later.

Creating class methods

We want this logging to be as easy to use as possible, without the need for instantiating a class, however having a more modern Obj C interface. This can easily be accomplished using class methods.

By using a + before a method, this is making that method available without instantiating the class. In the header file, we add the info method as follows:

// in APLog.h
// info log
+(void) info:(NSString *)format,...;

The ,…; allows for open ended arguments like you see in NSLog where you can pass additional parameters in which are formatted into the log string.

// in APLog.m
// info log
+(void) info:(NSString *)format,... {
  if ([[NSUserDefaults standardUserDefaults] integerForKey:@"logging"] >= 1) {
    va_list args;
    va_start(args, format);
    NSString *str = [[NSString alloc] initWithFormat:format arguments:args];
    [AlfredLog doLog:str level:@"INFO"];
    [str release];
    va_end(args);
  }
}

First, we check NSUserDefaults to see if this level of logging is required, if so, we split out the argument levels and pass them to a method which actually does the logging. Note that we alloc the string and release it, this means that if APLog is used in a large loop, we won’t need to wait for the autorelease pool to release the memory for logging, it happens here and now.

The other levels of logging for error, warning, fine and tiny are created in the same way as above but with a different method signature.

Using a separate method for Logging

By separating the actual method for logging, it allows us to quickly change the format we want for all of the logging output. In my case, I like

[level] log message

… as this makes things easy to scan for INFO, FINE, TINY – especially considering they are all 4 fix width characters in size. This also makes ERROR and WARNING stand out when reading your log.

// do the logging
+(void) doLog:(NSString *)log level:(NSString *)level {
  NSLog(@"[%@] %@", level, log);
}

The doLog method is a categorised private method, something I will cover in a different blog post.

Easy use by prefixing in your headers

One final step is to add APLog.h to your Prefix.pch file which means you won’t need to import this in every class you want to Log in. Your Prefix.pch will look something like this:

#ifdef __OBJC__
  #import <Cocoa/Cocoa.h>
  #import "APLog.h"
#endif

Download the source

Download APLog to use in all of your projects, commercial or otherwise. This code is released under the MIT License.

Note: Don’t forget to set the ‘logging’ value in NSUserDefaults (Alfred has the index of a NSPopupMenu bound to this value in the prefs), or call [[NSUserDefaults standardUserDefaults] setInteger:3 forKey:@”logging”]; near the beginning of your code to log all levels.

I hope this is as useful to you as it is for me. Please leave me any comments or improvements below.

Cheers,
Andrew

When I reinstall OS X, I very quickly reconfigure Apache to allow for local vhosts. Apache can be a bit of a minefield for configuration and I am by no means an expert, however, these simple steps give a huge amount of benefit as you won’t need to edit apache’s configuration files every time you want to add a new vhost.

One example which I use daily is alfredapp.com which is setup locally as alfredapp.local – These two sites are exact mirrors of each other both rooted with / can be significant in web development when accessing resources and site links. I can develop and test on the local site, then when I’m happy, push the changes to my distributed repository and deploy to the live site.

Note that the following config changes may mutually exclude any other apache changes you have made… If that means nothing to you, then this will likely work fine.

Before we start, turn on Web Sharing

Open up OS X’s sharing preferences and turn on “Web Sharing”, this will start up Apache.

Step 1 – Backup the configuration files

/etc/apache2/httpd.conf
/etc/apache2/extra/httpd-vhosts.conf
/etc/apache2/users/[username].conf

Step 2 – Import the vhosts config into httpd.conf

Temporarily, we are going to make the httpd.conf writable to make some changes.

Open Terminal.app and type:

sudo chmod u+w /etc/apache2/httpd.conf

Then open the httpd.conf file and remove the # off the beginning of the following line:

#Include /private/etc/apache2/extra/httpd-vhosts.conf

While you are in here and if you haven’t done so already, it’s probably worth also uncommenting PHP too by removing the # from the following line:

#LoadModule php5_module libexec/apache2/libphp5.so

Save your changes and make your mac more secure again by making the httpd.conf file unwritable:

sudo chmod u-w /etc/apache2/httpd.conf

Step 3 – Do some magic in the vhosts config

Replace the contents of /etc/apache2/extra/httpd-vhosts.conf with the following:

UseCanonicalName Off
VirtualDocumentRoot /Users/[username]/Sites/vhosts/%0
LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon
CustomLog /var/log/apache2/access_log vcommon

Turning off UseCanonicalName makes Apache ignore the ServerName directive and instead use the domain name supplied by the browser to construct the domain (blah blah or something like that). VirtualDocumentRoot sets where Apache looks for the virtual hosts. Replace [username] with your case sensitive usename. The last two lines setup the log format adding the virtual host at the beginning using %V.

Step 4 – Setup the access for vhosts for your user

In my case, edit /etc/apache2/users/preppeller.conf and update the directory access:

<Directory "/Users/[username]/Sites/">
  Options Indexes MultiViews FollowSymLinks
  AllowOverride All
  Order allow,deny
  Allow from all
</Directory>

Naturally change [username] with your user case sensitive again. Updating this config file firstly allows apache to access this folder, but also allows for better .htaccess overrides.

Step 5 – Restart Apache

In Terminal type:

sudo apachectl restart

Step 6 – How to use… this is the easy part!

Lets say I want to setup alfredapp.local. Firstly, I create the following folder in Terminal:

mkdir ~/Sites/vhosts/alfredapp.local

This will contain the files for the website (I just grab these out of repository). Next, I update hosts file and add alfredapp.local to point to localhost. Edit /etc/hosts (you will need to sudo edit this) and add the following line:

127.0.0.1 alfredapp.local

Now visiting http://alfredapp.local in my browser and magically it works. You can just repeat step 6 for every site you want to add!

Wow, that’s easy! What next?

The next obvious step would be to configure your DNS so that *.local resolves to localhost. If you did this, then there is ZERO config to do to setup your local mirrors… simply create folders, populate them, and visit the domain in your browser! DNS configuration is a WHOLE different ballgame, which is why I’m not covering it here.

I hope that helps. Let me know if you have any comments if you have found this useful or if you know of better ways of doing this.

Cheers,
Andrew

Being a Mac developer working for myself is one of the best life decisions I have ever made. It has been extremely stressful and hard work quite a bit of the time, but it is extremely rewarding once you have some software being used by a large number of happy users, it is one of the best feelings in the world.

After over 15 years of commercial enterprise and user interface development, I’m hoping I can share some of my experiences and knowledge to help other people to get into Mac development too!

I’m hoping that over time, this blog will evolve into a really valuable resource for Mac developers of all levels

Cheers,
Andrew