Illustrator iOS Template (including iPad 3)

Free iOS Illustrator Template

Download my free Illustrator iOS template.

Since moving into iOS development, I try to do as much of my artwork in vector so that it’s easy to scale, usually moving in to Photoshop to add effects and pretty it up.

To speed up my workflow and to remind me not to forget any of the numerous icons you’re supposed to provide for apps, I’ve created an Illustrator template to help get me started, which works in conjunction with a Photoshop template that I’m still developing (but, thanks to Jon Hicks, now has very precise Vector masks with the correct corner radii).

Using the Illustrator iOS Template

All of the artboards in this illustrator iOS template have been sized and named according to Apple’s interface guidelines should you decide to go direct from Illustrator to Xcode (although Bjango’s Marc Edwards doesn’t recommend it).

However, by default, Illustrator exports the files as “documentName_artboardName.png”, which would usually mean having to tediously remove the “documentName_” bit from each of the exported files but, thankfully, Matthew Ericson has created a super useful script that solves this particular problem.

This script overrides the naming default and allows you to save everything out using just the artboard name, which means everything comes out ready to drop in to Xcode.

I would also recommend switching on Pixel Preview (Cmd + Alt + y on Mac) so that you can line up your vector shapes to the nearest pixel. This will make it easier to get pixel perfect pasting when moving between Illustrator and Photoshop.

See this excellent article, again by Marc Edwards of Bjango for more about this.

License

I’m releasing this illustrator iOS template as Freeware, so feel free to download it and use it however you like. You can use it for any of your projects without restriction and you don’t have to give me credit (though it’s always appreciated).

Setting Up Virtual Hosts with MAMP on Mac OS X

I’ve been using the regular MAMP for a long time without problems but recently I wanted to start experimenting with subdomains on my local development server using Virtual Hosts.

I knew that MAMP Pro supported Virtual Hosts and so I fired up the trial and indeed they do make it very easy for you to add new host names: simply add a server name and a directory for your files and you’re good to go. If ease and convenience is important to you, then just get the Pro version and be done with it.

However, I like to know how things work and so, after a bit of poking around in my /etc/hosts and the various httpd.conf files in both the /Applications/MAMP and /Applications/MAMP Pro directories, I found that it was actually pretty straightforward to add new virtual hosts manually.

Adding Your New Domains to the Hosts File

Throughout this post I’ll be using the example domain name line-in.local.

  1. Open up a terminal window and make a backup of your hosts file by typing
    sudo cp /etc/hosts /etc/hosts-backup

    (as this is a system file, you’ll probably need to enter your password)

  2. Edit the hosts file in Nano by typing the following:
    sudo nano /etc/hosts

    Near the start of the file, you’ll see the line: 127.0.0.1 localhost. You can simply add your new domain to this line so that it reads:

    127.0.0.1 localhost line-in.local

    I also added each of my domains to the IPv6 version (which is declared a few lines later), so it looks like this:

    fe80::1%lo0 localhost line-in.local

    This is a good idea because there are reports that OS X Lion’s DNS cache is a bit rubbish. I found that it was taking up to 5 seconds to resolve my new domain names. Adding the domains to the one line seemed to help fix this problem).

  3. Ctrl + x and then y will write out your changes

