iOS/Web Developer's Life in Beta

It’s probably not the kind of Iron Man competition that you’re used to hearing about. This one is a challenge to blog at least once per week, every week, about Perl and Perl-related technologies.

My buddy Matt Trout, co-founder of Shadowcat Systems, creator of DBIx::Class, a core contributor to Catalyst, as well as all sorts of other great Perl goodies, is starting a blogging contest to try to get the word out that Perl is still alive and well, and perhaps try and overthrow the public perception that Perl is use old-school “use CGI;”. And he’s also a hilarious public speaker too.

I’m going to be taking part from this blog. I love Perl, and have been writing software in it for nearly 15 years. The problem with a lot of people like myself is that we already know that Perl is great, and is used throughout the world to solve mission-critical problems on a daily basis. But we tend to forget that unlike Java, .Net, and other crappy newcomers, Perl doesn’t have a marketing department trying to convince people that their language doesn’t suck. Anyone who’s had to deal with Java CLASSPATH problems, .Net’s problems like – well, that it’s .Net, for starters – knows that just because there’s industry buzz about something doesn’t mean it’s lacking in the “SUCK” department.

Please check out http://www.enlightenedperl.org/ironman.html and join in. Or alternately you can email ironman@shadowcat.co.uk if you want to contribute. At the very least, I suggest you follow the Enlightened Perl Iron Man blog. If you’re following this one, at the very least you’ll be following a small part of it.

I keep finding amazingly good blog posts or links of interest that I end up bookmarking for my own uses, but I end up having to tell people on a case-by-case basis why one article is good for one reason or another. I end up bookmarking on my Delicious account and sharing blog articles I like via my Google Reader account, but it’s becoming increasingly obvious that this isn’t enough.

So instead, I’m going to write a weekly (hopefully) article on links I’ve come across and why they’re cool. So, without further ado, here’s the first installment of Links Of Interest.

Object-Oriented CSS

I came across a link from Ajaxian, which talks about Nicole Sullivan’s work on Object Oriented CSS. Here’s an excerpt:

How do you scale CSS for millions of visitors or thousands of pages? Nicole first presented Object Oriented CSS at Web Directions North in Denver. Since then, the response has been overwhelming. OOCSS allows you to write fast, maintainable, standards-based front end code. It adds much needed predictability to CSS so that even beginners can participate in writing beautiful websites.

The idea is intriguing. I’m curious to see how it can be applied to mobile iPhone development. The important thing though is that most people get web development wrong. Either JavaScript, CSS, semantic markup, or all of the above. I even know people who still do their layout with tables!

Typically when you consistently find a problem with development across a series of projects, the problem is most likely you, or at least the way you’re doing things. Take a step back and re-think the problem, and re-educate yourself on best practices.

There have been articles across a number of respectible web development blogs talking about writing reusable code, and defining client-side logic in classes (even when you think you might never re-use that application logic again). But I’ve never seen that principle applied to CSS. I definitely recommend reading more on this topic.

Juicer: JavaScript and CSS Packaging

YUICompressor, and its friends, are great methods for compressing CSS and Javascript, but my biggest wins you can possibly make in optimizing the size of your script or style content is simply to not include the things you don’t need. This is why I perked up when I saw a post on Ajaxian on a project called Juicer, which is a tool to package JavaScript and CSS while applying best practices as it does its work.

When developers start a project, they’ll go to the site for their tool of choice. For me, I first go to MooTools and download a kitchen-sink build of MooTools-core and -more, and as I develop I’ll use more and more features of it.

However, when it comes time to ship, I need to scale back what my MooTools build includes since probably 75% of it won’t be needed by my project. But the question is, which 75%? This is mostly a trial-and-error process which is made all the more difficult to deal with because I’m used to Perl and CPAN resolving dependancies almost flawlessly.

So my hope is that Juicer can help me solve some of these problems, and I can use it at build-time so I not only can resolve dependancies and build the proper Perl modules to deploy my webapps, but that it can trim down my JavaScript libraries to include only the features I need.

QFocuser

This seems like quite a simple script, but it solves an important problem. In a nutshell, it creates a way of handling focus and blur events for fields and other sorts of widgets so you can make your web applications accessible. Ajaxian gives a little summary of QFocuser, but I had thought that this could be quite powerful for reasons other than accessibility.

At my day job, we style our text fields specially when they are disabled, selected, or just regular plain fields. Most of our legacy code manages this manually, by setting attributes and CSS properties independantly, and many places gets it wrong. I’ve been implementing some changes in our framework to eliminate this problem, and largely involved implementing much of what QFocuser does, but in a more specific way.

I’m curious to see how I can apply it here, and use it as a generic mechanism to make our UI behave more consistently.

