Bay New Media

So it’s come to this

Adobe, Flash, Flex / Flash Builder, HTML / CSS, JavaScript, Mobile No Responses »

Mar 292012

I attended FlashInTO last night. The event bills itself as a “Toronto Flash User Group”, a monthly gathering of anyone interested in Adobe Flash and related technologies. I hadn’t attended in well over a year because the turnouts were becoming depressingly low, probably due to the previous subterranean location in Kensington Market, the regular mid-week date, and the exclusive availability of overpriced bottled beer and very little in the way of anything else.

Still, I thought, I’d give it another try – schmooze a bit, maybe chat about SocialCastr, and just see what was happening out there in the world of Flash and AIR. After all, Adobe recently released its roadmap for the Flash runtime, and just a couple of days ago announced even more news surrounding upcoming features and new pricing models. If anything, one might think that such topics would at the very least have been brought up at some point during the evening.

Well, one would be wrong. In fact, the entire evening was dominated by topics such as Unity, and HTML5, and ending with shameless Apple love-in with literally not one mention of Flash. At all.

The “Emerging technologies in the real world” topic was interesting enough, with Demi Kandylis describing how his company used Unity to produce an interactive shadow puppet display for Sapporo, the Japanese beer maker. Demi’s team happened to use Unity, a 3D engine that can also be used to output to Flash, which could have become an interesting launchpad to at least mention some of the interesting work being done with Flash and 3D. But no mention of Flash, of course. Not even a hint.

The next presentation was part of what I see as the ongoing, and frankly insane push to get everyone to develop in HTML5. Here, Ken Peleshok demonstrated Adobe Edge, now in its 5th version and still able to perform only basic animations of the kind that Flash was capable of 15 years ago. The demonstration was pretty much a failure as Ken couldn’t get basic animations going with his code, but there was plenty of Apple-wielding supporters standing to the side exclaiming, “just you wait!” There was certainly enough opportunity to at least draw parallels to Flash animation, but of course that was never brought up. But why would anyone want to discuss Flash at an event called FlashInTO?!

I had to walk out on the final panel discussion because it turned into one of the most disgustingly overt Apple advertisements I’d ever witnessed, not to mention the conclusions that the panelists came to. The Apple logo featured prominently in every slide along with the panelists’ children, and everyone took the opportunity to casually wave around their iPads, Macs, or whatever piece of Apple hardware they were carrying to show that, yes, they were just the coolest people ever and could be trusted to deliver unbiased and reasoned opinions. Simon Conlin, the founder of FlashInTO (and later Flash In The Can…see below), started off by saying, “This isn’t supposed to be an advertisement for Apple or anything…”, and then motioned to the front of his laptop with the glowing Apple logo just to drive the point home before starting the accompanying slide show of panelists’ kids brandishing Apple hardware, often with the company’s logo as the primary focus and the kids in the corner of the images. Most of the time the kids weren’t in the picture at all, it was just photos of iPads, iPhones, and other iDevices.

Despite this end-of-night panel being billed as “A look at apps for kids, what’s good, what’s bad and much more”, there was literally one app that was shown while the discussion centered entirely around the “brilliance” of Apple’s marketing and design. And once again, not even a passing mention of Flash, Flash Builder, Catalyst, or any of the other Flash-related products that could easily have been incorporated into the discussion. Even Adobe wasn’t mentioned…it was a complete Apple circle jerk.

Believe it or not, though, the couple of overpriced pints I had downed allowed me to stomach things up until that point; it was only when the conversation turned to, “What the youth of today can teach us” that I packed it in. Once again with all attention on how Apple was genius for doing so, the panel began discussing how we, as software developers, should be tailoring our apps towards infants. After all, kids are completely uninhibited and have no preconceived notions about interacting with hardware or software, and so we should all be striving to dumb down our own products and make them as basic and infantile as possible. That way everyone could use what we produce without any real learning curve or impediments. And wouldn’t it be a good idea to cripple device functionality through our software to ensure that people only use our software when, how, why, and where we want them to?

I was this close to standing up and reminding them how their device-weaned spawn don’t have the wherewithal to keep their hands off of hot stoves or not run out into traffic (maybe that’swhy adults think for a few moments before adorably mashing $800 devices with ball-peen hammers), but it was clear that they were really only into publicly masturbating to Apple propaganda and rhetoric. When, at some point in the past I’d mentioned that Applites offer up their firstborn to Steve Jobs, I thought I was only exaggerating – clearly I was wrong.

