Articles

Original image from dontoine, idea courtesy of @seantron

This week was an incredibly rough week for Flash and Flex Developers. Adobe announced that it would cease active development of the Mobile Flash Player, choosing instead to focus on developing tools, solutions, and browser processes targeting "universally supported" (accuracy of this statement somewhat dubious) HTML5. The Flash Platform will continue to be developed in what seems to be a more focused manner—the Flash Platform being streamlined to mobile applications packaged with Adobe AIR and more innovation with tools related to gaming and video. That's great, and it's really not news if you consider it. Adobe has regularly been mentioning this direction over the past few years and this sounds in line with its inability to attain the Flash Player's same ubiquitous installation base in the mobile space as in the desktop space.

The major pain was more sharply felt when Adobe dropped their second bombshell of the week: the announcement that Flex would be donated to an open-source foundation and that "[Adobe believes that] HTML5 will be the best technology for enterprise application development." For developers who've invested many years in Flex development, I'm sure this felt like a solid punch in the gut. This was no more apparent than in a mass-flash-developer community video chat last night where many developers cried foul on Adobe's handling of its "abandonment". Topics included...

• How are we supposed to explain to our clients that Flex is a viable technology for their Enterprise product when the makers of said technology are saying what amounts to "HTML5 is better?"
• What's the migration plan?
• Where are my HTML5 tools that allow me to start making kick-ass HTML5 apps right now?

These and other questions were posed, often in a tone of considerable vitriol. Well, I'd like to address some of the statements and questions made during this chat. Naturally, these are completely my opinion, so feel free to tell me yours at @typeoneerror on Twitter. I wrote some of these somewhat ranty sections while listening to the Flash community video chat last night so they aren't really in any meaningful order.

"How do I explain this to my clients?"

Communication is everything. Adobe certainly has made this clear with their lack thereof. With your clients, present the facts and the facts only. Your client ultimately pays you to develop their Enterprise product, so if they decide that their application should run on iPad, you need to solve that problem for them. You cannot look to solve creative problems with a technology-first mindset. It's a square peg/round hole situation; trying to apply Flash to everything is somewhat foolish. Is interactive even the best solution to your client's problem? Maybe it's a motion graphics piece instead? You cannot blame a corporation if you cannot answer that challenge, only yourself, right? Can I package it as an AIR app? Will I have to completely remake it using HTML5 technology? Which leads to...

"Flash is better than HTML5!"

Of course it is (and you know it so well, so that helps), but that's not what this is about. You need to be able to provide your clients with business solutions. That could be a Flash app, that could be an HTML5 app, hell, it could be a knitted wool cap...the point is, if it makes sense for the client, then that's the tool you should use. If you don't like the HTML5 technology stack and don't want to do web development with its technologies, you should focus your considerable skill on something else. Simple, right? Again, communication is key. Manage expectations. "You want that massive enterprise app rebuilt in HTML5? OK, not a problem, let me just be clear it's going to take twice as long and cost twice as much." That's the reality. That would be your or your client's decision to weigh whether that cost is a good business decision.

"Now I have to do browser/device testing."

No, you don't; not if you don't want to. Think how easily your Flash API knowledge could be applied to Unity 3D, or decide to pick up C# and focus on XNA gaming and push apps to Xbox, Windows and Windows Phone 7. Pick up Objective-C and make iPhone apps (check out the Sparrow Framework inspired by the Flash API!). The point is, don't be completely tied to a single technology. Performing quality assurance is just about the worst part of being a web developer, so if you don't want to do it, you may have to try a platform that is a bit more locked down.

"It costs more to develop in HTML."

A boatload more—tell me about it. Boy did I love the days back when I was the technical director at BKWLD when all we did was develop Flash sites. Save, Publish, Upload...hey QA is done! So, HTML apps take a bit more time to QA. You should factor that into your costs if an HTML app is the best solution for the project. Simple as that. BKWLD recognized the value of a non-flash product a few years ago and split the company in half to form the successful ground(ctrl). BKWLD's music sites prior to this were generally 100% Flash. ground(ctrl) has these same clients, but different technology. Expectations managed. It is not Adobe's responsibility to provide solutions for your clients, it's yours. If Adobe's corporate decisions aren't working out for you, move on to something that does.

"Javascript sucks, performance sucks[, I hate life]."

Hell yeah, it does (one could argue that the DOM sucks, not .js, but I digress), but so did ActionScript 1. Holy crap, did it suck. Look at ActionScript now; AS3 is easily my favorite language to write in to this day. Again, don't like JavaScript? Don't pursue it. Perhaps try a language that doesn't suck. Ruby. Python. C#. Objective-C. As a Flash and Flex developer, you can pick up any of these languages in a week or even a weekend. It's just syntax, right? Maybe even try Node.js!

