diyria

diyRIA – we build business apps

Category Archives: iphone

The AIR 2.6 SDK released — write once, deploy everywhere!…

adobe air logo… I hope!  I have my fingers crossed, oh sweet sweet AIR Team!

Actually, this post title should be, “How the Adobe AIR 2.6 SDK (and it’s iPhone Packager) could make my life more awesome, could make many developers’ lives easier, could make deploy-time (to multiple environments) faster, and could make for an environment where we have a TON more ‘apps’ out there.”  But that title seemed a bit excessive.

360|Flex in Denver will be here soon… I hope someone talks about the following:

“Write once, deploy everywhere.”

“Dude, the phrase is “Write once, RUN ANYWHERE.”

“Yeah yeah…. whatever.”  Regardless, of the exact phrase, it was THE phrase from a couple short decades ago. The advent of web browsers and the adaptation of javascript seemed to adhere to this little catchphrase (though more OS-centric devs would say Java was where this write once, run anywhere jive comes from). You could write a small amount of code and be next-to guaranteed, with very little work or support time, that your application would work on multiple devices and operating systems.


Let’s go back to the server-terminal environment.

HTML is very related to this WORA idea.  HTML was great and all, but it created an environment akin to computer networks designed decades prior when processing time was WAY more expensive and PCs were rare. Take, for example, the terminal-server model.  A server would do all the processing and the hardware in each of the terminals in the classroom (or at least in my MS-DOS class in High School) would consist of a monitor, keyboard and nic card.  The terminal was no more than a proxy to the processing beast at the front of the classroom.

old hotmail logo Now, think back to the first version of HoTMaiL (html-caps intended… anyone else use hotmail back then?!).  You, as a user, would log in to the site to check your mail, and the server would do a bunch server-side processing, running scripts and the like, to render an html web page.  In those early days of dynamic content, a majority (read: ‘next-to all’) of the heavy lifting was done by the server.  This heavy lifting was done for each page request, from every user.  I loved it at the time — the web was made of complete awesome.  But in terms of client processing vs. server processing it was sort of a step in the wrong direction. It was a step toward those days of the dummy terminal.

Two friends, Rich Crites and Brian Holmes wrote an awesome ColdFusion enterprise framework in the early 2000s was what I would call “ajax before ajax existed.”  The awesomeness of Rich’s and Brian’s cf framework (and also the awesomeness of that Ajax thing that became all the rave a couple of years later) could be directly attributed to the balance of the “system’s” processing.  The “system” number-crunching shifted away from the server and more of the processing would occur on the client-side.  Small requests would push small amounts of data back and forth between client and server.  The client-side application had all of the ‘View’ code.  If you clicked the ‘delete email’ button in this model, a small request with an emailID would hit the server, a result with something like “emailDeleted = true” would be returned, and the client would know to remove a row from the ‘inbox grid’ in the visual layout of the user’s inbox in the HTML page.  I’m simplifying and am not giving a completely accurate client/server (nor model/view) description of either ajax nor Rich’s old cf framework, but you get the picture.

So why all the blabbing about web architecture, terminals of yesteryear, servers, clients and Ajax?  Because these ‘apps’ that reside on our phones, tablets, computers, televisions, and random devices, [while a step in the right direction with regard to this semi-new client/server/processing paragigm,] CAN BE A NIGHTMARE FOR DEVELOPERS.  I heard recently that the development team for Angry Birds has (or had?) to manage nearly 50 codebases for all of the devices that they support for the game.  [I’ve also heard that Angry Birds 2.0 has been deployed to 90% of devices via Adobe AIR and a whole slew of conditional compiler args… can anyone back me up on that?!!!]

Today’s, most apps that exist for multiple devices and platforms (Pandora for example) the probability is very very high that multiple codebases exist for the different platforms that this application runs upon.

A number of projects try to solve this multi-platform multi-codebase issue.  The one I’ve heard the most about is Titanium Appcelerator.  It is one of the few phone frameworks that actually compiles your ONE codebase into multiple native executables for multiple (iPhone and Android) devices.  I’ve seen it in action, and the biggest pains (to me, a person who has been a full-time Flex Developer for the last 3+ years) == layouts and debugging.  Of those two, the more time consuming is the code required to create a layout.  The speed with which developers can roll the visual portion of the an application is very important. I and my co-workers are very efficient.  I am accustomed to writing hundreds or even thousands of lines of code and nearly completing an entire module or screen before compiling and figuring out where I messed up.  The reason?  I can SEE my layouts and understand them clearly when they’re in an XML-based file.  I don’t have to worry about the layout and I can spend my time writing business rules and the code that actually requires thought.  Doing layouts in an xml file feels so right, and it is SO fast to write.  Titanium Appcelerator is close. I think they have a layout issue to solve before I really make the plunge — but maybe I won’t ever have to make the plunge:

Enter Adobe AIR.

We have two issues when it comes to ‘app’ development for multiple platforms.  One: The client processing vs. server processing paradigm.  Two: Code maintainablility.  From what I can tell, the AIR 2.6 SDK leverages number two (more emphasis on client-side processing), while maintaining the awesomeness of one easy-to-maintain codebase.

I’m excited because I’m optimistic. My hope — from one codebase I will easily deploy to the desktop, web, and mobile devices.  Sure, I might need some conditional compiler blocks, but to have ONE OO language??…  Awesome!

You, as the developer, might have to over-abstract a few classes, or overuse polymorphism to tackle those device-centric issues, but you have one codebase!!  ONE MOTHER HUMPIN’ CODEBASE!  Some say this is exactly was HTML5 is all about, but how do you launch an HTML5 application without an internet connection?  How you deploy that HTML5 app to an android device — do you have an executable wrapper, like a browser, for your html app?  There are simply too many instances of my needing the application to work both WITH and WITHOUT an internet connection and to store data locally in the app.  Adobe did it right for enterprise application development.  HTML5 can’t yet solve many of these issues.

I can’t stress it enough.  If I have one repository locale and pull down one small project stack for an application that will install to multiple devices, I am a happy developer.  If I have that same repository location (or project stack) that will also deploy to the web, I am an even happier developer.  And if I use the same codebase and can build a desktop application in AIR, or even in a custom-built exe (flash projector-ish wrapper), I have EVERYTHING that any client might ever want, all in one location.  I am happy, effecient, lightweight, happy, inexpensive (that’s right… i’m cheap), happy, working three days a week and relaxing.  I might be sipping O’Dell IPAs or hanging out with the family more than I am now, all because of Adobe.  we’re talkin’ HAPPY TIMES (TIMES TEN)!

Adobe AIR Team, I will be sending you roses and chocolates if this process is as smooth as I hope it will be.