iOS/Web Developer's Life in Beta

I’m a big fan of all things Apple, and as you can tell from my past blog posts I’m a big fan of iPhone development. I’ve even dusted off my aging C skills, and have learned to love Objective-C. The one thing I haven’t learned to love, like all other iPhone app developers, is their application release process, and the seemingly arbitrary app store acceptance department.

Don’t get me wrong, I think how Apple fiercely guards the App Store to prevent bad, buggy, or offensive material from getting on there is a great thing. Some of my mother-in-law’s students in the class she works in have iPhones or iPod Touches, and these little 10-year-olds love the little apps I’ve put out. They’re fun, light-hearted, and they get a lot of enjoyment out of these and other apps. It’s reassuring to know that if I install an app, it won’t crash my phone (too badly) or that a child won’t be offended by them (too much).

However, the level of detail they give in their rejections seem both arbitrary and unnecessary. You develop an app and have to throw it over the fence to Apple, after which you wait with no level of detail as to the status, or success, or any sense of progress through whatever queue they have. Finally, you more often than not get a big fat rejection letter that gives you no detail as to why your app didn’t meet their secret criteria.

In my experience so far, this has actually been a virtue. My apps actually did have minor race conditions, or problems on specific platform versions. So, fair enough, I fix my changes and submit them in. But recently, the framework I work with and have been helping develop seems to be under fire from Apple for no apparent reason. And it’s the contradictory nature of their message that is what gets under my skin.

In this long thread on the PhoneGap mailing list, a number of developers writing their applications under PhoneGap have been given rejection letters saying something like:

Upon review of your application, cannot be posted to the
App Store due to the usage of private API. Usage of such non-public
API, as outlined in the iPhone SDK Agreement section 3.3.2 is
prohibited:

” An Application may not itself install or launch other executable
code by any means, including without limitation through use of a plug-
in architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded and used in an Application
except for code that is interpreted and run by Apple’s Published APIs
and built-in interpreter(s).

The PhoneGap API implemented in your application is an external
framework.

For those new to PhoneGap, it’s a project that gives you an XCode project directory with Obj-C classes pre-made that allow you to develop iPhone apps in HTML / JavaScript. It wraps up several of the iPhone’s native controls and exposes those capabilities to JavaScript. In this way, an application developer could write their app in a hybrid of native Objective-C code and the iPhone’s own native browser control, the UIWebView.

It seems though that Apple constitues the use of their own controls as a 3rd-party library. Apple’s own developer documentation includes code sample projects, much like PhoneGap’s, intended to get a developer started on using their SDK. Is it incorrect to assume that others can do the same?

Additionally, there are 3rd-party companies such as AdMob, Medialets, and a number of others that provide ads, application tracking, and other resources to iPhone developers. Their code is given to you as pre-compiled libraries, that are most certainly not included on the iPhone when you pull it out of its shrink-wrap. So how is it that all these apps are released to the App Store with these 3rd-party libraries linked in, and an app framework whose source code is freely available and uses officially documented features can’t be?

I decided to put an end to the speculation, and wrote a letter to Apple’s developer support on this matter. I’ll give it a chance to percolate through their support department, and if I don’t hear an answer back via email, I plan to call their support department until I can get an answer.

For future reference, and in the interests of keeping the discussion open, here’s a copy of the letter I sent in to Apple.

From: Michael Nachbaur
Date: May 17, 2009 6:04:28 PM PDT (CA)
To: idp-dts@apple.com
Subject: Library classification clarification

Hello, I’m an iPhone software developer, and one of the core developers of the PhoneGap project. A number of users of PhoneGap – a set of Objective-C classes aimed at leveraging the UIWebView to access iPhone-supported hardware features – have reported that their apps have been rejected from the App Store because they supposedly use a “3rd-Party Library”. I wanted to get some clarification about this, as this is not only untrue, it is completely at odds with the goals of our project.

