I’m diving in to PhoneGap and ObjC, finally

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:


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:


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.

Reblog this post [with Zemanta]

Anti-Valentines day, 2009

Day 045/366 - February 14thImage by Amanda M Hatfield via Flickr

My wife and I don’t celebrate Valentines Day. This is for several reasons, but the biggest reason is that we don’t like being made to buy overpriced flowers and chocolates, pay for overpriced restaurants, and buy overpriced cards that convey generic and meaningless messages of love to someone I already love and have far more profound ways of expressing it than what Hallmark has cooked up. So basically, we’re both jaded and cheap.

A couple days before Valentines, Dee wasn’t feeling well (more so than usual) so on my way home I made two quick stops. I went to a stationary store and bought a couple of coloured “Sharpie” permanent markers, and as an afterthought grabbed some $5 tulips from a street vendor. She appreciated the flowers, but when she saw the markers she squeed in excitement. (Note, Squee is an onamotapia…it is exactly as it sounds).

She had mentioned in passing a week prior to this that her current marker was getting dry, and writting labels on burnable DVDs was getting difficult. So the thoughtfulness of my gift, regardless of cost, was far more valuable and meaningful to her than any number of generic flowers can possibly convey.

And basically that’s the core of why I despise Valentines. If you need an annual holiday to express your love and affection for someone, then your relationship is in serious trouble. However, if you find little ways over the course of the year to make a difference, then you’ll realize that V-Day is nothing more than a cash grab for flourists and card companies alike.

So how did we celebrate the day I keep ragging on? We got our single friends together and took them to the pub for drinks and food, and then came back to our place afterward to watch some great stand-up comedy. It keeps them from feeling bad and buying into the hype, and who knows…maybe we can be the wing-man then need to get them hooked up with another hapless single person!

Reblog this post [with Zemanta]

Second impressions with PhoneGap


I’m now a registered iPhone App Developer! After the usual waiting, emailing, phoning, and faxing that I won’t bore you with because blogs all over the world are full of people ranting about Apple’s registration process, I now have my developer key. (Personally, I don’t see what people are complaining about…it wasn’t all that painful.)

So now that I’ve written two iPhone applications, the first thing I wanted to do was load them on the phone and see how they actually behaved on real hardware. The results were, lets just say, less than thrilling. While they ran and did everything I would have expected of them, there are strange inconsistencies between the rendering of WebKit on the phone vs the desktop.

What went wrong

First off, let me state for the record that these are development versions of my apps, and I hadn’t figured on them working well right away. Lets face it, as developers we spend most of our lives working with broken crap, and try our best to make it less broken. That being said, I’m still an optimist and I had hoped.

First, what worked:

  1. The app’s icon, start-up screen, and general layout all behaved. Everything was where it was supposed to be.
  2. The app started up fairly fast. The only other app I’ve used that’s based on PhoneGap is the Translink public transit app (since I take a combination of a bus and train to get to work). It takes far longer than most apps to start, so I had expected the worse for my app.
  3. Clicking on buttons and other UI elements in my first app worked just fine. My second app, which uses more complicated gestures (pinch, rotate, etc) also worked without a hitch.
  4. My JavaScript ran quite well, with only a few minor exceptions.

Now on to what didn’t work. Keep in mind, the list above is a lot longer than I’d expected, so the oddities below are tolerable, for the time being.

  1. My CSS transitions are behaving very oddly. Instead of smoothly fading from 0% to 100% opacity, they jump between 0% and 100% immediately, back down to 0%, and then fade gracefully back up to 100%.
  2. The toolbar of my app, which is implemented as HTML/CSS, flickers whenever I click on buttons anywhere on the screen. This is especially weird since the events for those buttons, located in the center of the screen, don’t touch or interact with the HTML or CSS attributes of the toolbar in any way.
  3. For one of my apps I use an element with CSS sprites. None of these seem to work. When I change CSS classes, instead of changing the background position of the sprite image, it stays in the same skewed position.