Preparing the Virtual Hosts in Your httpd.conf File

  1. Go to your MAMP application folder and find the configuration files for Apache. It should be in /Applications/MAMP/conf/apache/ For my version of MAMP, they use includes to separate out some aspects of the configuration files including virtual hosts. This seems like a nice way of keeping things organised and allows you to easily play around with virtual hosts without messing up your main httpd.conf file so that’s what we’re going to do here.
  2. Open up httpd.conf and scroll all the way down to the bottom. You’re looking for the line:
    Include /Applications/MAMP/conf/apache/extra/httpd-vhosts.conf

    It might have a # symbol at the start, meaning that it’s commented out. Delete that symbol. If it’s not there at all, simply add the line.

  3. Save and exit out and go back into the configuration folder (/Applications/MAMP/conf/apache/). If you have a subfolder called extra, open that up. If not, create it.
  4. Open up httpd-vhosts.conf. If it doesn’t exist, create it. If you didn’t create it yourself, you might see some example dummy hosts in there. You can ignore these or delete them.
  5. If the following line doesn’t exist in your file, create it:
    NameVirtualHost *:80
  6. The first thing we have to do is to create the default configuration. This is what Apache will use if it can’t find a server that is pointing to your localhost IP address but hasn’t been declared as a unique virtual host. Copy and paste this:
    <VirtualHost *:80>
    DocumentRoot "/Path/To/Your/Default/Document/Root“
    </VirtualHost>

    Replace /Path/To/Your/Default/Document/Root to the path where you store your web files (default in MAMP is /Applications/MAMP/htdocs, but you may have changed this).

Adding New Web Document Roots