And just to drive home the point of the evening, a draw was held for tickets to this year’s FITC. That’s Flash In The Can, if you’ve never been. I haven’t, mostly because the tickets are ridiculously priced, and partially because even when I might’ve had a chance to attend, people who had deigned to call me their friend ended up attending, on free tickets, with other “friends” who had absolutely no interest in Flash, and without even mentioning the event until I found out about it accidentally afterwards. And that the FITC was held directly across from the street where I worked at the time just helped to drive that screw in a little deeper. Then there was the childish crap they pulled and subsequently tried to cover up using threats and intimidation, that just completed the picture of what kinds of people self-avowed Applites really are. Not all, of course – you may have an iDevice right now — but be aware that going down the Apple path almost always invariably ends up leading out of the asshole of one thing or another.

But while FITC of the past was actually about Flash, look at the lineup of topics for this year’s FLASH In The Can: HTML5 • Online Video • Kinect Hacking • Javascript • OOP • WebGL • OpenFrameworks. • CSS3 • Starling • jQuery • Flash Stage 3D • Augmented Reality • Digital Art • Robotlegs 2.0 + much more!
Out of the 80 or so presentations, five mention Flash. And these are: “Deep Dive in the Flash Platform Roadmap”, “Flash and HTML5″, “Moving Forward with Flash (or Not?)”, “OpenFrameworks 101 for Flash Developers”, “Tangled: HTML5 <video> and Flash”. In effect, that’s one presentation on the Flash Platform Roadmap I’d mentioned earlier, one presentation for beginner Flash developers, and three about how you should be abandoning Flash for HTML5 hype.

And just in case you had any doubt about their dedication to Flash, the only Flash element on the FITC website is the banner, FlashInTO has no Flash elements whatsoever.

Yeah, this is what things have come to. The word “ridiculous” doesn’t even begin to cover it, and although I tried not to make this into an Apple-bashing post, it’s unavoidable considering how it’s flaunted in everyone’s face so openly and readily; exclusively, even. And I can’t help but wonder when it’ll stop. What will it take for people to notice this insanity?

Hooking up with Android

AIR, Flash, Flex / Flash Builder, Mobile No Responses »

Jan 062012

About a month ago my poor Samsung Blackjack II finally bit the dust. The jog wheel would no longer scroll or click downward, making even simple tasks nearly impossible. Shortly thereafter the ringer died and remained permanently on silent mode, despite the fact that all the other audio functions worked just fine — calls were missed left, right and center. Finally my cat had decided to chew through the charging cable yet again, pretty much driving the final nail into my trusty sidekick’s coffin.

The fact that the Blackjack ran Windows Mobile, albeit an early version, was a great advantage as it allowed me to easily integrate it with Outlook, Google Mail / Calendar, and my office Exchange server. Yes, I actually used my phone for more than making calls and playing Angry Birds. And it apparently supported Flash Lite, though for the life of me I couldn’t figure out how to install it let alone get any Flash content running on it. But it’s been years since I’d had to replace my phone so I was looking forward to getting into something newer. Android fit the bill quite well.

I settled on the Google Nexus S, initially released in December 2010 and sporting the latest (at that time), version of Android (2.3, AKA “Gingerbread”). I must admit that I’m not crazy about the smallish on-screen keyboard of these newfangled phones but everything else about the device appeals to me — multi-touch, voice search, email and social networking of every ilk, just about every type of wireless connectivity out there, and, oh yeah, Adobe Flash and AIR!

Okay, yeah, it was mostly the Flash / AIR support that got me most giddy. In fact, it was my own Flash site that I had a look at first to see about performance, compatibility, and all that kinda stuff. And I wasn’t disappointed. Both the Flash player and Adobe AIR currently feature prominently in the Android Market which, if you’ve never owned a similar device, is basically just a trusted download location for Android apps. You’re free to download and install non-Market apps mind you, unlike another phone manufacturer, except that you get a warning saying that the app may be insecure. Fair enough … at least I have a choice!

Android is a pretty easy operating system to get used to. Most features on screen are accessible through a poke, a swipe, a multi-touch, or a longhold (press and hold). The main screen is nicely customizable, allowing installation of widgets (little applications that run on screen at all times), icons, folders, and shortcuts. It also comes with a bunch of other bells and whistles that AIR can make use of like an accelerometer (motion sensor), assisted GPS (geolocation using both GPS and cell tower/wi-fi triangulation), front and rear facing cameras, GPU-accelerated 3D graphics, and support for full screen H.264 playback. Basically, it’s at the leading edge of what’s supported by AIR. I also have an application in the works that lends itself very well to mobile, so this little gizmo couldn’t have come around at a better time.

So what’s it like to develop AIR applications on Android? Well, I can only speak from the Windows perspective, but in this regard I can say it’s exceedingly easy and accessible.

For starters, getting into the Android Market costs about $25, a far cry from the $99 you have to pay some other company before you can even begin thinking about coding for their devices. And, of course, you can bypass the Market entirely and just plunk apps onto the phone willy nilly if you’re so inclined.

