In each of my posts on setting up a local development environment on OS X, it's mentioned that you need to add your website's domain, even though it's local, in your /etc/hosts file. My preferred way to edit the hosts file on OS X is using Gas Mask. If you wanted to create the local virtual host projectx.dev, you would add the line 127.0.0.1 projectx.dev in /etc/hosts or with Gas Mask, and then use that same value in either ServerName in Apache or server_name in Nginx. This can be tedious for adding new sites. Luckily there's a way to set this up once and then never have to edit your hosts file again for adding new local virtual hosts.

In my previous post, I walked through how to set up a local environment using Nginx running on port 8080 so as to avoid running anything as root or with sudo. Something that I've found incredibly annoying is when I forget to specify the port I get an error in my browser, or Chrome might even suggest something based on a search term. It's fairly easy though to configure Apache to route everything to another port.

We came across an issue with a site recently, where the name of the custom module file was the same as the name of the theme. So, for example, if the theme name was Bork, the module name was bork.module. This can cause a variety of problems since the two share name space. Problems can include blocks disappearing (both from your site, and from the /admin/build/blocks menu), printing $content returns only 'array,' and more.

Time for part two of my series on iPhone development basics. Last time, I gave some tips on writing settings to a binary file using Apple's Foundation Library. This time I'll show you how to retrieve those settings -- either from a cached version of the property list or from the filesystem itself. As with the first article, let's dive in head first with some code.

First of all, you'll want to add a static NSDictionary member to your settings data controller class for storing the cached settings.

In your .h file:

In your .m file:

Here's the loadSettings function. As you can see, I've implemented it as a class method -- there's really no reason to treat your settings data controller as anything other than a singleton with some class methods. Some argue against using singletons in Objective C. In most cases, I could be persuaded to agree; however, app-wide settings don't really make any sense implemented as anything except as global variables, and singletons are essentially the OOP equivalent of globals. I'd love if someone wanted to discuss this in a comment thread, however.

Over the past month or two, I've been fortunate enough to be able to put some work into an iPhone framework that interfaces with Drupal sites. In doing so, I've learned a number of things about the various Cocoa frameworks that might be useful to others. As such, I'm going to run a short series of blog posts documenting some of these discoveries.

First up is the subject of data storage -- particularly the storage of simple settings. There are several ways to accomplish this in the Cocoa touch framework. If your settings are fairly complicated and you don't expect your user to alter them very frequently, it's recommended that you hook into the Settings application (the way that Mail and Safari do, for example). Of course, this is cumbersome by virtue of the fact that you have to exit your app and start up Settings in order to change anything. If your user is tweaking settings frequently, this could spell a UI disaster.

Another option is simply to write settings to a file somewhere in your app's sandbox. For our Drupal/iPhone framework, I've adopted this approach. For most of our sites, I don't expect users to be dealing with very many settings -- username and password, of course, and perhaps a few other options tied into the Content Profile module. Therefore, while we can't take advantage of Apple's powerful Settings framework, data storage and retrieval is still very manageable.

CCK's standard "Display Fields" settings are good for configuring per-content type field visibility and can save a lot of custom coding time. If a field is shared over a dozen content types, however, a change to one has to be made to the others, and that's a lot of clicks.

The Content Type Selector module adds a little dropdown to the right of the tabs on the CCK settings pages. So you change the field settings on one content type, pick the next type in the dropdown, change it there, etc. It's still a lot of clicking but it's a few seconds trimmed with each page and feels more seamless.

I've started using and loving the Popups API module. It allows other modules to create lightbox-type ajax popups of other pages and forms. Out of the box, it includes the option to convert several admin UI pieces into popups, like the Configure Block links, Taxonomy Add/List/Edit links, etc. Saving a few seconds here and there adds up to a lot of time!

(Note: Make sure to set the Content Selector in your theme settings (/admin/build/themes/settings/themename). The default is strange, but in most themes div#content should do it.)