Get the source.

A note about the code: The source code is by no means the cleanest, nor is it the best implementation. This was a fun project exploring a few areas of personal interest. It’s not the worst, but be warned. (and have fun with it)

I typically end up using regex’s at some point in most projects. Anything with user input is pretty much a guarantee. Recently when adding some new functionality to a strip tags util I came across a situation I’ve never encounter before in ActionScript. As the title suggests I wanted to use a variable value in the expression, while this isn’t typically an issue, I came a across a situation where it didn’t work. Here is the real world example.

Original regex¹:

This nifty expression works like a charm. But I wanted to update it so the developer could limit which tags it stripped to those specified in a array. Pretty straight forward stuff, to use a variable value in a regex you first need to build it as a string and then convert it. Something like the following:

Pretty straight forward. So when approaching this small upgrade, that’s what I did. Of course one big problem was pretty clear.

Guess what, invalid string! Better escape those quotes in the string. Whoops, that will break the regex! I was stumped. So I opened up the language reference to see what I could find. The “source” parameter, (which I’ve never used before,) caught my eye. It returns a String described as “the pattern portion of the regular expression.” It did the trick perfectly. Here is the solution:

You can reduce it down to this for convenience:

Anyways, put that away into the old memory bank, it might come in handy.

¹Original expression from Mastering Regular Expressions, by Jeffrey E.F. Friedl

With stable requirements, a project can proceed from architecture to design to coding to testing in a way that’s orderly, predictable, and calm.¹

Of course anyone who has worked on anything knows this is exactly that, a dream. (He agrees) Changes are inevitable. They happen for a variety of reasons, and almost always² results in a better end product. You know they are going to happen, so you you need to plan for them from the start. You should have a change procedure clearly outline with the client, and account for them in the initial budget. Here’s why:

A project change that takes 8 hours for a developer to implement, can easily require 16 man hours from a project budget, and cause a 5 day disruption in the production schedule.

Whoa! What? That’s right. Changes aren’t limited to the time a developer spends implementing, it can affect a big chunk of the production. Budget needs to be set aside for handling requests, because even if the change never gets implemented, there is a cost associated with it. Before you can budget for it, you need to understand it. Lets look at the anatomy of a change request.

1. A problem is flagged.
Change requests always begin with a problem being identified. Problems vary greatly, from “User flow is confusing” to “We forgot about X, which our funding requires.” These can originate from the client or internally.

2. Communication
Once a problem has been flagged, all stake holders need to be updated on the situation. This happens through emails, phone calls, and meetings (internal and external). If a developer is currently build what has been flagged, they may need to stop and wait for a solution.

3. Exploration
Once everyone agrees that the problem is legitimate, and a solution needs to be found, options need to be explored. This can be anything from a meeting to user-flow diagrams and wireframes, there might be prototyping and multiple explorations. The bigger the change, the longer this will take.

4. Spec out the solution
Once a solution has been found it needs to be spec’d out for everyone. This should be in the form of a document that a client can sign off on and the developer can use to build from. It should clearly out line the problem, solution, and affect on the project cost/schedule.

5. Approval
Approvals typically have turn around time to them where everything is in limbo. Nothing can be done between the time the spec is sent out till approval. Typically there is a fair bit communication that happens here as everyone makes sure they understand the changes. This step will have one of 3 outcomes

1. Approval, production can continue
2. Proposal is rejected, modify or go back to step 2.
3. Client decides the change is out of scope/budget. Continue with the original plan, flag for future change.

6. Implementation
The process doesn’t end with approval, the team now must make the change. This means undoing any of the original implementation that has changed, and then building what’s new.

7. Test
Testing! Every change needs to undergo rigorous testing. Is it a web based application? You need to test in all supported browsers/versions.

8. Bug fixing
Changes introduce new bugs. When you fix a bug you have 20-50% chance of introducing a new one.³ For every bug fix you’ll need to retest all the browsers.