Setting up the development environment is fairly straightforward. First, you plug your Android phone into your computer and have some drivers automatically installed to allow you to use it like a USB drive. One part of the installation typically fails, the part where Windows tries to find the driver to allow you to establish a debugging connection to the phone. This is essentially a special USB communication channel that allows the desktop to install and manage the phone through the cable and also provides bi-directional debugging communication to the host application.

Google provide their own driver for this purpose while other OEM Android device makers have their own. With the SDK and associated USB driver downloaded and installed, you only need to go to the device manager, find the unrecognized device, and update its driver using the instructions provided by Google. Okay, I know, it seems like a bit of a hassle, but for most developers this will all take roughly 5 minutes the first time around. The second time I was able to do it in roughly 30 seconds. In fact, it’s the SDK download that takes the most time out of the whole thing.

I’m sure that it’s possible to install AIR applications using the SDK’s command line tools, but Flash CS 5.5 automates the whole process so I’d recommend using that for easy development. How easy, you ask? Is “click on publish” easy enough for you? Yeah, with publish settings set to “AIR for Android”, it’s as easy as ALT-SHIFT-F12 to start the application right on the connected phone. I was actually a bit shocked at how simple the process was and how my application just worked without many changes. Of course you’ll need to change dimensions if you’ve written a desktop or web app, and you might need to optimize some of the code and graphics for the 1GHz processor, but other than that your AIR application will run pretty much as is.

Okay, now I know what you’re thinking — didn’t Adobe drop support for future versions of Flash for Android? Yup. But it’s hardly the end of the line.

For starters, the last version of Flash for mobile is 11.1 — the creamy cutting edge offering all the latest and greatest of the Flash platform. I suppose that in a few years I may have an idea for a web application that Flash 11.1 can’t handle, but so far I don’t see that in the tea leaves. Also, it’s not as if Flash is being tossed into the trash — it’s being given over to mobile partners so they can develop and tailor the player to their own needs. True, it’s not a guarantee that we’ll be seeing Flash on mobile forever, and it may lead to unpleasant segmentation where each vendor has a slightly different implementation of Flash, but keep in mind that Adobe re-affirmed its commitment to AIR on mobile. And as most Flash / Flex developers know, AIR is nothing more than Flash with extended functionality wrapped around it. And this extended functionality comes with a WebKit browser built in (think Chrome or Safari). And this integrated WebKit browser can load Flash content. See where I’m going with this?

I would, in fact, hasten to say that with Adobe dropping Flash support on mobile, it creates a slew of new opportunities for developers to get in there and fill up the vacuum. So if you’re a Flash or Flex developer and you’re a little jittery with Adobe’s latest announcements, just take a deep breath and relax — this is not the end.

JavaScript H.264 decoder

JavaScript, Video No Responses »

Jan 052012

Well, it’s a good first try, I’ll give ‘em that. However, those claiming that JavaScript is fast enough to decode video in real time really should have a gander Michael Bebenita’s JavaScript H.264 decoder.

The claim is that with this software decoder, it’s possible to reach frame rates approaching 30 frames per second. On my quad-core, 8GB development machine, I found that performance didn’t nearly live up to the hype:

The JavaScript H.264 decoder, not quite 30 FPS

Of course, where there are claims of speed, there are also claims of miraculously minimal resource consumption. And as with most JavaScript / HTML claims, these are mostly a load of unadulterated bull.

Here’s FireFox just sitting there and doing nothing (baseline measurement):

…and here’s the above JavaScript application playing back silent video (audio decoding doesn’t exist):

I’ll admit that 13% CPU usage is not too shabby for JavaScript. And the 125 Megabytes of additional overhead are not outlandish. Basically, kudos to Michael for an impressive demo!

But consider that, as mentioned, there’s no audio playback, the video is extremely choppy at around 9 frames per second, and when you compare it to the Flash Player running in a browser (as standalone or within AIR it’s much faster), playing the same video including audio barely registers:

On his blog post Michael mentions that these are early days yet, so I won’t be too critical. And yes, Michael’s assertions that JavaScript has been greatly improved over the last few years are true — decoding video in real time is pretty amazing despite the problems. However, keep this comparison in mind the next time you’re thinking of starting a CPU-heavy web project, and feel free to point out my posts to anyone claiming that JavaScript and HTML are the “superior” option.

RTMFP explained

ActionScript, Adobe, AIR, Flash, Flex / Flash Builder, Video No Responses »

Jan 042012

