I’ve been working on Dwarf over the past few days and decided it’s time to give a little introduction on its key features. Be sure to view fullscreen with no scaling to see it at 100%. The prerelease of Dwarf available to download on GitHub and the source code is hosted there as well. I’ll be rolling out the official 1.0 build pretty soon—I just need to add a few more key features.

A recent AIR prerelease drop broke Dwarf. I’m actually not surprised, since it uses a pretty ghetto hack—displaying a transparent window fullscreen and using ‘virtual’ windows. Because Dwarf is such an integral part of my everyday workflow and it’s such a small app, I figured I could easily rewrite it within a day or two. I’ve been on such a code-sharing high, that I started a new Git repository for it where you can find my work in progress. So far, I have a single ruler working with a semi-functional Mac toolbar. Everything should be complete either tonight or tomorrow, so keep an eye out.

On a legal note, the source code is provided under the GNU General Public License (GPL), so you can reuse and modify the code all you want as long as it’s still free. If you’d like to use it for commercial purposes, let’s talk.

My good friend, Luke Williams, finally launched his weblog—yes, I used the full word. Even though it has only been live for a short time, he already has a solid amount of fresh content. I know Luke is determined to keep this one active—as opposed to his first attempt, which ended up being comment-spammed by myself impersonating some of the more interesting people from MICA. Check it out and let him know what you think.

Thanks to the oh-so-wonderful GitHub, I was able to fork the repository, implement the fix, write a unit test to verify it’s safe, and find in the morning that it has been integrated into the actual RobotLegs repository—just like that. If you experienced the bug, be sure to pull the latest commit.

Now, if you’re not on GitHub, do yourself a favor and join today. In the few months I’ve been a member, I’ve met a handful of incredible developers and now feel compelled to share code when I can. Everyone benefits when you share what you know.

About five or six months ago, Twitter decided to enforce the transition. From then on, any application that uses the API must use OAuth in order to see “via [your app]” on tweets published with it—otherwise, it would display “via API.” Since “via” is where apps get probably 90% of their referrals, this was a big deal. Luckily for me, DestroyTwitter existed before that time and Twitter decided not to push the change on the veteran apps. Recently, however, the bad news spread that Basic Auth would be deprecated in June. This means every Twitter app must transition to the pain that is OAuth.

After developing the MAX Companion this past fall and now the more generalized version, I found myself rewriting the Twitter component each time. After a while, the Twitter API code I wrote for DestroyTwitter began to merge with the actual implementation, so it was no longer a standalone library that could easily be used by other projects. These past few months, I’ve been learning a great deal about framework architecture and design patterns. It has led me to realize I need to start fresh.

With all that being said, I’d like introduce a library I started working on two days ago. I call it TwitterAspirin. It’s an AS3 Twitter API library that eases the pain, providing developers with a very powerful tool for communicating with Twitter. Though it’s still a newborn at the moment, I see potential already. The library is built on RobotLegs and uses AS3 Signals instead of events. It’s hosted on GitHub, so the source code will always be available to the public. And, after last night’s commit, its OAuth functionality is complete. Here’s how to use it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

package {
	import com.destroytoday.twitteraspirin.Twitter;
 
	import flash.display.Sprite;
 
	public class Test extends Sprite {
		// set application consumer key and secret
		public var twitter:Twitter = new Twitter(consumerKey, consumerSecret);
 
		public function Test() {
			// add signal listeners
			twitter.oauth.requestTokenSignal.add(requestTokenHandler);
			twitter.oauth.accessTokenSignal.add(accessTokenHandler);
			twitter.oauth.verifyAccessTokenSignal.add(verifyAccessTokenHandler);
		}
 
		// click the 'Authorize' button to get the request token
		protected function authorizeClickHandler():void {
			twitter.oauth.getRequestToken();
		}
 
		// upon receiving the request token, open Twitter in the browser to authorize
		protected function requestTokenHandler(oauth:OAuth, token:OAuthToken):void {
			navigateToURL(new URLRequest(oauth.getAuthorizeURL()));
		}
 
		// return with the provided pin and click the 'Activate' button to get the access token
		protected function activateClickHandler():void {
			twitter.oauth.getAccessToken(pin);
		}
 
		// upon receiving the access token, verify it
		protected function accessTokenHandler(oauth:OAuth, token:OAuthToken):void {
			oauth.verifyAccessToken(token);
		}
 
		// done
		protected function verifyAccessTokenHandler(oauth:OAuth, token:OAuthToken):void {
		}
	}
}

As you can see, it’s extremely easy to use. Not only that, it provides great flexibility. Many libraries are simple to implement, but don’t allow the developer access to certain aspects of the process. With TwitterAspirin, each method returns the loader involved with the operation, giving developers the ability to listen for errors, cancel the operation, or attain the raw API data. The library also uses loader pools to recycle instances, so you can submit a tweet and, while it’s loading, submit another—you don’t have to wait for the first operation to finish. Then, once the operation is complete, the loader is disposed and returned to the pool, which optimizes performance and memory usage.

I’m really excited to see where TwitterAspirin goes and I have nothing but great expectations. Be sure to follow along with development and fork whenever you like.

So why an XMLLoader class?—because 99% of the data I load with AS3/AIR is in XML format. I stay far from JSON when possible because in AS3 it’s slower than a slug on its day off. XML is native and uses E4X, which lets developers navigate its information just like you would an AS3 tree. I load XML so often, I found myself copying and pasting the same code each time I’d need it—this is the clearest indicator that a class must be written.