Even if the change doesn’t go through, there is a cost attached to it. You need to stop productivity and spend man hours before you can even decide if there is going to be a change. If there is, you might add additional cost to the project, if not it falls into just part of the production process.

This will happen to some degree on every project, so you need to account for it. Both in your time line and budget.

¹ Steve McConnell, Code Complete – Second Edition, page 39
² I’ve worked on projects where changes happen for the wrong reasons. Internal disputes, lack of experience, “absolute” orders from higher up, have all caused changes for the the wrong reasons leaving the end user to suffer. Sometimes you have to bite the bullet, but you don’t have to work with the client again.
³ Stat from The Mythical Man-Month, page 122, 1995 print

I recently updated this site to use Google Custom Search. It took me 5 minutes to setup, and now anyone can search for all the everthing that rocks on this site. I was so impressed I recommended it for a client project, now their search doesn’t suck either.

It actually gives you quite a bit of style control. You’ve got full CSS control over the search box (minus a little bit of Google branding), plus color/font choices on the results page, which you can display in site. Sure the Google results page isn’t the prettiest thing you’ve seen, but it’s usable, fast, and familiar to your audience (no matter who they are.)

If you need more control, you can upgrade to their very reasonable paid service. It’ll take years for the cost of the basic plan to reach what it’ll cost you to pay a developer to build you a bad search system. And by that time you’ll probably be 2 site revisions down the road and still have crappy search. So go for it, admit that you suck, and give your users something they can actually use. I’ll be doing it whenever I can.

Now if we could just stop people from using IE.

• Flexible writer model enables multiple logging types/targets
• Log filtering system
• Very extendable
• Instance based, not Singleton (the source of all evil AKA Darth Vader)
• Singleton wrapper for Vader loven’ developers
• Written entirely in ActionScript 3 for usage in Flex and Flash projects

With this release I’m also doing some new things that I will be carrying into future code releases as well. These are:

Unit Tests
I will be including my unit tests from now on. Because of the nature of unit tests (simple, clear, and to the point) they make for excellent usage examples that cover all aspects of a code base.

Formal Documentation
I will be releasing more formal documentation from now on. This will include more detailed information, including topics on usage and extending. It should make the code more accessible. Click here to see the ones included in the logger.

More Focused ASDocs
I’ve included ASDocs in the past, and will continue to do so. These will be focused on what they really are, (which is a language reference), and will not include anything beyond that.

If you find it useful, and create some custom writers or filters please share!

On both a technical and production quality level, this game is impressive. It breaks the notion that Flash based games need to be quick, simple, “casual” experinces.

I highly encourage you to check it out at titaniumchef.ca

Here are a couple in game screens:

We constantly deal with object lifetimes when we are developing our applications. Evidence of this is making sure we clear all references to an object so it can be cleaned up by the garbage collector. However object lifetime should play a much bigger role in the design of an application then that, and as a result deserves more attention then it gets. In this article we will look at what object lifetime means on a technical level, and then the role it plays in performance and application design.

Object lifetime is the length of an object’s existence in an application. Technically speaking, from when memory is allocated (reserved) for the object until it is deallocated (freed for re-use). This process is handled for us in ActionScript, but occurs based on our actions. For example when we use the keyword “new” memory is allocated for the object we are creating, and when the garbage collector cleans it up that memory is deallocated.

Based on the previous definition, we can look at our Flash applications in terms of lifetime. The Stage has a lifetime at the application level, meaning it exists as long as the application is running. An array that contains references to all the children in a DisplayObjectContainer has a instance level lifetime, so it will exist as long as the DisplayObjectContainer exists. Other object’s lifetime may be limited to a method call.

Often developers have objects who’s lifetimes are too long. I believe a it stems from a number of places, but based on work with other developers a few key place are:

• the knowledge that object creation is expensive
• a lack of formal programming theory, particularly Design Patterns, which offers tools for dealing with application design
• Insufficient focus on the topic in popular resources

Object creation in ActionScript is expensive, but so is keeping unneeded objects in memory. Managing object lifetimes in an application means creating and destroying objects as needed, allowing us to keep the application running at an optimal speed while using minimum resources.