Internet Marketer’s Checklist

Over at SEOmoz there’s this great post, titled “The Internet Marketer’s Checklist For Determining If a Business Idea is Worth Pursuing“. The title is a mouthful, but it’s a great discussion of the things that will make an online application succeed or fail. As programmers and technical types, we often lose site of the actual goal of doing what we do: building stuff that people will use.

I’m a terrible example of your average user. I use the keyboard primarily for navigation, even on my Mac (Quicksilver FTW!), I use the command-line almost exclusively. Most users wouldn’t be caught dead using their computers that way. This extends to other areas as well. Applications that would appeal to us techies won’t appeal to the nontechnical, teen-with-flashy-website crowd.

I’m fortunate that my wife not only is very technically savvy, but still is in touch with her non-technical roots, and has a psychology degree and her lab experience to know how people think. I use her as my litmus test to see if an idea is worth pursuing. But beyond knowing if someone will be able to relate to a website, this checklist looks like a great way seeing end-to-end if a site would be understood, would be marketable, and if it would actually stand a chance of being used by the general public.

I’ve managed to avoid C and C++ programming for most of my career of 15 years. I’ve dabbled, and then I’ve run back to my favourite languages. Besides, as a web developer there hasn’t often been a need for me to delve that deeply into the machine.

Now that I’m developing iPhone applications, that’s all changing. I’m using PhoneGap to develop my apps, but some of it was buggy, and others just didn’t do what I needed to do. I’m integrating the AdMob and Medialets APIs into my application, which means Objective-C programming. After picking my way around, and continuing on the work my friend Scott McWhirter developed, I think I’ve come up with something that not only works well, but helped me to learn and love Objective-C.

Why I started playing in ObjC

Scott had fixed a long-standing bug in PhoneGap which happened when multiple PhoneGap commands were made within the same event loop in JavaScript. After he figured out how it worked, and how to fix it, that showed me just how PhoneGap works. To be honest, this is the first time I really understood how it does what it does.

As I integrated Medialets in, I discovered that it has the capabillity of sending custom tracking events so developers of iPhone applications can not only analyze when and where people are using their application, but what they’re doing while they’re using it. I wanted to use this to see how effective parts of my first application are, so I can learn what to change in the future.

Sadly, since most of my application is written in HTML/JavaScript, there was no direct way I could call out to the Medialets ObjC API directly from my JavaScript events. I couldn’t do copy/paste code any longer, I needed to extend PhoneGap to add my own commands to it.

Why I Refactored PhoneGap

The way PhoneGap commands worked in the past is it would set “document.location” to an address that looks like “gap:command_name”. If any arguments were supplied, they’d be added on the end separated by colons. But since that is a relative path, it would be added on to the end of your application’s filename. So, since HTML files are loaded locally from within the app’s directory on the iPhone, a GAP command would look like:

file:///…MyApp.app/www/gap:command_name

So figuring out if a command is being called involved a lot of hackery around stripping out the gap: portion of the URL. Since this was difficult to deal with, and meant there was a lot of re-used code, not to mention commands couldn’t contain colons, or any characters that could potentially be URL encoded, I refactored GAP commands to be their own absolute paths, like so:

gap://command_name/arg1/arg2/arg3…

When this location is set, a callback within the Objective-C code (called shouldStartLoadWithRequest) checks the address and determines if the request is a real request and should be allowed to continue, or if it should process the command as a GAP command and disallow the link from being loaded.

So these URLs are never loaded outside of the phone. Once PhoneGap sees a gap:// URL, it parses it as a command request and never attempts to fetch the resource. The benefit of this is that the iPhone’s NSURLRequest and URL objects automatically decode the URI parts and escapes any %20-style encodings. It also is a lot simpler to find the name of the command to run, since all it has to do is fetch the URL’s hostname property.

I’ve pushed this to my own fork of PhoneGap up on GitHub if you want to try it yourself. Hopefully these changes get pulled down into the main branch of PhoneGap.

Next Steps

Realizing how easy it is to write Objective-C, I’m planning additional changes in the future. First, I would like to refactor the gap.js JavaScript code to use Joose, a light-weight meta-object class framework. This way, instead of calling out to a separate class like Device.exec to call out to PhoneGap, you could inherit from PhoneGap and create a class-based application that extends it instead.

I would also like to make the commands within PhoneGap pluggable, so one doesn’t have to extend one giant if/else block. Instead, it would be nice to have a pluggable framework where you can add commands by inheriting separate classes. I don’t know enough to do this yet, so unless someone else does something similar, it will have to wait.

Certainly I’ve learned quite a bit, and had a great time doing it! I’m really enjoying PhoneGap and iPhone development, and I’m looking forward to adding more as time goes on.