Parsing String data to XML poses an issue that many don’t know about. I only discovered it because of the Twitter API. The API is so janked, it sometimes returns the HTML error page instead of the XML response. It wouldn’t be so bad if it weren’t for an image tag in the HTML that isn’t closed. This immediately throws an “XML parser failure: element is malformed” error. Using try/catch is the only way to avoid this. That’s why I wrote it into XMLLoader. It automatically handles the data, attempts to parse it, and, if there are any errors, the load stops and dispatches an error signal.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

package {
	import com.destroytoday.net.XMLLoader;
 
	import flash.display.Sprite;
 
	public class Test extends Sprite {
		public var loader:XMLLoader;
 
		public function Test() {
			loader = new XMLLoader();
 
			loader.retryCount = 2;
			loader.includeResponseInfo = true;
 
			loader.openSignal.add(loaderOpenHandler);
			loader.completeSignal.add(loaderCompleteHandler);
			loader.errorSignal.add(loaderErrorHandler);
 
			loader.load("http://search.twitter.com/search.atom?q=destroytoday");
		}
 
		protected function loaderOpenHandler(loader:XMLLoader):void {
			trace(loader);
		}
 
		protected function loaderCompleteHandler(loader:XMLLoader, data:XML):void {
			trace(loader, data);
		}
 
		protected function loaderErrorHandler(loader:XMLLoader, error:String, message:String):void {
			trace(loader, error, message);
			trace(loader.responseStatus);
		}
	}
}

Speaking of signals, XMLLoader is the first class in DestroyFramework to use Robert Penner’s AS3 Signals instead of events. If you have to ask why, you haven’t been programming in AS3 long enough. Each XMLLoader instance has signals for open, complete, error, and cancel. The class also includes a retryCount property that indicates how many times to attempt to load a URL before calling it quits. Since some APIs can be down one second, then up the next, this feature really comes in handy. It’s mainly intended for handling the beloved fail whale.

The last two features include a cancel method and an includeResponseInfo property. Sure, URLLoader has a cancel method, close, but an exception is thrown if you call close when no operation is in progress. This makes sense, but the runtime shouldn’t close down shop when it happens. XMLLoader instead cancels and dispatches the cancel signal when the cancel method is called, and if no operations are in progress, it simply does nothing.

The includeResponseInfo property is an incredibly easy way to tell the loader to return the response status code and headers upon success or fail. Without XMLLoader, you could get this information with an event listener and the appropriate handler, but it’s far easier to flick a switch. In all honesty, I’ve neglected to retrieve this info using URLLoader in the past simply because it’s such a verbose process. Now that it only requires setting the property to true, I know I’ll use it more often than not.

As always, the source code is available on GitHub. Be sure to keep watch—my account will be pretty active these next few weeks.

Last week, I started replacing events in DestroyFramework with Rob Penner’s AS3 Signals. They’re faster, shorter, and include a few methods that developers have been dying for. Unfortunately, the first implementation, into my new Group class, didn’t work. I was puzzled to say the least. After literally hours of testing and debugging, I discovered the culprit.

It turns out, the remove(listener) method lacks a check for listener existence in the listeners array. When the method is called, if the index of the listener returns -1, the array splices the first listener. I forked the Git repository and implemented the fix on the Signal, NativeSignal, and DeluxeSignal classes. And because a fix isn’t a fix without proper unit testing (says Joel Hooks), I added the unit tests as well.

I have a number of new DestroyFramework classes ready to document and check-in over the next few days. I plan to get back into sharing interesting and useful things I come across, regarding both programming and design. And, now that I’ve been introduced to MVC(S) and RobotLegs, I have a lot more to talk about—expect a tutorial in the near future.

To add some imagery to this post, below is yesterday’s Destroy Everyday post featuring Andy Mangold. I also included a detail shot because the web-sized image really doesn’t do it justice.

It’s the new year and the best day to start anything. In my search for a hobby off the computer, I compromised and found a semi-off-the-computer challenge. Jen led me to the “Make Something Cool Every Day” concept. It’s a great motivation to consistently produce work while strengthening creativity. The best example I’ve seen yet is Brock Davis’s portfolio on Behance. Surely, I don’t expect to think up ideas as original as his, but I plan to use this as a stimulus to return to photography, print, and any other physical mediums I’ve neglected over the years.

The daily creations will reside on destroyeveryday.com as a Tumblr blog. The service provides a dozen different ways to post content, so “I didn’t have access to a computer” won’t be an excuse for missing a day—believe it or not, you can post content via a 1-800 number. Here’s to the new year and the beginning of a new venture.

1
2

[Embed(source="assets/fonts.swf", fontName="Helvetica")]
protected static const HELVETICA:String;

This past week, I came across the same issue twice. Up until now, I only worked with fonts that used the fontName as it appears in Flash’s properties panel. Sure, this works for fonts with simple names, but when you start getting fancy, things get messy. I needed to embed Alternate Gothic No. 2 and Flash labeled it as “AlternateGothic” with “No2″ as the style. I set the fontName as “AlternateGothic No2″ and was presented with this familiar gem:

I get shivers each time I see it. After a few minutes of failed guess and check, I set out for a solution. I opened FontExplorer X and discovered that the font is labeled as “AlternateGothic-No2″.I gave it a shot and boom went the dynamite. From then on, I thought that would be the correct fontName—the font’s label in Font Explorer X.

I was wrong. This week, I needed to embed Helvetica Neue Roman, which is labeled as “12 pt Helvetica* 55 Roman 05472″ in FontExplorer X—freaky, eh? I tried it out and the error returned. At first, I was bummed because I thought I had a foolproof solution. I was close, but no cigar. I opened Font Book to get a second opinion. Apparently, the font’s true name is “12 pt Helvetica* 55 Roman 05472″, which means FontExplorer X removes redundant whitespace, found in our example between “Roman” and “05472.” I tried it out and, sweet sassy molassy, it worked.

From now on, I’ll consult Font Book when embedding a new font.