Take for example a Flash website where all the major sections are created at application initialization. (which puts them all into application level lifetime.) Changing a section simply means changing the visibility property, or adding/removing display objects from the display list. The result is that the entire site is kept in memory all the time, regardless of if the user ever visits each section.

The truth is, that for many Flash sites, “micro sites” for example, you could argue this just doesn’t matter. Doing things differently would result in unnoticeable performance improvements on most modern computers, and the end user would not know the difference. This changes however with one particular changing/new (certainly new growth) market that is going to be huge for Flash, that market is cellphones. Cellphones are now starting to to have full Flash support, and we’re not talking about Flash light, but full Player 10 support. Suddenly that little bit of memory counts for a lot more.

So how else could you construct your site? The simple solution is to construct the sections as the user requests them, and destroy them when they leave them. You’re navigation might be at an application level lifetime, but each page need not be. What about the expense of creating new instances? Changing the section is a limited action, only happening on a user action, so it will not occur at a high rate of speed or necessarily at all, and therefore is not a issue. It becomes cheaper to build on demand and not maintain in memory for reuse. There are several design patterns to assist in the creation of objects, for example the Factory Method.

Looking at another example in a different situation, lets take a general button that offers several methods and properties for styling it, one of which is a label and another is an optional display object to use as an icon. The button uses a TextField object for displaying the label.

A common way of building this button would be to create a TextField in the constructor, add it to the display list, and maintain a reference to it through a private variable for changing the text displayed. The problem with this is that there will be situations where a button has no label, (an empty string), perhaps it’s strictly icon based instead. In this case you still have a TextField object in memory that you are not using, that’s one for each button instance, so potentially lots of them.  So our label TextField lifetime should not be the same as our button’s lifetime. When the label is set, the function handling that process should determine if it needs to create, dispose, or update the TextField object. Construction is not a performance issue because likely the label will only be set once, or not at all.

By paying attention to object lifetime in the design/construction of your application, and keeping objects in the proper lifetime scope, you can gain significant performance increases, especially as the application grows in size, or when targeting power limited devices. While this article only looks at specific examples, this is a topic that applies to every piece of you application, and as a result should be fully considered throughout the construction process. I’ll be exploring this topic more in future posts.

additional resources:

Managing Object Lifetimes, by Miško Hevery

ActionScript3 Design Patterns, Bill Sanders & Chandima Cumaranatunge

• Added lastPage property. Will return the page the pagination object was on before the current one, or zero if the page has not changed yet. This is useful for detecting the direction movement.
• Added getItemsOnPage(page:int):Array method. Allows access to the information on any page.

You can grab the latest version on the Code page.

Version 0.7.0 will feature a simple pagination control view, with the main goal of making prototyping easier.

Hover over a icon to see it’s tooltip:

This small library makes adding tooltips to ActionScript based projects really easy. Some key features are:

• Instance based, not Singleton (as it is in Flex) which allows for multiple instances to exist in a single application.
• Objects who have tooltips do not need to know about the display controller
• Easily add a tool tip to any custom DisplayObject

To add tooltips to an application you need to create an instance of ToolTipController. ToolTipController has two parameters, the first is the root DisplayObjectContainer that you want to find tooltips in, (It will automatically find any tooltip’s in it’s display list), and the second is an instance of the IToolTip interface which will handle the tool tip target.

The ToolTipController will look for any objects that implement the IToolTipTarget interface.

You can download it here (with demo)
and view the docs here.

This is a BETA release, so feel free to offer any feedback.

To create a new paginator you do the following:

Then to retrieve the data set for a page you can do the following:

It supports 3 page scrolling types, NONE (see all pages), SLIDING (current page in the middle), and JUMPING (jumps by groups of pages), additionally you can control the number of pages to appear at one time. (NONE ignores this)

Below is a simple demo using the sliding scroll style.

Download the source and demo here. (Demo code included)
View the docs here

This is a BETA release, so if you try it feel free to offer any feedback.