Although the presentation below was given over 3 years ago, we’re only just now beginning to see the emergence of RTMFP-based, peer to peer applications. Chatroulette was one of the first to break through to a mass audience, and recent applications like Sendoid have been described as “game changers”. In other words, the protocol has been around long enough now where it’s proven its reliability, and it’s had a few flashes of brilliance that demonstrate that it’s not only viable but also ready for prime time.

If you’re a Flash developer, interested in peer to peer networking technologies, or just want a peek at the low-level functionality of the next big thing, here’s the Adobe Max 2009 presentation by Matthew Kaufman, one of the guys that came up with RTMFP.

“Publish All Open Files” Flash Extension

ActionScript, Adobe, Flash 2 Responses »

Oct 252011

As I was going through the laborious process of exporting all of the FLAs of my project this morning I realized that I could easily write an extension for Flash to automate it for me. The resulting JSFL script works well enough that I made an extension out of it.

You can download it here: http://baynewmedia.com/download/Publish_All_Open_Files.mxp

Once you have it downloaded, install it with the Adobe Extension Manager or just double click the file if you already have the manager installed.

Here’s how the script works:

All FLAs open in the Flash IDE are saved (you may be asked if you want to save your changes for each file if any have been made).
All the open FLAs are then published except the main FLA. If no main FLA is designated, all the files are published and the script finishes.
Finally, the main FLA is executed (like using the “Control -> Test Movie” command in the Flash IDE).

Essentially what this allows the developer to do is to publish all supporting SWFs that may be needed for a project and then execute the main project SWF at the end. This means that prior to running the script you should open all the project FLAs that need to be exported, and close any files you don’t need to publish.

Defining the main FLA

Only one of your open FLAs should be designated as the main one. The script will work even if you define more than one main FLA but it won’t be able to distinguish between them and may execute the wrong one.

Defining the main FLA is very simple. Simply go to the main (root), timeline of the main scene of the FLA and select the first frame. Add a frame comment that reads “main” (note: this must be a comment, not a frame label!)

There are two ways to ensure that this is a comment and not a label. The first is simply to stick two forward slashes before the text like this: “//main“. Alternately, the “Properties” inspector has a combo box that allows you to switch between a frame label and a comment — it automatically sticks the slashes in front of any text that’s supposed to be a comment.

And that’s it! Now when you run the script, this file will be launched after all the other open FLAs have been published.

Running the script

You can find the installed command in “Commands -> Publish All Open Files”. Click on this and the script takes care of itself after that.

Okay, I know, nothing earth-shattering, but I hope that at least it saves you a little bit of time in your daily work flow.

Reference Error #1056

ActionScript, Adobe, AIR, Flash, Flex / Flash Builder No Responses »

Sep 272011

I’ve just spent the last day or so fighting with an ActionScript error and now that I’ve finally figured out what I was doing wrong I’d like to share the solution with you in case you’re pulling your hair out.

The error is:

ReferenceError:Error #1056: Cannot create property…

The property in question can be pretty much anything; a MovieClip, a XML object, a custom class, or as in my case, a TextField.

What made this error especially frustrating was that the TextField instance this error was referring to was on the stage in the Flash IDE. I wasn’t adding it using ActionScript and it was obviously present in the editor. Moreover, when I compiled the FLA and traced the TextField instance out, it existed! It was only when the exported SWF was loaded into the main project SWF that this error would appear, again, and again, and again, and again.

Well, it turns out the solution was a lot simpler than I thought: I had a copy of the same class (same name, same package), in another SWF that was being loaded.

To illustrate: Containing.swf was loading myMovie1.swf and myMovie2.swf, and both myMovie1 and myMovie2 contained an instance of MyClass. You may encounter this error even if the class is only being imported or included for export in the library — basically, any time it’s available for use in Flash memory. Whether this resulted in a namespace conflict or maybe just a load order precedence problem, the MyClass instance that I was trying to access in myMovie2 would always throw the error.

The solution ended up being incredibly simple: I simply deleted the extra instance I’d accidentally added to myMovie1 (I’d completely forgotten I’d added it), and the problem was instantly fixed!

However, in some cases you may want or need to keep class names the same between loading SWFs, and this will obviously produce the same problem. From the perspective of the Flash VM, it can be seen as “which class am I supposed to use?” In this case I’d recommend using a namespace to differentiate one of the classes from the other or, if that can’t be done, using a separate Application Domain for each loaded SWF to keep them both separate within the virtual machine. If you need to communicate between the loaded SWFs, you can then accomplish this using something like JavaScript, or a LocalConnection. Obviously this second solution isn’t the most elegant but it will work. In my experience, if speed of communication between loaded SWFs is important, using JavaScript is the better way as LocalConnection can be surprisingly slow.

I haven’t found a satisfactory answer to this issue on most online forums and even the ones that did attempt to fix the issue had explanations that didn’t make a whole lot of sense. Hope this one helps you!