Find some new stuff you like working with and offer those as solutions for your clients. For an example of this, how about following two Sean M's I know. Sean Monohan (@noobsarepeople2) is building a XNA-based game at the moment which has a Node.js backend and level editor. Guess what Sean does during the day? Flex developer. If Sean had to give up Flex completely today, I know he'd be happy to try other things. I know the guy just wants to make cool games, regardless of the technology. Having interests outside of his client work allows him that freedom. Sean McCracken (@seantron) is a Unity 3D development and also does iOS and Android development. He also works at Red Interactive (where I'd guess he does some Flash work here and there). Again, point is that you can apply all this Flash Platform knowledge to other pursuits. It's not giving up on Flash, it's just broadening your creative approach.

"Show me one good HTML5 app."

Facebook.com. Bigger than any enterprise app you've ever built, guaranteed. What is an HTML5 app anyway? Look at their doctype. <!DOCTYPE html>. Is this HTML5? Yes and no. Very little actual HTML5 markup, lots of modern web technologies used that we are now lumping under the HTML5 masthead. Point being, web technology that is not plug-in dependent. An application does not have to do what Flash can do to be successful.

"Adobe left us with no migration plan."

Learn new shit, and learn it now. Adding to your stable of product offers only increases your marketability. Adobe will eventually create some rad new tools for HTML and Javascript development (or they won't and they'll just keep adding one feature to Photoshop per year for the next decade...who knows...I know I'm planning for it) and we'll all be set for the next round of internet.

No one in their right mind will say that Adobe has a great history of PR and communication with its developer base. It's also a corporation. If you decide to put all your chips in with a single technology, you will eventually get burned. Tech moves too fast. But what have you learned in your many years of Flex and Flash dev? Personally, Flash gave me a unique way at looking at product development. Besides teaching me object oriented programming, the Flash Platform helped me learn asset management in a programming context, how to programmatically animate assets, and especially important, I feel, is a distinct separation of concerns between logic and visuals. As Joel Hooks (who happens to be one developer who makes me confident that Flash has a great future ahead of it) succinctly put it "your skill-set is not the Flash Platform"; it's creating rich interactive experiences. This overarching knowledge can easily be applied to other platforms and technologies. You should certainly continue to develop in Flash (I do, and I still love it), but diversify.

"I can't make Enterprise apps in HTML5."

This is just a cop-out to me. Unless your enterprise app is a asset-heavy game, video/streaming presentation software or something similar (the places where Flash excels according to Adobe), there's no reason you cannot build an incredibly successful HTML-based application. You can also likely charge more for it because it'll likely be inherently more difficult to produce.

"Adobe betrayed us."

Reality check: Adobe is a corporation. They will make business decisions that make sense (in theory) for them monetarily. As a developer, you've got to make tough decisions about which technologies to devote time learning. If you've been doing nothing but Flash development for the past decade, that is a huge gamble. One that probably paid off very well for you until late (I paid the bills as a Flash dev for close to 6 years). In this case, it's time to—as they say in finance—diversify your portfolio. Risk management and reduction.

New Standards

In Adobe's press release, they state that Flash "has repeatedly served as a blueprint for standardizing new technologies in HTML." This could not be more true, and will, of course, continue to be true. Flash is incredibly powerful; the majority of the cool functionality we are now seeing being recreated in modern "web" technologies all have roots in what Flash enabled us as creatives to do. Full screen, responsive, liquid layouts; effects; animation; video; et al. So what if HTML5 isn't perfect yet; the technology will move faster than any individual can learn it, so it won't take long (just compare Flash 4 to Flash 8) to catch up.

Spoon

Looks like the open-source foundation that will be taking over the Flex SDK is Spoon.as. And perhaps "taking over" is a misleading phrase; the SDK's development will still be lead by developers from the Flex SDK team; it just won't be backed by Adobe (seemingly).

Having a look at the people on the board of directors, it's clear to me that the Flex SDK will continue to be a viable platform for the foreseeable future. In fact, "removing" it from Adobe's clutches may be the best thing for it in the long run (less bureaucracy, more code, right?). Looking at something like the Robotlegs community/team, again, I'm confident that as long as the Flash Player itself continues to be developed, there'll be lots of room for Flex and AIR projects. Some clients and companies will start using more HTML5 technologies, but there'll be plenty that will settle—nay, opt—for the amazing capability of the Flash API internally and for Enterprise solutions. If you really want the Flex/Flash community to thrive, I'd imagine the best thing you can do is sign up to support Spoon.

My personal plan

1. Support Spoon.
2. Continue to let Adobe know that Flash is an important platform by using it to make kick-ass applications and games.
3. Support awesome projects like Robotlegs.
4. Use Flash where it makes sense and achieves client goals, and
5. Use HTML5 and supporting technologies with the same intent.

Thanks for reading. Hopefully you found these thoughts positive and useful. Please let me know if so.

Following my obsession with TextMate snippets and commands, I created a function snippet which extended the basic function and added a few new useful features. This snippet is mapped to Shift + Enter. Just type the name of your function...

myFunction

and hit Shift + Enter after it. The following snippet is inserted:

/**
 *
 *
 * @return
 */
public function myFunction()
{

}

The first tab stop is inside the parentheses so you can add some parameters, hit tab again to focus on the scope (public). We use a simple regular expression here to add "_" or "__" to the method name depending on if you type public|private|protected. The rest of the tabs go through the return statement, docblock and finally end inside the function declaration.

I've got both an AS3 and PHP version. Starting with the PHP version:

cat <<SNIPPET
/**
 * $4
 *
 * @return $3
 */
${2:public} function ${2/(private)|(protected)|(.+)/(?1:__)(?2:_)(?3:)/}${TM_SELECTED_TEXT:-$TM_CURRENT_WORD}($1)
{
	$0
}
SNIPPET

And the AS3 version is basically the same with just a return type defined:

cat <<SNIPPET
/**
 * $4
 *
 * @return ${5:$2}
 */
${3:public} function ${3/(private)|(protected)|(.+)/(?1:__)(?2:_)(?3:)/}${TM_SELECTED_TEXT:-$TM_CURRENT_WORD}($1):${2:void}
{
	$0${2/void$|(.+)/(?1:return null;)/}
}
SNIPPET

I'd also like to eventually add @param docs to the docblock as you type out parameters. Would love some suggestions there.

You can download both the PHP and AS3 Function Commands here. You can also download my TextMate theme Plum Dumb, or—if you're into PureMVC—you can download my PureMVC TextMate templates.

Working on the 1.1 release of Cee-lo today I ran into a task where I needed to position a button underneath a text field. I wanted said button to be positioned relative to the height of the text field. In Actionscript, this task is easy:

theButton.y = theTextField.y + theTextField.textHeight;

+1 abstracted language, no? In objective-c/iOS SDK, the task is slightly more complex. Especially when the UILabel's font size is set to auto adjust (adjustsFontSizeToFitWidth) based on the width of the text field. Here's the working solution below. In this example, the username field on Cee-lo's winner screen is set and the rematch button is positioned under the UILabel based on the text height of the username field. The max font size for the field is 36 and the minimum is 12.

- (void)setUsernameText:(NSString *)theText
{
    // assign the text to the username field
    self.username.text = theText;

    // actualFontSize accepts a pointer to a CGFloat, so define that here
    CGFloat fontSize;

    // determine the size of the field if we were to show theText
    // in it at the original size
    CGSize size = [theText sizeWithFont:self.username.font 
                            minFontSize:12.0f 
                         actualFontSize:&fontSize 
                               forWidth:self.username.frame.size.width
                          lineBreakMode:self.username.lineBreakMode];
    // so at this point, size is a frame that defines the bounds
    // of the textfield if it were rendered at 36 pt. But now, by reference, fontSize
    // contains the actual size of the text field's font after resizing. 
    // So we use that size to determine how big the field would be
    // with that font size:
    CGSize computed = [theText sizeWithFont:[UIFont fontWithName:HelveticaNeueBold size:fontSize]];

    // position the rematch button under the text field
    self.rematch.frame = CGRectMake(20.0f, self.username.frame.origin.y + computed.height + 5, self.rematch.frame.size.width, self.rematch.frame.size.height);
}

Using ASDoc with a codebase library can be a real pain. Use Tweener in your classes? Papervision? Anything from the fl.* packages? You don't want to include all of that in your documentation. ASDoc provides a flag exclude-dependencies. That's fantastic but it doesn't play nice with the doc-sources command which accepts a path/package as a parameter for what you want to document. This means that you have to use the doc-classes param – and list every single class you want to document. Well, I have about 130 classes in my library, so that's a bit of a pain. Enter the AIR app DITA. Dita gives you a GUI for selecting ASDoc paths and then spits out a asdoc.sh (shell script) that lists all your classes in the target path. Here's my final bash script for generating my documentation (note that I've removed the big class list and some other options for brevity):

#!/usr/bin/env bash
asdoc 
    -source-path ./src 
    -doc-classes typeoneerror.utils.StageManager 
    -external-library-path ./lib 
    -package typeoneerror.buttons "Contains abstract button implementations" 
    -exclude-dependencies=true 
    -main-title "Typeoneerror Documentation" 
    -window-title "Typeoneerror Documentation" 
    -footer "Copyright Typeoneerror Studios" 
    -output docs 
    -warnings=false 
    -strict=false 
    -show-binding-warnings=false 
    -show-actionscript-warnings=false