PhoneGap only uses officially-supported features of the iPhone, as documented within XCode’s iPhone SDK documentation. We even make sure that we don’t even use deprecated features of the iPhone, as we want to ensure 100% compatibility. All the software we use is exposed natively by the iPhone, and is in use in many other apps on the App Store.

So I wanted to get an official clarification from Apple as to why these apps are being rejected, and what, if anything, we as the maintainers and developers of the PhoneGap project can do to rectify the situation. We are trying to empower developers with quality starting-blocks for developing their own applications, much as the Apple sample applications do.

So please, if there’s anything we’re doing wrong, we would more than happily change our code to accommodate Apple’s policies. As far as we can tell, we support Apple’s licenses even better than other apps on the App Store, because we don’t import 3rd-party libraries such as AdMob, Medialets, or any of the other ad and tracking libraries that are obviously featured on almost every app in the App Store. And these are quite plainly 3rd-party libraries, and as such should they not be even more restricted than we are?

As a community, of both software developers and of business-people, we are very anxious to hear back from you, and would like to discuss this with someone at Apple to get an official answer, instead of the conversation being one-sided and filled with speculation.

Thank you for your time, and I look forward to hearing back from someone soon.

What are your thoughts on the matter? Can anyone reading this find some reason why Apple would target PhoneGap?

Update: I got an update on this problem from Steve, one of the app reviewers, over at Apple.

I’ve merged the results of my UIControls branch on github into my master branch. I think my little experiment went well, and I’d love to get feedback from people on how this new API works for you. I still have some great plans for it, but before I get ahead of myself, let me cover what I’ve done:

Changes:
• Refactored the command call API to allow for a richer set of arguments to PhoneGap commands
• Moved some commands around to more appropriate classes (e.g. Alert and Vibrate both moved to Notifications)
• Reorganized the XCode project so commands are clearly separated from PhoneGap infrastructure
• Renamed the Settings.plist PhoneGap config file to PhoneGap.plist, and created a new Settings.plist file that contains custom application-specific configuration.
• Made all PhoneGap commands inherit from a common base-class that auto-loads its own Dictionary of configuration from the main PhoneGap.plist file.
• Added UIControls command class that exposes tab bars and toolbars to JavaScript.
• Updated the demo to show off tabs and toolbars

All that looks like a big change, but almost all of it was infrastructure changes that were necessary to get UIControls to work. Previously, all PhoneGap commands were class method calls, meaning it was very difficult to maintain state between command calls. Now that commands are actually called on an instance of a given command class, it’s easier to maintain state. So when a tab bar is created, multiple calls can be made, each to construct different aspects of the UI. Without all this, the following example would have been much more complicated:

uicontrols.createTabBarItem(“toprated”, “Top Rated”, “tabButton:TopRated”);
uicontrols.createTabBarItem(“recents”, “Recents”, “tabButton:Recents”);
uicontrols.createTabBarItem(“more”, “More”, “tabButton:More”);
uicontrols.showTabBar();
uicontrols.showTabBarItems(“toprated”, “recents”, “history”, “more”);

The changes to the PhoneGap configuration were necessary because now, when a PhoneGapCommand subclass is constructed, it will look in the PhoneGap.plist configuration file to see if there’s anything pertaining to it. So if there’s a key in the dictionary with the same name as the class being constructed, it will use that as a local configuration dictionary influencing just that one class. That way, if you don’t use a feature of PhoneGap, or you have to configure a lot of options for a single type of command, these options won’t be cluttered alongside the standard global PhoneGap settings.

I created Settings.plist because of experiences I had in an application I’ve been creating in order to test my new UIControls branch changes. I found that I wanted to set compile-time options (for instance a “lite_mode” boolean) that influenced the way my app runs, without having to change HTML or JavaScript code every time. So instead what I have is a configuration plist file that is used exclusively in JavaScript for my application. I’ve added the excellent SB-JSON framework in to the PhoneGap project, and use that to pass these settings into the JavaScript application at start-up time. So all you have to do is read Settings.lite_mode, for instance, in order to read properties set in your plist file.