Flash “dying” with Flash-based Muse

Adobe, AIR, Flash, HTML / CSS No Responses »

Sep 152011

Last week on my personal blog I wrote about how mainstream media, especially in the technology field, has been infiltrated by hacks producing nothing that would be recognized as responsible journalism. Not only are these writers not knowledgeable about the subjects they write about, they often produce work that is factually wrong and serves as simply gushing advertising. And if they’re not shilling products or services, they take the opportunity to falsely denigrate the competition. It’s the “falsely” part that I find most troubling.

The following recent article on the popular Cult of Mac website is an outstanding example of this:

With Flash dying, Adobe goes after iWeb with Muse

Before I get into why just the headline alone is wrong, I’d like to point out that the author, Killian Bell, is carried on a number of sites besides Cult of Mac, including TechnoBuffalo, iDownloadBlog, and Macsessed, all unsurprisingly Apple-oriented blogs.

I say unsurprisingly because I find this level of misinformation to be most pronounced when coming from Apple sites. At least that’s been my experience.

Judging by the Alexa numbers for these sites they, along with their authors, get lots of exposure. And like most sites spreading this type of propaganda, they get carried far and wide via additional partners like Business Insider and Techmeme which, together, likely account for a few million readers every month.

The crux of the problem is statements like this:

“Adobe’s increasing support for HTML5 seems to be a constant indication that the company is accepting the slow demise of Flash, but is this software, and Edge that launched on beta earlier this month, just going to speed up the process?”

Yeah, Adobe is accepting the demise of their flagship software. I know I’ve touched on this topic in the past, but in those instances the authors were simply making unproven statements, which would be bad enough. But in this case, not only does the author provide “evidence” of his claim by pointing to the new Adobe Muse, he takes the opportunity to remind us how this exact thing is the proof that, yes indeed, Flash is dying and this is how Adobe’s killing it off.

Of course, readers of my blog will probably have at least a passing familiarity with Adobe AIR, the desktop runtime that extends Flash. Very roughly put, AIR is Flash, and AIR is Flash. And guess what Muse is written in?

If there is any doubt, one only needs to look in the installed program directory to find the SWF file — a Flash file — that comprises the application.

To put it another way, the author asserts that Adobe is accepting the death of Flash while using Flash to produce the software used in the assertion. The absurdity of the statement is staggering; it’s like saying the new Microsoft Windows 8 is proof positive that Microsoft is getting rid of Windows. It’s hard for me to even write that with a straight face.

But apparently that didn’t stop any of the Cult of Mac-friendly sites from carrying the article without even a hint of fact checking, and I have no doubt that it will at some point become the basis for some other article pointing to “proof” that Adobe is killing off Flash.

Again and again I read the same thing being pushed out by mainstream media and being re-printed and quoted whenever anyone wants to back up any sort of baseless statement. It’s become epidemic and a very dangerous precedent; if so few “professionals” are questioning the veracity of these statements, how many non-professionals will?

It’s incumbent on knowledgeable technologists to set the facts straight. You don’t have to agree, but you do need to base your opinions on facts at the very least. And whenever you see people pulling information out of their asses like Killian did with his article, it’s important that you stand up and set the facts straight, because when truth starts to get swept under the rug, bad things tend to start happening.

Okay, that being said, I should take the opportunity to actually say a few things about Muse. Factual things.

First off, it’s pretty good! It’s not exactly Dreamweaver in terms of sheer power, but as a way to produce free-form HTML-based sites without touching code it works well.

Newer web features like CSS3 and HTML 5 feature prominently in Muse. The main feature buttons pretty much spell out what makes Muse different from something like Dreamweaver:

Each project has a “Plan” stage where you decide how individual pages are related to each other, a “Design” stage where you actually create the pages, a “Preview” stage that allows you to see your work in the built-in preview window (probably AIR’s WebKit-based browser), and finally the “Publish” stage where you upload your work to Adobe’s hosted Business Catalyst servers.

Some early reviewers have been bitching about Adobe’s $180 per year (or $15 per month) hosting cost — that’s the initial price anyways — but you can always just export your project to individual HTML files / folders and upload them to your own host.

One of the interesting things about Muse is its way of handling installed fonts. Unlike Edge which limits designers to only web-safe fonts, Muse allows you to use any installed font from your system by converting the text to a PNG and including it as an inline image in the output web page.

While this is entirely a guess, I believe PNGs are used because of their transparency support, something that would make sense in layered compositions.

Muse also has nice round-trip integration with other Adobe products like Photoshop so that you can insert raw (being edited) media from these other programs and then go back and forth between them and Muse, keeping both updated with the changes.

