Posts Tagged ‘adobe’

Adobe & PhoneGap: Makes Sense, Mostly

Adobe Acquires Nitobi

So if you haven’t heard yet, Adobe acquired Nitobi, the company that is responsible for PhoneGap. This was announced at Adobe’s big MAX conference. If you are unfamiliar with PhoneGap, then this post is going to be wildly uninteresting to you. At a high level, they provide a cross platform mobile development solution that leverages native webviews with HTML5, CSS, and Javascript to create native mobile apps.

Not Hard To See Coming

Well, for one thing, Adobe was obviously hedging its bets on Flash/Air’s viability in the long term with mobile when they started introducing HTML5 capabilities through Edge. I mean, if Adobe’s planning to offer interactive, Flash-like development with HTML5, who is going to believe that Flash itself has a real future with mobile? Or as Gizmodo put it, Adobe Edge may become the beginning of the end for Flash. Yeah, it will likely always exist, but it is not the de facto standard for delivering interactive web (or mobile) content anymore.

And of course there’s the whole Adobe Air for mobile thing. Android was obliging enough to make Air a first class citizen. Install Air, run Air apps… simple. And while the Adobe Air install is a bit hefty, it’s hardly something worth worrying about with today’s storage capabilities on mobile devices.

“Flash has been labeled an outlaw and Air is smuggled in like an illegal immigrant”

The more harrowing journey for Adobe has been iOS. Basically, Flash has been labeled an outlaw and Air is smuggled in like an illegal immigrant. There’s been a staring contest between Adobe and Apple for a while now, but I think it’s safe to say Adobe blinked. Apple has continually proven that is has the most marketable mobile devices available, and has done so without any back pedaling on what they will and will not allow (minus letting 3rd parties build apps).

Something had to give if Adobe was going to get a real foothold in the mobile world, and it obviously wasn’t coming in the form of their current solutions. Enter PhoneGap…

But PhoneGap is not Without Its Challenges

Image by

PhoneGap fills a lot of holes for Adobe, but its going to need a lot of help itself. I think PhoneGap has gone about as far as it can on its own. It has achieved its goal of abstracting most native functionality for many different mobile platforms, but starting developers are wanting more.

PhoneGap has no user interface components. This is not fun for new developers… or veteran ones for that matter. You need to build everything from scratch or go out and find a UI framework that works for you. The 2 front-runners, Sencha Touch and jQuery Mobile, bring their own glitches and idiosyncrasies. Also, now you find yourself learning 2 frameworks that have a noticeable lack of cross-over documentation.

There’s also a seemingly purposeful lack of direction in terms of tooling and best practices. New developers, often web developers, are left to their own devices to find the workflow that works best for them. There’s no sanctioned IDE or set of tools suggested from PhoneGap to build your mobile apps. Infinite flexibility can be a real drag when you just want to know the most effective way to get things done.

But let’s put this even more plainly…

What are the pros and cons of PhoneGap?

Pros Cons
  • Terrific mobile platform compatibility
  • It’s an open, standards-based solution
  • Ease of entry for existing web developers
  • Large existing userbase for the above reason
  • No clear direction on UI, tooling, or best practices
  • performance is limited by webview
  • Platform disparities
  • Documentation is brief and sometimes lacking

And what are the pros and cons of Adobe?

Pros Cons
  • High quality tools for integrating development and design workflows
  • With Flash and Flex, they’ve been delivering visual and UI sugar for a long time now
  • They’ve been rocking interaction before was in diapers
  • They run nearly identical user experiences on each platform via Flash/Air
  • Their documentation is nothing if not expansive
  • A vehemently loyal community
  • Weak mobile platform compatibility. Android made Air a first class citizen, but we all know the story with iOS.
  • The majority of Adobe’s tools and SDKs are closed and proprietary
  • Has not seen a lot of fresh blood lured in by their current mobile development offerings
  • You gotta pick up AS3 if you want to be effective

Anyone else seeing a pretty clear yin-yang thing going on here?

So What Does It All Mean?

Well, for one thing, it means PhoneGap is becoming an Apache project. Yep, they are donating PhoneGap to Apache, which puts them one step closer to their altruistic goal of PhoneGap itself becoming obsolete. PhoneGap’s own Brian Leroux stated in his PhoneGap 1.0 presentation that:

“The purpose of PhoneGap is for PhoneGap to cease to exist”

Why, oh why, did Adobe buy it then? I think it’s because they want to be your one stop shop for purchasing IDEs, frameworks, professional services, etc… Adobe is likely banking on the ongoing popularity of PhoneGap and web-based native mobile development. “Web-based native”… sounds a little like an oxymoron, but whatever.

A Match Made in Heaven, Right?

Sounds like a perfect match. The 2 companies seem to complement each other very well. But…

There’s just a few questions I still have regarding the acquisition. Rather than drone on any longer inserting my own conjecture, I’ll just list my questions here and leave them as talking points for you, my readers.