Oh, and finally, I’ve moved the JavaScript documentation to javascript/docs, since they were practically impossible for new users to find in the past. I’ve been working on creating DoxyGen docs of the PhoneGap code for use in XCode’s documentation browser, but I haven’t gotten far enough there to actually check anything in besides comments. I found instructions on how to generate XCode docsets from DoxyGen, but I haven’t gotten it working just yet.

So please, try out my PhoneGap updates and let me know what you think of it. I think the integration of the JSON framework will make things like Contacts much simpler to implement.

Before I go though, I want to give a little “wish list” of features I’m planning on adding in the near future. I’ll get to them whenever I can, since my own app development takes priority of course.

• Toolbar buttons
• Tabbar show/hide animations
• File support (read / write local files)
• Camera and photo library support (POST to a server, save to a local file, etc)
• Native “Flip / Slide” transitions (no more having to mimic them in CSS)
• 3rd party API integration, like AdMob and Medialets (I already have both of these done, but I’m in discussions with both companies to determine if the terms of their license allows me to redistribute it)

Last Thursday I went down to Nitobi after work for a couple of beer and a chat about PhoneGap before I had to go give a couple lightning talks at the Vancouver.pm Perl Mongers group. My hour chat with a couple of the Nitobi crew turned into over 2 hours, making me late for Vancouver.pm, but I think the effort was worth it. First off, they have good taste in beer. Second, I had an opportunity to do a little show-and-tell of my PhoneGap branch on Github. Not only did they like my changes, but I told them what my roadmap of features for PhoneGap includes, and I think they’re on board.

So to that end, I’ve started with the changes I said I’d work on. I cleaned up the console / debug logging code I recently developed, to allow for the main meat of what I’m working on: A flexible API for dynamically creating native UI widgets such as toolbars and tabbars. But before I can do that, I wanted to refactor the calling method that PhoneGap uses.

In order to make PhoneGap commands stateful, and to be able to pass a richer set of instructions to those commands, I’m refactoring the call API to look like so:

gap://Class.Method/arrayEl1/arrayEl2/…?dictKey=dictVal&…

The first command to a given class will construct it, passing the reference to our UIWebView to it as a constructor argument. All command classes now inherit from a new class called PhoneGapCommand, which stores the webview as an instance property.

So then the first, and all subsequent commands, are invoked with two parameters:

1. (NSMutableArray*)arguments
   This is a list of arguments passed on the path component of the URI. They’re URL decoded for you, so any %-encoded characters will be expanded for you.
2. (NSMutableDictionary*)options
   This gives you a dictionary / hash of the query string component of the URI. This is always passed, but if a command doesn’t supply a query string, the dictionary will be empty.

Calls from within JavaScript will take the first hash (object in JavaScript notation) it sees and will use that as the query string. All other arguments need to be strings / numbers, or else they’ll be dropped. This means you can pass your options hash as the first, or even the last argument in a PhoneGap.exec call.

The bulk of this code is almost done, so I’m excited to hear what people think about this. I’m just getting the existing commands working with this model before pushing back out to Git, at which point I’ll continue on and implement native UI toolbars / tabbars.

Update: I’ve updated my branch on Github with my latest changes. I think they’re great, but there are still some changes that need to be made. I got most of the API working, except for contacts. But since they weren’t working so hot to begin with, and someone else has stepped up to the plate to improve Contacts, I’ll let him merge his updates in to my new code. Next up: native UI controls!

I’ve been working on some pretty fun changes to PhoneGap recently, which hopefully will be merged into the main branch soon. (Brock? Any word on that? It’s now 12 days, and counting) In my branch of PhoneGap I added console logging support, I implemented queueing of commands so they don’t walk over each other, and finally (and perhaps more importantly) improved the JavaScript build system and infrastructure.

PhoneGap’s JavaScript Structure