Another useful feature of Muse includes the ability to insert special objects like menus, lists and various types of content panels, compositions (combinations of interactive elements), and image slideshows. Pretty much everything is free-form so you can plunk it anywhere on the page you want.

What Muse demonstrates is how much HTML has evolved in being able to freely lay stuff out on pages. It’s certainly fair to say that, in terms of design, HTML 5 can now readily compete with Flash. And what Muse also demonstrates is just how powerful Flash and AIR really are, that they can be used to generate content that’s repeatedly claimed surpasses them. Of course this second statement is a load of baloney and Muse is living proof of this. No, Flash isn’t dying, it’s alive and well and propping up the very thing that’s supposed to be killing it.

The wheretos and whyfors of Adobe AIR Launchpad

ActionScript, Adobe, AIR, Flex / Flash Builder No Responses »

Sep 092011

I’ve been holding off writing about the AIR Launchpad application currently available on Adobe Labs because of one simple question that’s been bugging me: What’s the point of this thing?

Adobe describes it as an application to help Flex / Flash Builder developers get “started building desktop and mobile applications (iOS, Android, BlackBerry PlayBook) deployed on Adobe AIR”. Okay, I thought, but is that really something that’s tough to do? Does it offer any advantages?

It wasn’t until I sat down and played with it for a few minutes that I though, hmm, yeah, I can see this being kinda useful — it can save you some time and potentially some headaches.

For starters, I might update the Launchpad description to read, “Helps you to generate generic application shells that include commonly-used functionality.” That’s because, well, it’s what Launchpad does. In other words, you could do all of this yourself inside of something like Flash Builder but it requires you to set up a bunch of stuff, create some initial classes and a bunch of imports, etc. etc. As with most things I write about, not impossible, but Launchpad just automates it all for you.

The main screen has two options: Desktop applications and Mobile applications.

The desktop options include things like the dimensions of the initial application window, the chrome (window style) you want to use, and the option of various standard ActionScript classes that you can include depending on what kinds of app you want to write (networking, file access, etc.).

Most of these things are check boxes so the whole process is pretty quick — no mucking about with XML or manifest files. When you’re done, Launchpad produces a ZIP file with all of the necessary project files and directories, all nice and tidy and set up for direct import into Flash Builder.

On the mobile front you have the option of selecting which mobile OSes you want to target (Android, iOS, and Blackberry), since each of them has different packagers and installers.

As with the desktop options, you get to pick some of the most common ActionScript libraries you want to include with the project(s), but the project dimensions and other display options are fixed since you’re dealing with the limited real estate of mobile phones. There are also a mobile-specific options such as “Auto-Orient Screen” and “Install Location” (internal or SD card), that you might overlook if you haven’t done much mobile coding.

As with desktop projects, a ZIP file is produced that can then be imported into Flash Builder and then built.

Launchpad is a useful little application after all, and there’s kind of a poetic cyclical beauty about the fact that it’s an AIR application that’s used to create other AIR applications. It’s entirely free and doesn’t show any sign of being a time-limited demo, so I’d recommend downloading it and giving it a whirl. Yeah, it’s a good idea to learn to create projects from scratch by hand, but after that, why waste your time?

Adobe Edge 2 Preview and the empty promises of HTML 5

Adobe, Flash, HTML / CSS, JavaScript 1 Response »

Sep 082011

When Adobe released its second preview release of Adobe Edge yesterday I thought I really should give this “Flash killer” a try.

After all, with headlines like these, maybe this Edge thing really is something to be reckoned with:

“Edge Keeps Adobe Relevant In A World Without Flash” (PCWorld)

“Adobe’s Edge HTML5 Web Tool Blazes a Trail To The Post-Flash Internet” (Fast Company)

“Flash Alternative: Adobe Previews Edge HTML5 Software” (InformationWeek)

“Adobe’s New Product Shows There’s Life Beyond Flash” (AdWeek)

“Adobe previews Flash alternative Edge – Flash may be on its last legs” (ITPro)

Wow! According to the mainstream hype, Adobe’s betting the bank on Edge and tossing Flash into the trash. Why the hell did they build an entire frickin’ platform around Flash just to toss it out when HTML 5 came around?! What a waste.

Except, of course, it’s not true.

At all.

Magazines like Information Week, CNet, PCWorld, and others have writers who go so far into the realm of hyperbole that what they write can only be described, at best, as sheer ignorance and, at worst, as outright lies. If we’re to believe some of these hacks, Adobe is actually destroying its entire company because Steve Jobs didn’t like Flash on his iDevices and, well, that was just too much for them to take. Yup, Jobsie didn’t like our software — scrap everything, boys, we’re starting over!

