(I didn’t have any worth-while screenshots to show, so enjoy this photo of Adobe co-worker Matt Kursmark.)

I’d like to introduce DestroyTwitter 2.1.1 as a subtle update that carries a handful of improvements. First and foremost, there is now an option in the ‘Retweet Format’ preference for ‘native’. Many have asked for and/or demanded it, so I’m glad I’m finally able to deliver. What differs with this method of retweeting is its appearance upon submitting—if you’ve already seen the tweet you’re retweeting in your home timeline, you’ll simply receive an alert indicating success. If the original tweet hasn’t made an appearance in your home timeline, your retweet will drop in like the other formats. The reason behind this is Twitter only shows one copy of each tweet in your home timeline, even if that second copy is from you. Confusing? That’s Twitter for you.

Along with native retweets comes two welcomed features in the image service arena. Imgur joins the family of available services, though only anonymous support at the moment. Individual accounts will be supported in a future update. Also, image services now include the tweet’s text as the title or accompanying message of the image. You can thank @imjameshall for that suggestion.

In the Profile panel, you can now see how many lists the specified user belongs to. You can also click ‘view mentions’ to see tweets that have mentioned that user. Regarding fixes, I closed a number of runtime errors, which is always nice. I also fixed the image viewer scaling dimensions. Apparently, at certain ratios, the scaling was off.

That’s about it for this update, except for one undocumented feature I will keep to myself. If you read my blog, however, you’ll know what it is right away. If you’re a DestroyTwitter native, you should’ve been prompted for the update by now. Otherwise, download it from the website.

After releasing DestroyTwitter 2.0 back in June, I’m thrilled to announce it has reached the one million tweet milestone this past Friday, just shy of seven weeks. Once I added Google Analytics to Dwarf, I decided to include it in DestroyTwitter as well, tracking tweets, installs, and updates. Unfortunately, I didn’t think of using it for DestroyTwitter 1.x, so there’s nothing to compare this milestone to. Nevertheless, we’re going full speed ahead, averaging 30,000 tweets and 450 unique installs each day.

Its success to this day has been solely from word-of-mouth—something I’ve always been proud of. Keep spreading the word and I’ll do my best to continue growing DestroyTwitter in the right direction.

I’ve been sitting on this update for a few weeks now, but the recent move to San Francisco has kidnapped my spare-time. Now that I’m almost settled, I was able to take advantage of the weekend to prepare for this launch. The most anticipated feature in 2.1 is themes. This was a popular feature in 1.x that didn’t make it into the initial 2.0 release due to time constraints. Now it’s back, but greatly improved, using CSS instead of XML. Keep in mind, it’s not fully functional CSS—it’s AS3-supported, so you can only modify specific properties. Even so, the number of elements you can customize has been multiplied fourfold.

With the reintroduction of themes, I’ve decided to make a few other changes. First of all, the Theme Builder is no more. Since CSS is much more familiar to most and there are dozens more parameters, it doesn’t make sense to maintain it. Also, it allowed anyone and their grandma to upload a theme to the depot. This was great for usability, but unfortunately, it flooded the site with thousands of themes that went unused. At the moment, 2.1 is bundled with a handful of themes and there’s no directory on the site. I did set up a section on the support site to upload themes and I’ll showcase the standouts on the website.

Regarding the thousands of previously created themes from 1.x, you can still install them in 2.1, but you might need to tweak certain elements that didn’t exist in 1.x. In Preferences, click ‘Install theme…’ and select the .dtwt file. It’ll automatically convert it to a CSS file in the themes folder, where you can open it in your favorite text editor. From there, you can change the theme, save it, then click ‘Reload current theme’ to see the updated look. If you’re working on a certain section of the app and don’t want to go back to Preferences to click the reload link each time, you can use the hotkey Command+Option+Shift+R on Mac or Control+Option+Shift+R on PC.

If you’re all set and ready to go, either download 2.1 from the DestroyTwitter website or simply update from the app if you have it installed already.

Complete Window Resizing

For those updating from 1.x, you could resize the window vertically and use ‘Wider Workspace’ mode to view three canvases at once. No more! If you want to go fullscreen, go for it. If you’re weird and want to show Mentions and half of Home, feel free. And if you resize the window to within 40px of a canvas’s edge, it’ll snap to that canvas.

More Accessible Settings

Instead of placing every setting and its grandma under Preferences, I decided to relocate a few. Now, if you want to change the refresh rate of a canvas, you can do it straight from the canvas. These menus also provide you with the hotkeys that match the function, so you no longer need to reference the documentation.

Composing tweets is where the settings relocation really shines. Instead of closing the drawer and heading to preferences just to change your URL shortener or image service, you can do so straight from the drawer itself.

The search history is also a context menu now with a dedicated item for clearing the history or the current search.

Preferences Galore

Though many of the settings have been moved, a ton still reside in the Preferences canvas. There are now three different font sizes for the older folk, icon sizes (including none), and a few tweetflow options.

Improved Filtering

Filters in 2.0 were known as ‘Rules’ in 1.x. Now, they have their own drawer that can be accessed straight from the canvas without heading to Preferences. You can filter users, keywords, AND sources. This means if you’re like me and hate check-in services like Foursquare and Gowalla, add them to the sources filter and boom goes the dynamite.

Easter Eggs