Next steps

From here, I think I need to either use CSS classes, or set style properties from JavaScript exclusively. Mixing and matching might be causing problems. What do you think?

However, as I finish this, my wife and my in-laws want to go to the pub. So screw this hacking on frustrating code from home. I’m going for a pint and some appies!

Before I go though, I’m going to appeal to the iPhone and PhoneGap developer community at large: Have any of you encountered these problems before? Do you have any suggestions on how to make things work better?

Reblog this post [with Zemanta]

Managing sites with Git and intelligent post-update hooks

I’ve recently begun drinking the koolaid of Git, and damn it’s tasty! The things I can do with git that I couldn’t have done before (or would have been difficult to do) makes me excited about it. In fact, the one feature that I thought was a drawback — the no-one-true-server nature of it — is actually its strongest selling point.

See, the way I’ve taken to doing my development now is I create two “remote” repositories. First is “origin” which points to a repository managed by Gitosis. Second is a “live” repository that points at a working directory on my production server. That working directory is where my live site actually runs in.

On its own this is handy. As I develop new features, I push my changes to origin. Once my code is ready, and after I run “make test” to verify my site passes all its unit tests, I push to my live repo. At this point I ssh to the server, restart my server processes, and in theory all should be well.

The need for automation

I discovered quickly that in practice this was fraught with error. After a fairly large refactor, I found that the code that worked perfectly well on my development laptop fell over on production. Old or missing libraries, dependancy problems, ownership permissions on files, you name it. My site was down for 2 hours while I tried to resolve these issues. I added more unit tests to my code, but still this wouldn’t have caught these problems.

At this point I decided that a more automated approach was needed. I used a friend’s post-update hook as a template, which simply merged in changes and restarted nginx following a push to live. To this I added a long one-liner, and added the relevant commands to /etc/sudoers with the “nopasswd” option. In the end, the function looks like this:

bounce_fcgi() {
  echo $PWD >&2
  [ -f Makefile ] && make clean >&2
  perl Makefile.PL >&2 && make test >&2 &&
    sudo /etc/init.d/nginx test 2&>/dev/null &&
    sudo /etc/init.d/nginx reload &&
    sudo /etc/init.d/webapp restart >&2

Essentially, after my new changes are merged in, it:

  1. Creates and runs my Makefile
  2. Runs all my unit tests
  3. Tests my new nginx server configuration
  4. Reloads my new nginx configuration
  5. Restarts my FastCGI web application

If any of those steps fails, the full process halts. All the >&2 arguments ensure that the output of these commands are echoed to my local console from the remote server. So when I type “git push live”, all the test output is displayed to me inline. If an error occurs, I can immediately fix it in my local environment and push out a new change without having to log in to my remote server once.

My web application is written in Catalyst, and I use Test::WWW::Mechanize::Catalyst extensively, so I not only unit test my back-end classes, but I test the URLs users actually interact with. It even goes so far as creating and destroying test accounts within my database, so every feature of the website is tested, right down to validating the contents of my robots.txt and sitemap.xml files.

Next Steps

There are still some holes that need to be filled here.

  • If running my tests fail for some reason, I would like to roll-back the remote working directory to the previous version and restart my services, that way the site continues to function under a known-good state.
  • I would like to use WWW::Google::SiteMap::Ping to notify Google, and perhaps other search engines that support XML Sitemaps, that the contents of my site have changed and a reindexing is needed.
  • My site is localized, so I would like to regenerate my PO translation files, and if any strings have changed or are out of date, automatically send an email to my translators with the new POT template file attached.
  • Run my HTML through a spelling checker, to verify I don’t put any typos in any of my pages.
  • Since I try to use caching as much as possible, when a web page’s content has changed, I would like to automatically connect to my Memcached servers to purge the relevant pages from its cache so new versions are immediately available.

A fringe benefit is makes it fun and exciting to write unit tests! Whenever I find an area that isn’t covered, I sit down and crank out more tests to validate new features. I never want to be caught with my pants down on a deployment. Each time it catches something I missed, it makes the whole thing worthwhile.

Does anyone have any thoughts on how I can improve this? Is anyone doing something similar that I can learn from? I’m very excited about my new deployment system, and wish I’d had this ages ago. If there’s anything you want to know more about, please leave a comment.

Reblog this post [with Zemanta]

First impressions with PhoneGap

A few months ago I had the opportunity to meet with the crew developing PhoneGap down at their headquarters (Nitobi, down in Gastown district of Vancouver). It’s only a few blocks away from where I work, but the horrible downpour of rain made me think twice about going (hey, it is Vancouver after all). Next time I’ll bring my laptop with me, but it gave me an introduction to what they’re looking for help with, and where they’re taking PhoneGap.

Due to work and home commitments however, I haven’t been able to develop any applications for it until recently. I was stuck at home for almost a week with a terrible flu, and that gave me the opportunity to tinker, and helped me to avoid daytime television.

First Attempts

At first I tried to develop an app much in the same way I develop web applications on other browsers. I built a MooTools package including the dependancies I needed, stuck it in a directory, and began writing classes to implement the UI logic I needed. After compiling and getting it all onto the iPhone simulator, I screeched to a halt.

None of my logic worked. The static HTML was just that…static. So, I trimmed code, recompiled, rinse, repeat. Try again with jQuery, no joy. Try with XUI, and still things were behaving oddly.

Essentially I discovered that I was just trying to do too much. I pulled everything back, simplified my code, and did away with the external libraries. Importing MooTools and jQuery weren’t the problems exactly, though I figured it wasn’t helping. The thing I discovered is that WebKit, CSS3 and Safari’s JavaScript engine are sophisticated enough that there isn’t much need for complicated JavaScript toolkits.

Second, more successful attempts

After taking a step back, I went back to basics. I built my class using basic prototype class construction (though I miss “new Class({})” from MooTools). Instead of using JavaScript-based animations, I read up and implemented CSS3 transitions. I did my HTML layout debugging in Firefox with Firebug, proofed them in Safari on my desktop, and only then did I compile and test in the iPhone simulator.

My biggest problem was the lack of a debugger or JavaScript console on the iPhone simulator. My only way of accurately testing where my code was falling down was by issuing “alert()” statements, which of course breaks the flow of code.

I now have my app running smoothly, and as soon as my business name and licenses go through, I’m going to register as an Apple iPhone developer so I can test my app on my iPhone. With luck, I’ll be pushing my application through the AppStore release procedure, which I’m sure will be another learning curve as well.

For now, I’m happy with what I have. I’ve created a simple application that works client/server via XHR with fall-back to disconnected mode when there’s no network connection, the animations and transitions are smooth, and the JavaScript is minimal with no external libraries other than gap.js needed.

I’ll post again once I release, so everyone can see what it is I’ve been working with. I have great plans for future applications, and I’m excited about PhoneGap.

PhoneGap Impressions

Before I go though, I want to make a few points about my observations of PhoneGap. I might be misinformed on a few points, but the lack of documentation and its relative alpha/beta state may just mean that these features are coming.

  • No JavaScript console available
  • XCode can’t figure out when HTML/JavaScript dependancies change, so you have to do a “Clean All” before recompiling and testing your changes
  • XUI really isn’t ready for broad use, in my opinion. It seems like a great idea, and I would like to contribute to it, but it’s easier right now for me to write plain JavaScript.
  • Use CSS3 whenever possible; avoid issuing animations in JavaScript.
  • If you do have to do more complicated animations, use JavaScript only to piece together different sets of CSS3 animations by setting different CSS classes at intervals.

Fortunately, the PhoneGap google group is active, and quick to respond. I’m looking forward to becoming more involved as I build more with PhoneGap.