I admit to having more than a soft spot for Adobe’s technology, but that’s not why I was so peeved when Steve Jobs made his much ballyhooed announcement that Flash on mobile was just the worst thing since Hitler.
For starters, much of Jobs’ characterization was just plain wrong. His problems with Flash not being “open” were gloriously misinformed as Adobe’s open source efforts, which included Flash and Flex, plus many of the video, audio, and networking technologies they contain, were already well established as open source technologies at that point.
Jobs’ insistence that HTML5 is a “standard” was equally incorrect, as the myriad of sites, services, and projects that have sprung up trying to either work around or at least document the many incompatibilities, quirks, and just old plain lack of support in the HTML5 “standard” attest to.
Jobs didn’t think Flash was needed to access video since HTML5 formats like H.264 (MP4) were so ubiquitous. On this point I’d have to agree, but that was never the sole reason that Flash became synonymous with online video. The reason Adobe’s player won out was because of a robust server architecture that, coupled with Adobe’s edge Content Delivery Networks, makes the technology a viable solution. Delivering MP4 streams over HTTP to browsers from a server farm is a lot more prohibitive, with cost being just one factor.
In his Flash critique, Jobs made the unsubstantiated claim that Flash was the number one reason why Macs crashed, a statement he never bothered to back up and which, as far as I know, was purely fictional or at best incredibly scape-goaty.
While Flash wasn’t a great mobile experience, mostly because it wasn’t set up to both deal with mobile gestures and co-exist on a web page, the same could be said of unresponsive or badly designed HTML5 sites. And whatever shortcomings the Flash player had, I’m sure they could have been addressed.
I’m not the only person to think that Flash was done away with unjustly. Amazon is trying to revive it for their devices, BlackBerry never lost it, and it Android can’t quite seem to shake itself of it. Judging by the popularity of the “How do I manually install Flash on my mobile device?” topic over at Adobe — 24.7 million views as of today– Flash is far from fading away.
The biggest injustice in this debacle, however, is the one I see being imposed on web developers.
Even something as basic as frame-based animation is only partially supported in most modern HTML5-capable browsers with most requiring reams of code and workarounds for “full compatibility”.
Rudimentary sound support, along with the same issues we were grappling with in Flash many years ago (synchronization, maximum mixing channels, etc.), has made it’s way into HTML5. Instantly, developers learned that the web “standard” wasn’t quite up living up to its name.
Companies too have learned that they prematurely jumped on the HTML5 bandwagon and have had to re-think their approaches.
But it’s not that HTML5 is terrible.
In fact, as devices get faster and capable of handling more complex code, the mobile browser will slowly evolve to become it’s own robust virtual machine, much as Java and the Flash player are now. Eventually, much of what is today erroneously called a “standard” will actually become one, mostly, give or take, across most browsers. But we’re not even close to getting there yet.
Still, now that I’ve had time to truly immerse myself in HTML5 and experience how it works across browsers and devices, I see the potential for a much improved web experience.
Up front, the only real improvements are in the tools available for expression — better ways to animate, addition of sound and audio, improved font handling, dynamic drawing APIs, and so on. This can all be put together to produce nice, expressive web sites and games, examples of which are more quite numerous these days. I’ve even done a couple myself. And it’s because of this exposure that I can’t recommend HTML5 for anything other than nice, expressive sites and somewhat basic interactive games. The so-called “standards” required for more demanding code are simply not up to snuff and are more often a hindrance than a help.
patrickb August 14th, 2014
Yeah, application frameworks are a dime a dozen these days. That’s why SwAG isn’t a framework but rather a toolkit — the Swiss Army Gear toolkit for ActionScript 3, to be exact.
As the name implies, this small-ish library contains useful code that can be employed wherever needed, as needed, without the full weight or presumptuousness of a full-on framework. In other words, it should be useful for you whether you have a project that’s well under way or are just starting out.
Because the library has lots of disparate features, I’ll be dedicating a number of future posts discussing them in detail and providing (hopefully) useful examples. Here is a brief preview:
Some of these are used extensively in SocialCastr and Araknid and they definitely made my life easier. SwAG doesn’t presume to be the only code running so adding it or removing it, mid-project or otherwise, is easy and straightforward. I’ve chosen to not include it in pure AS3 projects like TorAS or WRASE because they’re much more useful as autonomous libraries. Applications, however, are meant to be used rather than incorporated into other projects, so in those cases I happily stick SwAG into every nook and cranny.
SwAG had additional functionality which has been yanked since these make way more sense as individual projects:
I don’t know if / when I’ll get around to updating and publishing these but I’m not averse to sharing if you want to get in touch with me directly.
Otherwise, grab yourself a copy of the pretty-well-documented toolkit here: https://code.google.com/p/swag-as/source/browse/#svn%2Ftrunk
…and stay tuned for SwAG fun and frolic.
patrickb January 29th, 2014
As I mentioned earlier, accessing the Windows Registry tends to require Administrator privileges (via UAC) in many cases. The ActionScript library I wrote for this purpose, unfortunately, is no different.
In the previous version of WRASE, all Registry operations were done this way, which has many and obviously sucky connotations. To get around this, the users of your application could always disable UAC altogether, or there’s the option of running it in Administrator mode, but both solutions are less than ideal.
Luckily, there’s a third option.
But first, the bad news: most Windows Registry keys still require Administrator privileges to update. The only Windows Registry key tree that’s mostly update-able without Admin rights is “HKEY_CURRENT_USER“. I say mostly because there are sub-keys that are also inaccessible to non-Admin updates, usually because they’ve been created by other privileged processes or are in some other way locked.
The good news: almost all of the settings and information that you may need to have update access to is within “HKEY_CURRENT_USER”. Most other keys are still accessible as read-only, which makes sense once you start looking at what they contain. Also, if you really do need to update these keys, WRASE can do so by launching the registry editor with Admin rights as it did in the previous version.
To accommodate this I’ve made some changes to WRASE. The most notable include:
While making the recent spate of changes I learned that there are additional ways of accessing the Windows Registry that are more direct (“reg.exe” simply has more options than “regedit.exe”), which is extremely useful when accessing high-level keys. The current version of WRASE exports such keys and all their sub-keys which can produce massive amounts of data; usable in theory, but in practice not so much. This has elegant solutions but until someone complains I’d rather work on other projects, so please drop me a line if you are running into problems or need some improvements.
WRASE r5 is available for download here: https://code.google.com/p/wrase/source/browse/
patrickb January 29th, 2014
Posted In: Development / Coding
Since I spent time figuring out how to describe it on Google Code, I thought I’d rather post that than hurt my brain again. So here’s what Araknid does:
[Araknid is] An Adobe AIR application that crawls and archives web pages and assets such as images and scripts into a searchable/convertible SQLite database file. Use it to create a deep search index of your (or any other) site, your intranet, or even the whole web. Uses user-defined regular expressions to match and extrapolate links and other dynamic site information. Built on SwAG Toolkit ActionScript 3 application framework, user interface developed in Flash CS6 (.fla file). Dynamically supports latest versions of Adobe AIR on mobile.
Araknid is still quite new, meaning database interactions will need to be optimized, regular expressions will need to be tweaked, and some important features will need to be added (for example, crawl only under a specific URL or domain). But core functionality should be there, along with plenty of room for growth for anyone who wants to fiddle with the source code.
Here’s what you’ll see when you run the software…the legend is below:
1. Click here to select where the Araknis database (SQLite) will be stored. Once set, clicking here will open the SQLLite database file in the default application.
2. Pauses and unpauses any currently running crawl.
3. Opens the currently running crawl URL (#6) in a new browser window (if you’re curious to see what’s being crawled).
4. Variable crawl delay (in seconds). Prevents servers from flagging Araknid as an attacker or malware.
5. The percentage loaded of the currently running crawl URL (#6).
6. The currently running crawl URL. Pause Araknid, enter your own URL, and unpause to start a new crawl.
7. Countdown clock showing when the next crawl will happen (in seconds). Based on the crawl delay (#4).
8. A list of URLs extracted from the currently running crawl URL. These are added to the database (if not already crawled), and queued for subsequent crawls.
TIP: Rename or delete the database file to reset Araknid (like a new install).
ADVANCED TIP: You can update the regular expressions used to filter / extract URLs from various HTML tags. To do this:
1. Shut down Araknid.
2. Update the configuration XML file (config.xml) in the Araknid installation directory (for example, C:\Program Files (x86)\Araknid\config.xml).
3. Delete the Araknid application storage folder: C:\Users\[YOUR USER NAME]\AppData\Roaming\Araknid\Local Store
WARNING: This step resets your application settings (you’ll need to re-select the database file on next startup if you want to continue previous crawls).
4. On next restart, Araknid will use the new regular expressions for subsequent crawls.
All desktop operating systems:
Source code (ActionScript / Flash CS6 user interface):
…and something to view the resulting SQLite database:
patrickb January 21st, 2014
This TorAS thing is going to be a lengthy project — there’s still lots left to implement and older code to one day upgrade — but I received some great feedback about the appropriateness of communicating over Tor using unencrypted HTTP (it’s not very appropriate in many situations). So I’ve branched the current stable version and added TLS/SSL support (courtesy of as3crypto), in a development branch:
I’ll add it back into the main branch as soon as I get some time to document it fully, but the bulk of the new functionality has been covered in the updated Developers Guide:
I may also have added source code comments so have a peek.
TorAS ActionScript source code is made public under a liberal license (MIT), developed on open source technology (FlashDevelop), incorporating open source technology (Tor “Expert Bundle” binary , released under a similar license and spirit), and comes with a handy step-by-step guide. It’s most powerful on Windows (on account of the bundled Tor binary), but you should be able to use it on AIR for Android with something like Orbot (is there an official Tor router app for iOS?), and in fact anywhere AIR and Tor can run together.
patrickb January 21st, 2014