2.0 includes a number of goodies that aren’t exactly obvious at first. I plan to add documentation sooner than later, so you can check them all out. Two worth mentioning for now are multi-touch navigation and scrolling through unread tweets. The first only for devices that support gestures, like Macbook Pros. You can three-finger swipe from canvas to canvas. If you’re tired of scrolling through trying to find the next unread tweet, simply hold alt when arrowing up or down. It’ll select and scroll to the next unread tweet in that direction if one exists.

A Few Missing Features from 1.x

Many of you will notice a number of features that exist in 1.x, but didn’t make it to 2.0 (yet). The biggest two that are sure to affect a good number of people are Themes and Groups. Because of Twitter’s approaching deadline for the OAuth cutoff, I didn’t have the time needed to implement these and fully test them. Even though Twitter extended the deadline, I wanted to stick to my launch date. Themes will definitely be in 2.1 and Lists (formally Groups) will be in 2.2 or even earlier.

Since these features are pretty important to some users, I decided to change 2.0′s application ID, so if you want to continue using 1.7, you can. Installing 2.0 won’t overwrite 1.7. The unfortunate part of this is 1.7 won’t prompt for an update, however, you can run them side-by-side until the OAuth cutoff in August if you need multiple accounts.

There are billions of other improvements and changes, so be sure to explore a bit. Also, take note of memory usage. After a few solid weeks of testing, we’ve seen usage as low as 25mb. Not once have I seen it reach 70mb—and that’s after 24 hours of usage.

PLEASE READ

Now, this morning I had a number of issues with the destroytwitter.com domain, so it might still be propagating throughout the world. Also, make sure your address isn’t using the https URL. If it doesn’t load for you, you can download 2.0 here.

Enjoy it and if you have any feedback, bugs, or questions, hit up the new support site: http://support.destroytwitter.com

It’s time. I need 100 testers to run through every aspect of DestroyTwitter 2.0 and report any bugs they come across. Up to the task? Request an invite.

[update] – The invites were sent out this morning. If you didn’t get one, don’t sweat—the public release will be out next week.

It’s a big day in Adobeland—both AIR 2.0 and Flash Player 10.1 make their debuts. Lucky for me, they arrive just in time for the soon-to-be-released DestroyTwitter 2.0, which relies on a few fancy features in the new runtime. I’m planning for a June 21st launch, so mark your calendars and make sure you install AIR.

Since the beginning, Twitter has supported Basic Auth as a form of authentication. On June 30th, however, they plan to pull the plug. If you’re unfamiliar with authentication processes, Basic Auth involves attaching the user’s username and password to a request header. It’s as simple as can be for developers, but not exactly safe for users. Although many developers wouldn’t even consider tampering with a user’s account, the dark side still lingers.

Because of this, OAuth was introduced to keep users’ passwords out of 3rd party hands. Instead, an access token is given to the 3rd party for each user. With it, they can call any of the methods in the API that Basic Auth could, but users can feel safe knowing only Twitter holds their passwords. Though this sounds all well and good, it certainly has its downsides.

For one, the login process isn’t as smooth—for both the user and the developer. This diagram compares the user experience of Basic Auth versus OAuth. As you can see, OAuth is a bit long-winded. It’s even worse for the 3rd party. They bear the burden of encoding and signature parsing. From a user experience standpoint, the worst part of the OAuth process lies in the last three steps. Twitter is not a bank. Requiring the user to copy, paste, and authenticate a pin adds three unnecessary steps.

Prior to DestroyTwitter, I developed DestroyFlickr, which authenticates with Flickr to access its API. This process involves entering a username in the app, which opens Flickr.com, asks you to login if you haven’t already, then verifies that you’d like to authorize this app. Finally, return to the app and you’re good to go.

Now, Twitter does have an alternative authentication method—xAuth. Imagine if Basic Auth and OAuth had a baby. The process is the same for the user as Basic Auth, but the 3rd party is given an access token, just like with OAuth. There’s one problem—it still divulges the user’s password to the 3rd party, just like Basic Auth. Even though Twitter says, “Storage of Twitter usernames and passwords is forbidden,” this single sentence isn’t going to stop a malicious 3rd party from exploiting users.

Let’s look at one last issue that arises with OAuth. For Twitter app developers, how do you authenticate with services like Twitpic?—with the user’s username and password. If the 3rd party can’t store users’ credentials, it’s impossible for them to authenticate with the service. Unless Twitter releases this proposed echo method with enough time to implement, you will either see a massive drop in Twitter service usage or Twitter app developers will ignore the no-storage rule and put us back at square one.

Keep in mind, a lot can change between now and June. Let’s hope Twitter improves the user experience by removing the need for a pin. Let’s look forward to a way to communicate with services without sharing users’ credentials. With enough of a heads-up, June 30th will just be another day. If, however, Twitter makes a change in the eleventh hour, we might see a number of frantic developers.

[update] – Twitter updates OAuth docs to prepare developers for June.

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.

Anyone who knows me has probably seen me in front of a computer more often than not. And with every year that goes by, I feel one step closer to burning out. I want to be able to code for as long as I can, but I know it isn’t healthy to maintain my current pace. In college, the morning/day/night work schedule made sense—I was surrounded by peers who worked around the clock as well. Now that I have a full-time job and a family, it’s time to balance the work with a period of downtime and recreation.

I will continue to respond to emails regarding DestroyTwitter as best I can, but I have no plans to post the source code. If you have any questions, feel free to ask them in the comments. It has been a fun year and I can’t thank you enough for contributing to the project.