“I can already hear the `It’s back to AS1` complaints starting…”

  • What happens to Flash/Air for mobile? It obviously won’t be forsaken, but this can’t sit real well with developers who have so far devoted themselves to this workflow.
  • How does Adobe deal with the inevitability that current developers will revolt against using Javascript? I can already hear the “It’s back to AS1″ complaints starting…
  • Does Adobe even have any interest in getting existing AS3 developers using PhoneGap? I know they are saying that they weill support both solutions, but come on, someone is gonna get more love than the other.
  • How long until we finally see a defined workflow and IDE for PhoneGap. Is Dreamweaver integration the best we get?
  • What will the PhoneGap guys do next? They are actively working to put themselves out of a job, so I’m curious what the next move is.

What’s Next?

I have no clue, but it’s sure to be interesting. I’m hoping for good things on both sides as it’s only going to make mobile development in general more exciting.

Will Adobe’s ability to create great tools translate to mobile success? Will PhoneGap’s strict adherence to the open web model jive well with Adobe’s history of closed, proprietary tools? Will the inevitable merge of the open web and existing Adobe community be a bumpy one?

Stay tuned…

Adobe Alchemy

Adobe Labs has a prerelease project called Alchemy, which allows you to compile C/C++ code into SWC libraries that are usable in your AS3 code. For a former C/C++ coder like myself, this is music to my ears, but those without that background might be wondering why the hell you would even bother. Well, there’s 2 major points to consider:

  • You’ll be able to use the existing mountains of C/C++ libraries in your AS3 without having to create a port.
  • To quote the Adobe Alchemy page:  (Its) ideally suited for computation-intensive use cases, such as audio/video transcoding, data manipulation, XML parsing, cryptographic functions or physics simulation, performance can be considerably faster than ActionScript 3.0…

Now before you go getting all excited to compile your favorite C/C++ library into an SWC, there are some things to consider:

  • The more OS and other library dependencies your compiling target has, the less likely it is to work.
  • This is a prerelease labs project, so expect bugs and lots of visits to the Alchemy forums.  This should probably not be used for production code.
  • Adobe has not made it clear whether or not they plan to continue development of Alchemy, or whether it will ever be rolled into an official release.

If that hasn’t scared you off I’d highly suggest going to the Alchemy project page to get your necessary downloads and then heading immediately to the “Getting Started” page to setup up your development environment.  See if you can get their basic stringecho.c program working.  Once you have built your environment and compiled your first SWC for use in your AS3 code, it’s time to actually build your own Alchemy version of a C/C++ library.  Here’s a few examples of libraries that have been successfully ported to AS3 via Alchemy:

aalib Ascii Art in Alchemy

aalib Ascii Art in Alchemy

Box2D Physics in Alchemy

Box2D Physics in Alchemy

Now remember how I said you would inevitably run into bugs?  Yeah, that’s gonna happen, it wasn’t just a maybe.  Well, here’s a list of bugs I’ve run into so far (in attempting to port IJG’s JPEG library) and what I had to do to work around them.  And by “work around them” I mean “what people on the Alchemy forums did to work around them.”

  • adl.exe stuck

    checking whether we are cross compiling... \
    $FLEX_HOME/bin/adl.exe c:\\cygwin/tmp/t35f0.0/app.xml \
    2> /tmp/adl.trace & echo $!

    Cygwin must installed at C:\cygwin because Swfbridge, which loads AIR apps on the fly during configure scripts, is hardcoded to reference C:\cygwin.

    If you are working on a Linux system and get a similar error, make sure that you can execute your $FLEX_HOME/bin/adl file successfully. The executable for the standard Flex 3.2 SDK does not include a valid Linux ADL, only Windows and Mac. For a Linux version, download the AIR SDK for Linux and use its ADL.

  • Bad regex in achack/gcc

    Compiler] Error #1084: Syntax error: expecting identifier before \
    leftbrace., Ln 1, Col 18:
        package cmodule. {

    Change line 274 of $ALCHEMY_HOME/achacks/gcc in the following way:

    #if($o =~ /([^\.]*)/)
    if($o =~ /([^\/\.]+)(\..*)*$/)

    or just replace $ALCHEMY_HOME/achacks/gcc with this fixed version.

  • Missing

    [Compiler] Error #1063: Unable to open file: \

    Don’t compile shared libraries, only static. You can usually set this in a configure script using “–enable-shared=no –enable-static=yes”. You can also pass the “-static” option to gcc directly when compiling.

That’s the list so far, but I’m sure there’ll be more. When all else fails, be sure to check the your /tmp directory for log files. I hope its saves anyone reading this a few hours as thats how long it took me to track these all down as an Alchemy noob. If you have the brains, guts, and patience to churn out an Alchemy port of a C/C++ library, leave a comment and let me know about it. Hopefully if enough of us do some real head turning work with it Adobe will actually put some serious effort into an actual supported release. Keep your fingers crossed.