Worse still, non-tech news pick up these “expert” sources and repeat this misinformation to the point where it becomes “common knowledge”, kind of like “Iraq has WMDs” or “FEMA handled the Hurricane Katrina disaster admirably”. Future prognosticators take this ball and run with it even further, making insane pronouncements that are based as much on thin air as the space between their ears. It’s one of the main reasons I’m starting my alternative blog at PatrickBay.ca; the “common knowledge” of the media and the monopolies they prop up needs to be challenged.

Still, I firmly believe that new technologies should be tried and tested – honestly – so that people get an accurate view of what’s out there. So I downloaded the Edge 2 Preview and had a gander.

Full disclosure time: I like Adobe. After all, I’m a Flash / Flash Builder / ActionScript developer, and this is the company that makes the ubiquitous virtual machine on which my code runs. I generally like their design tools and have come to appreciate the power and flexibility of software like Photoshop, Illustrator, and InDesign.

But not Edge.

It’s not that it’s necessarily bad, but for people to suggest that it could in any way replace Flash is absolutely absurd. Yes, I know this is still a preview version, but the way it’s being touted by the mainstream you’d think that Flash is basically ready to be junked now that HTML 5 exists.

Let me start with the good stuff in Edge:

It’s pretty simple to get HTML 5 animations set up. The interface is uncluttered and there aren’t many options, so figuring out the software isn’t tough. And getting something on the stage and animated is pretty straightforward, especially if you have experience working with timeline-based software like Flash or Premiere.
It works pretty well. I found the animations a bit jerky at times, but considerably better than some earlier efforts I’d seen with custom HTML / JavaScript implementations.
It really is WYSIWYG. Much like Flash, what you see in the authoring tool is what you’ll see in the browser. Most of the time.
It’s responsive. When I tried Microsoft’s Silverlight design tool many moons ago (when it was still called Sparkle), the performance on my machine was awful. It took ages to get anything done and the only thing I was able to produce with it at the end was frustration. Edge, in comparison, is nice and fluid.
The alignment guides are useful. Pretty standard fare for many design programs, but it’s still nice to have dynamic guidelines available to help you keep your elements clean.

That’s pretty much it. If I were to try to sing Edge’s praises any more I’d really be reaching. That’s because there are many things left to be desired:

Compatibility. I’ve been saying this for a long time, and sadly, HTML 5 hasn’t done anything to address cross-browser compatibility issues with both rendering and JavaScript. In fact, even Edge’s previews section warns that some samples “may not render properly on all devices”. I don’t blame Adobe for this, that’s just the way browser makers operate. I do, however, blame Steve Jobs for continually trumpeting HTML 5 “standards” as the pinnacle of the web; quite to the contrary, they’re not at all.
Font support. Laughable. Especially considering how Apple repeatedly states their fondness for fonts and stylish typography while simultaneously pushing for the mostly font-less HTML5.
Compare Edge’s available fonts:

To Flash’s partial font list:

Again, this is simply a restriction on HTML and has to do with what fonts are installed on all computers everywhere. Mostly. Most of the time. Of course you can always use Web Fonts, but these have their own set of compatibility issues.
Size. I’ve heard much hyperbolic bleating about Flash being “bloated” and “CPU hungry” and a “memory hog”, and HTML being “sleek” and “slim” when, once again, the exact opposite is true.
To demonstrate this, I created two near-identical animations, one in Flash, and one in Edge. The sizes of the collected files for the two projects speak for themselves.

The Edge project is 170 KB:

…and Flash, in comparison, is a mere 38 KB:

…and that’s the whole Flash project, including the HTML and JavaScript files needed to embed it on the page. The actual SWF file is a piddling 11 KB:

…and that also includes the embedded font being used in the animation!

Note that this doesn’t include any functionality or special effects, none of which Edge supports either directly or otherwise, and which can be added to Flash with only a few additional bytes of data added to the project size. Which brings me to my next points…
No functionality. Edge is useful for animations, and for creating the underlying JavaScript code to run those animations, but if you wanted to create web controls or anything that’s actually functional, you won’t be able to do it in Edge. Yes, that doesn’t preclude you from adding it later using some other software, just don’t expect to be able to write a web application in Edge.
No special effects. As Flash developers can probably tell you, adding nifty effects like drop shadows, bevels, or other custom Pixel Bender shader effects at runtime (programmatically, while the application is running), is a snap. In Edge these are not only not available programmatically, by they’re not available at all. Again, don’t blame Edge for this, it’s the fault of the “superior” HTML 5 that none of this is available to you.

And these are just a few of the areas where Edge falls flat, mostly under the weight of the hyperbole and empty promises of HTML 5.