With virtual hosts, you can use different folders for different document roots. For example, I have a web design clients folder and I hold all of my web files for that client in an individual webroot folder within that design folder. This makes archiving and organisation easy (though if you do move the folder, you’ll need to remember to update the Virtual Hosts file).

  1. Create a new folder for your virtual host somewhere on your system. Make a note of its location. You may also want to add a quick index.html file to that folder which will tell you if it’s working or not.
  2. Copy out the following into the httpd-vhosts.conf file, underneath the first VirtualHost declaration:
    <VirtualHost *:80>
    DocumentRoot "/Path/To/New/Document/Root"
    ServerName line-in.local
    <Directory "/Path/To/New/Document/Root">
        Options All
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
    </VirtualHost>

    Important things to note:

    1. The ServerName should be what you set your /etc/hosts declaration to (in this case, line-in.local).
    2. Virtual hosts can contain most Apache directives. For directory-specific directives, create a new declaration. You generally want to copy your set up from your main Apache directory configuration (see httpd.conf) so that things work consistently across all of your hosts. One important declaration is AllowOverride All. This allows you to use .htaccess files in your new directory.
  3. Save this file out and restart Apache. If everything is working, you should be able to open your browser and go to your new host (e.g. http://line-in.local) and it should open up the index.html file you created.

Congratulations, you now have a working virtual hosts set up!

You can add as many of the declarations as you’d like, just remember to update /etc/hosts for each new domain you want to add.

Troubleshooting

Everything went smoothly following the above for me but your mileage may vary, especially if you are using older versions of MAMP or have heavily configured your httpd.conf file.

If Apache doesn’t start at all, check your httpd-vhosts.conf file for errors (make sure the closing quotes match, that you’ve closed all open directive tags and that you’ve spelled the directives correctly). If you just can’t get it to work, you can always open up your httpd.conf file and comment out (with a #) or delete this line:

Include /Applications/MAMP/conf/apache/extra/httpd-vhosts.conf

This will effectively ‘turn off’ your Virtual Hosts configuration and get you back to a working development server.

iOS Application Development, Part 1

Xcode splash screen

Last week I gave you my initial impressions on Objective-C and begun the epic Stanford course on iOS application development. I have now completed the first assignment and am half way through the videos and I would like you to accompany me as I continue my journey to Make Epic Shit.

But first, the “Hello, World” application. It’s an application that’s on the right path—it’s just missing the Epic.

Continue reading

Wrap Form Elements To Maintain Vertical Rhythm

It’s easy to get obsessive about typography and vertical rhythm, especially when using my plugin that shows you exactly how close to the lines you are.

One of the biggest challenges in maintaining a solid vertical rhythm is form elements. I have tried too many different ways to get them to fit into the flow of text–including countless combinations of padding, margins, borders, line-heights and font-sizes–but unfortunately they simply do not behave themselves consistently cross-browser.

Which is why I had a bit of a double facepalm moment when I realised exactly how easy it could be. Simply wrap them in a containing element and give that element a minimum height:

<div class="form-container">
	<label for="input-element">My Label</label>
	<input type="text" id='input-element'>
</div>

Usually I just go for double the line height:

.form-container {
	min-height: 3em; /* Assuming line-height of 1.5 */
}

/* If you're using LESS/SASS, it's even easier */
.form-container {
	min-height: @lineHeight * 2;
}

Obviously, if you change the font-size of the containing element, this will break your vertical rhythm (you’ll have to re-calculate the min-height based on the new line-height, itself based on the new font-size).

But if you’re using the same font-size, then this is all you need to make sure that everything sits vertically where it should.

If you want more space underneath or above your form container, you could simply use another line-height unit:

.form-container {
	min-height: @lineHeight * 2;
	margin: 0.75em 0;  /* Assume 1.5 line height, divided by 2 */
}

Everything that comes after it will sit on the same line as everything that comes before it.

Getting More Control from the WordPress Settings API

A picture of tabbed settings using the WordPress Settings API

No Sketchbook Sunday this week as I’ve been busy coding some new tools to help speed up my WordPress development.

I’ve been developing a class-based Base Plugin environment that allows me to quickly create new settings pages (on both themes and plugins) and focus on form creating, validation and program logic (I can’t wait until PHP5.3 is more widespread. So many times I could have used Late Static Bindings and proper Namespacing…)

I’ve been using the Settings API but I also wanted to be able to switch between Tabs, Meta boxes and vanilla HTML simply by changing one class variable.

In order for this to work, I needed more control over how the Settings are displayed. The default WordPress function is the do_settings_sections(); but this simply dumps out all of the sections in one go—no good if you’re trying to separate out individual sections on one page in order to use JavaScript-based tabs or individual Meta Boxes.

Digging through the core, I had a look over the Settings API functions. The do_settings_sections(); is actually pretty straightforward. It basically just loops through a huge array of all of the pre-defined section areas. So I adapted it and came up with this single version:

if ( !function_exists('line_in_do_settings_section') ) {
	function line_in_do_settings_section($page, $section) {
		global $wp_settings_sections, $wp_settings_fields;

		if ( !isset($wp_settings_sections) || !isset($wp_settings_sections[$page]) )
			return;

		echo "<h3>{$wp_settings_sections[$page][$section]['title']}</h3>\n";
		call_user_func($wp_settings_sections[$page][$section]['callback'], $wp_settings_sections[$page][$section]);
		if ( !isset($wp_settings_fields) ||
			!isset($wp_settings_fields[$page]) ||
			!isset($wp_settings_fields[$page][$wp_settings_sections[$page][$section]['id']]) )
		return;
		echo '<table class="form-table">';
		do_settings_fields($page, $wp_settings_sections[$page][$section]['id']);
		echo '</table>';
	}
}

Now all I need to do is pass the $page and $section that I want to display, and it’ll only display that section. With this level of control, it’s trivial to set up a looping system (for example with tabs):

<?php
// A bunch of pre-defined setting section ids
$tabs = array(
	'default-settings',
	'advanced-settings'
);

<div class='wrap line-in-plugin'>
	<?php screen_icon( 'plugin' ); ?>
	<h2 class='lif-title'>
		<span><?php _e( 'My Example Plugin', $this->lang ); ?></span>
		<?php
		$i = 1;
		foreach ( $tabs as $tab ) { ?>
			<a class="nav-tab hidden" href='#tab-<?php echo $i; ?>'><?php _e( 'Tab ' . $i, $this->lang ); ?></a>
		<?php
		$i++;
		} ?>
	</h2>
	<form action="options.php" method="post">
	<?php $this->settings->get_settings_fields('my-settings-page'); ?>

		<?php
		$i = 1;
		foreach ( $tabs as $tab ) { ?>
			<div id='tab-<?php echo $i; ?>' class='lif-tab'>
				<?php line_in_do_settings_section('my-settings-page', $tab); ?>
			</div>
		<?php
		$i++;
		} ?>	

	 <p class='submit'>
	 	<?php submit_button(); ?>
	 </p>

	</form>
</div>

Instant tabbed settings pages!

A picture of tabbed settings using the WordPress Settings API