PhoneGap is broken up into several different .js files, each of which implements a part of the PhoneGap API. And with recent changes to PhoneGap’s Objective-C code, the implementations of those commands are divided nicely into their own separate classes. Additionally, there’s platform-specific implementation hooks of those APIs which make the necessary calls in to the native code that implements those commands. At build time, a Rakefile is used to compile these together into one single “phonegap.js” file that can be included into your application.

But in the main branch currently there’s a number of bugs that prevents this system from working. The JavaScript files were being loaded in a bad order, causing prototype methods to be overwritten instead of extended.

I’ve hacked something together to improve on this, but this is really just a stop-gap measure. Really what should happen is an actual JavaScript framework should be adopted to help with class loading, extending classes, and implementing interfaces.

JavaScript Frameworks FTW

I’m a big fan of MooTools, so most of my day-to-day web work is in that framework. But really, most libraries solve the basic problem of “Here’s a base class, I want to either add to it, or subclass it to add more behaviour”. You never know how much you rely on something like that until you have to do without.

I found myself in the uncomfortable position of having to implement prototype-based inheritance by hand, and not in the fun way. This brings me to the main reason for this post, besides the subtle prod to Brock.

I want to see a client-side library that works well for light-weight apps, but still provides capabilities to extend classes, find elements using CSS selectors, provide helper functions for performing CSS-based animations, and provide event binding and closure-wrapping support.

I started toying with JQTouch, and while it’s certainly intriguing, it doesn’t solve some things just yet.

1. It’s still based on the stock jQuery, which is still pretty large, weighing in at 56KB
2. jQuery’s event object doesn’t support any of the iPhone’s touch and rotate/scale event properties. You can get at it by saying “event.context.“, but at that point why bother? The native event object is just fine.
   
3. It doesn’t address some basic issues I have such as function binding

So far I’ve managed to resolve my above issues with PhoneGap’s JavaScript API for the time being, but long term I think there’s some definite needs for the iPhone platform in general. We need to lose the platform-independant thinking of the standard frameworks (“Am I in IE? Am I in Opera?” needs to go). We need to have something that improves upon the already excellent CSS-based animation support of WebKit, and provide more abstract behaviours. And finally, we need to provide capabilities that let us define class-based applications with rich event and callback binding support.

The reason we’re developing applications under PhoneGap is because we want to build apps faster than we could if we developed in native Objective-C. So we need to have a JavaScript library that doesn’t get in our way, and actively solves the problems with JavaScript that WebKit doesn’t already solve.

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.

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.

At work I needed to perform an animation on a sprite-based image (e.g. one large image containing multiple stages within an animation, pre-rendered). Since there was no easy way within Mootools to iterate over an array of class names, I created one. I called it “Fx.Index”, but if you have a better name for it, please leave me a comment.

Fx.Index = Fx.Base.extend({  initialize: function(el, css_classes, options) {      this.element = $(el);      this.css_classes = css_classes;      this.parent(options);      this.previous_index = null;  },  increase: function() {      var index = this.now.toInt();      if (this.previous_index == index)          return;      this.previous_index = index;      var klass = this.css_classes[index];      if ($chk(this.options.classBase))          klass += " " + this.options.classBase;
      this.element.className = klass;  }});

This code is taken straight from our product, which uses Mootools 1.11. So I’ll post an update once I port it to Mootools 1.2, at which point I’ll submit it to be added in the not-yet-created plugin directory.

I’m developing an Ajax web application in Mootools. Two actually, if you consider the work I do with my day job. At work we’re using the older 1.11 version of Mootools, but in the interest of helping this great project, I’m doing my spare-time development using version 1.2.

Mootools 1.2 makes it a lot more obvious how to extend and create your own subclasses of existing objects. Instead of writing all my fancy UI components as a series of functions within my page’s class object, I can create separate objects to handle individual features and call out when I need to. The workflow and API is much cleaner and is far more consistent.

I’ll delve into more about my uses of Mootools later, since I’m currently up against a wall at work. We’ve got to get our release out soon, and I have a number of bugs assigned to me to fix.