But as I said, I’m not against Adobe and as a starter animation product Edge is okay, plus it helps to demonstrate some of the shortcomings of HTML 5 and JavaScript for anyone wanting to investigate these things. As I’ve been careful to note, there are plenty of areas where these two technologies can be used to great benefit, and I’m certainly not going to pronounce that just because it’s light years ahead, Flash is going to “kill” HTML 5 and JavaScript. I just wish that the witless writers and ignorant commenters who help to spread anti-Flash propaganda were able to do the same thing.

Coming soon to a computer near you: Flash 11 and AIR 3

ActionScript, Adobe, AIR, Apple, Firefox, Flash, Flex / Flash Builder, HTML / CSS, JavaScript 2 Responses »

Sep 062011

Since I last wrote about the latest versions of Flash and AIR to hit Adobe Labs, the company has been putting the finishing touches on both products and readying them for release.

Both are now in the RC, or “release candidate” stage where they’ll be green-lighted for the public unless something catches on fire or explodes.

Eager beavers can grab Flash 11.0.1.129 here: http://labs.adobe.com/technologies/flashplatformruntimes/flashplayer11/

…and AIR 3.0.0.3880 here: http://labs.adobe.com/technologies/flashplatformruntimes/air3/

As I’d mentioned in the previous post, there are some whopping additions to both runtimes, the most notable of which (to me), are full-on 64-bit support, and accelerated video and 3D rendering.

In addition, there are now also the useful “Native Extensions” libraries which are a sort of plugin system that’ll allow developers to use native code, stuff written specifically for the platform (Windows or OSX, for example). There’s a lengthy document detailing the steps for C developers to create ActionScript extensions which can then be packaged with AIR installers and used from ActionScript. You might ask what the point of this is? Well, imagine for a moment something that you might want to do that a native application can, but that AIR currently can’t. Well, with Native Extensions, you can! Of course you do kinda need to know how to code in C, but I’m sure you’ll agree that having access to the unabashed world of anything and everything under the sun is extremely handy.

Some additions for mobile have been made since my last post too, specifically access to both front and rear facing cameras (on devices that have them), background audio playback on iOS devices, access to either headset or external speaker for audio playback, and an Android-specific setting that allows developers to set the colour depth for their application (16 or 32 bit), through the application descriptor file. AIR can now also use native text input on mobile devices so that things like text magnification and various mobile text selection systems (each phone seems to have its own), can be used.

If, like me, you’ve been dabbling in Flash / AIR’s protocol stack lately then you’ll be pleased to note that Adobe has added support for TLS sockets, a low-level step up from SSL that is often used for creating VPN tunnels and other highly secure communications. As you may recall, I wasn’t sure if this would make its way into this release since it was one of the most buggy pieces of functionality being added, but I guess Adobe managed to address most of the issues and TLS is officially in. Also on the security front, encrypted local storage is now available on devices so that your mobile AIR apps can carry passwords, logins, and other sensitive data around without them being easily accessible.

Finally, I guess many developers have been asking if they’re allowed to package the AIR runtime with their applications. Previously this was allowed but you had to complete an agreement with Adobe and create your own native installer using something like InnoSetup. It was kind of a laborious process and Adobe left it up to you to severely screw up the installer if you weren’t careful.

With AIR 3, Adobe is providing support for something called “Captive Runtime” packaging which is a fancy way of saying that you can now include the AIR runtime along with your application all in one executable package. It’s kind of like including the Java runtime with a Java application, or the Microsoft Word Viewer with any Word document. Of course this adds some significant bloat to applications (the AIR runtime is currently at around 12 MB), but it’s a nice option to give folks who may not have AIR installed and are completely clueless about finding out if they do.

Unfortunately, captive runtimes can only be created on the platform for which they’re intended; you can only create a Windows installer from a Windows machine, OSX installer on OSX, and so on, but still useful if you ask me.

Anyhow, there you have it. Adobe’s moving pretty fast and seems to actually be responding to both developers’ and users’ requests. With the latest updates to Flash, especially with the native code execution stuff, we are entering into über-application territory where developers can build slick, responsive applications in a fraction of the time it used to take us, and with support for features that can make heads explode (in a good way, not in the Cheney way).

To back up my statements even further, I went to the trouble of demonstrating that, contrary to Apple’s continued bleating gibberish about Flash and AIR’s security and reliability, the two platforms are actually more secure than Apple’s Safari-based HTML and JavaScript engines or, in fact, any browser-based HTML / JavaScript applications out there (some fared much worse).

The results (using Secunia data) were:

Adobe Flash Player security issues: 73
Average browser security issues (HTML and JavaScript): 237
Lowest browser security issues (Safari, HTML and JavaScript): 103

Yeah, of course Flash can always use more work, but it’s pretty solid when you consider the competition. So in the end, if you had any doubt that Flash and AIR are the shit, here’s your opportunity to suck it.

Older Entries