Thought Delimited

I'm not going to try and summarize the keynote:  you can either watch the replay at http://www.max.adobe.com/online/ or read a brief synopsis at http://max.adobe.com/news/2011/keynote_day1.html.

My first thought is actually about some news that wasn't part of the keynote, but was announced on the Internet during the keynote:  Adobe's acquisition of PhoneGap.  PhoneGap is an application framework that allows developers to build mobile apps using web technologies (HTML, CSS, and Javascript) and the PhoneGap API (to access particular device functions like geolocation, the camera, internal storage, etc) and then package and deploy those apps such that they work on most mobile operating systems (Android, IOS, Blackberry, and a few others).

What struck me about that news was that it means Adobe now provides two ways for app developers to develop cross-platform apps.  If a developer is already familiar with Flash and Flex development, they can build mobile apps using Flash Builder and Adobe AIR.  If the developer is more skilled with web design and programming, they can build apps using PhoneGap.  In both cases, the end result is an app that runs natively on your device of choice (IOS, Android, whatever).

First of all, it's yet another example of Adobe's willingness to support both Flash and HTML5 as development platforms going forward.  A number of tech analysts contend that Adobe's development of new tools that play nice with HTML5 is a capitulation of some kind to the way the industry is moving.  I don't see it that way: Adobe may be synonymous with Flash, but it's never been all about Flash with them.  They have always supplied the tools that the digital and web creation markets have demanded, just as any sane company would, regardless of what their internal preferences might be.

The other thing about the PhoneGap acquisition is that it will expand the number of developers using Adobe tools and technologies to create mobile apps for both Android and IOS.  And now suddenly Adobe potentially a big player in the smartphone and tablet space, not by release their own mobile OS or mobile hardware, but by providing the tools to any developer who wants to write on any and all of these platforms.  To be clear, at the moment there are certain kinds of apps or app functions that a developer would want or need to develop in native OS code, but as the Adobe tools provide ways to overcome those limitations (such as the ability to include native code extensions in Flash/AIR apps), the number of reasons for writing an app in native OS code (and hence writing a second version for deployment on another platform) are going to become fewer and fewer.

My second observation regarding the keynote concerns the suite of touch-optimized mobile apps - the Adobe Touch Apps - coming in November to Android devices and later to IOS devices.  While some of the apps are geared more towards visual designers, the Proto wireframing app is something I could use in the design phase of my web and mobile application work, and, well, who wouldn't want a touch-optimized version of Photoshop to use to mess around with their photos?

And that's when the thought occurred to me:  here were some apps that I could use to be productive with a tablet.  I'm an application developer who writes code.  I have access to two tablets and I don't use either of them to write code or generate digital content of any kind.  For me, tablets have always been digital consumption devices (something Amazon seems to recognize with their new Kindle Fire tablet) for viewing video, looking at pictures, or reading web pages or books, and kinda superfluous given I can do all that and much more with a laptop (to be clear, I do love my Nook Color as an e-reader, but I rarely use it to surf the web or anything else).

But the apps Adobe showed off today made me feel like I would in fact want to use them on a tablet, because they were designed specifically with tablets and touch-interaction in mind, not as desktop apps shrunk into a mobile form factor.  That to me is a step in the right direction, and it's apps like those that are going to grow the tablet market by making the tablet experience more compelling.

Zen Coding, in a nutshell, is a kind of coding shorthand primarily used to output HTML or XML code.  For example, the following line of Zen Coding:

div#page>ul>li*2>img.itemImg+a

...will produce this:

<div id="page">
	<ul>
		<li><img src="" alt="" class="itemImg" /><a href=""></a></li>
		<li><img src="" alt="" class="itemImg" /><a href=""></a></li>
	</ul>
</div>

If you compare the Zen Code to its output, you can see what the different parts of the Zen Code statement do. Assuming you know how you want to structure your HTML code, it's a pretty quick and easy way to generate the code you want with very little typing.

Having been recently reminded about Zen Coding, I decided to try out the latest version of the Zen Coding for Eclipse plugin and see if it would work in ColdFusion Builder 2.

The short answer: it does (and I imagine it works in CFEclipse as well). Once the plugin is installed, you can open your .cfm files in the regular editor window and use Zen Coding statements.

But then I discovered something I didn't expect: the Zen Coding plugin will convert even element names it doesn't recognize into matching start and end tags. In other words, even though it's not designed to be used with CFML tags, it can output them. Combine that fact with Zen Coding's support for adding attributes, and you can enter this line:

ul>cfloop[index=s][from=1][to=#ListLen(stateList)#]>li

...and hit the Tab key to get this:

<ul>
	<cfloop index="s" from="1" to="#ListLen(stateList)#">
		<li></li>
	</cfloop>
</ul>

...Maybe not the best real-world example, but it demonstrates the possibilities.  And the plugin lets you define your own shorthand abbreviations, so instead of typing "cfoutput[query]" to get "<cfoutput query=''>", you could define an abbreviation like "cfoutq" that will generate the same code.

I think this could be a cool way to write display code, and I'm looking forward to trying it out in real coding situations.

Update:  I totally overlooked the link on the Github page to the documentation for the current Zen Coding syntax:  http://code.google.com/p/zen-coding/wiki/ZenHTMLSelectorsEn

The other day I stumbled on a Make Use Of article about buzztouch, a "iPhone, iPad, Android app builder and content management system."  Since we're researching options for creating cross-platform mobile applications, and the article indictated that it was worth checking out, I decided to sign up and give buzztouch a spin.

buzztouch is designed to let non-programmers build a mobile app on the buzztouch website using a collection of web-based forms.  The app-building interface prompts you to create certain items, like a launcher icon for the app, a banner image for the home screen, and an "info" page for the app, but you choose what other content you wish to provide from a drop-down list of different components.  One component lets you create a screen of formatted text using CKEditor, while another lets you create an app screen using HTML, CSS, and Javascript.  There are components for pulling in remote content such as web pages, YouTube pages, streaming audio and video files, and RSS feeds.  One component lets you pinpoint one or more locations on a Google Map with brief location information that a user of the app can then use to get driving directions to those locations from their current position.  Even though I was casually playing with the system, I was able to create an app using several of these components in under two hours.

Once you've created the app, you can then download the native source code for the app:  you're provided with separated source code downloads for IOS and for Android.  The source code comes in a .zip file, which also contains a readme file with instructions on how to compile the source code for that particular platform and create the native app.  It only took me a few minutes to create an Android app from the source code, and it only took me that long because I had to provide a Google Maps API key to enable the mapping component I'd added (the readme provided exact instructions on the changes I need to make it the code to use the key).  I had my IOS developer colleague compile the IOS version of the app, and it was also smooth sailing for him.  The resulting app on the Android platform looked a little rough simply because of the generic design elements, but the IOS version looked pitch-perfect.

The first time you access any component or screen in the mobile app, there is a pause as the app retrieves the content or content instructions from buzztouch then caches it for local use.  This is where the content management system aspect of buzztouch kicks in:  any changes you make to the app on the buzztouch site get pushed to (or pulled by, not sure which) the mobile app.  So the app owner doesn't need to recompile and update the app through the App Store or the Android Market in order to make content changes.  If the mobile device doesn't have a network connection, then the cached content is used.

So what's my overall take on buzztouch?  I think that if you need to build a mostly informational mobile app, something that serves the same purpose as a mobile-optimized website, then buzztouch is a compelling option because of how easy it is to create the app and then update the content.  Even if your long-term strategy is to redesign an existing "desktop"-optimized website to be mobile-friendly as well, a buzztouch app could fill the void until that goal was reached.

If you need to build a mobile app that's more interactive, one where the user can send and receive custom data, then buzztouch is at best an incomplete solution.  There are no buzztouch components for collecting data (though the app itself will capture GPS info from the device in order to map where the app has been used, which is both useful and slightly disturbing), but you could probably use the Custom HTML component to create a web form that transmitted data via a regular form submit or via AJAX.  And there are as yet no components that let you access device-specific functions like the camera or accelerometer.

On the other hand, if you are capable of doing some IOS or Android coding, the native code provided by buzztouch could serve as a starting point for adding additional functionality:  the buzztouch folks seem to be open to folks using the generated code to advance their learning of native app programming.

So overall, I'm impressed with what buzztouch has done so far with the direction they've taken, and I hope they continue to improve on the platform.

The big annual auto show is in downtown Washington D.C. this week, and I'm planning on attending this coming Saturday (Feb. 5).  Even though I'm not looking to buy a new car anytime soon, my current car is twelve years old, and if it should suddenly die on me this year, I'd like to have some idea of what kind of car I might get to replace it.  Plus, I want to check out some of the new tech that's been appearing in cars the last few years.

I'm blogging about this because it occurred to me that maybe I could do some automotive scouting for other folks as well.  Have an interest in a particular car or car technology but don't have a local auto show you can attend?  Tell me what you're interested in by leaving a comment, and I'll look for it at the auto show and give you any info or impressions that I get.

And hey, if there are any local DC/MD/VA folks who'd like to meet up and maybe hang out at the show that day, that would be cool too.  :)

So just when I thought that all of the rhetoric regarding the Apple verses Adobe dustup over Flash had died down, Steve Jobs published an open letter entitled "Thoughts on Flash" on the Apple website today, ringing in yet another round in this boxing match.

I encourage those folks who care about this issue to read the letter in its entirety (rather than someone's summary of it).

Some quick thoughts I have on what was said (just my opinions/observations):

• When Jobs dings Adobe on the issue of Flash being proprietary, he acknowledges that Apple has proprietary products as well, but that "we strongly believe all standards pertaining to the web should be open." Why, exactly? What makes it okay to engage in proprietary protections off of the web but not on it?
• Jobs makes the point of mentioning WebKit to illustrate that Apple contributes to the open standards for the web.  He fails to mention that Adobe also makes contributions to web standards as well (the partnership with Mozilla on Javascript engine code comes to me) and that Adobe does have products in their toolset to allow developers to create websites using the latest advances in HTML, CSS, and Javascript. Adobe certainly has an interest in promoting Flash, but they continue to support other competing technologies.
• It's interesting that Jobs implies that Adobe was tardying in providing support for the H.264 hardward decoder, yet it has been pointed out by a number of sources that Flash has long suffered from performance issues on Macintosh computers because Flash was not allowed to make use of the graphics accelerator on Macintosh chips.
• Jobs states that any Flash sites that rely on "rollover" events to activate certain functionality would have to be re-coded in order to work on the iDevices. That may be true in some cases, but let's not forget that certain HTML and Javascript events also rely on the idea of hovering over a page element with a mouse, or dragging and dropping an item. The need to adjust to a multi-touch paradigm is not something that just affects Flash-based sites; it affects websites built with those open web standards as well. And just because something doesn't work quite right on a new device doesn't mean you should throw it out and start over from scratch.
• I see the issue of allowing Flash to run as a browser plugin on the iDevices and the issue of letting Adobe provide a tool for developers to translate Flash code into a binary file that runs on the iPhone OS as two separate things, yet the way the letter is written it seems to combine the two issues. Perhaps it was done as a means of using the earlier arguments to sway some options regarding the Flash-to-iPhone compiler issue.
• A lot of these complaints Jobs has regarding Flash (valid or not) can be or are being rectified. Instead of encouraging Adobe to address the things he has issues with, he "suggests" Adobe should drop Flash and stop criticizing Apple. That certainly implies to me that even an open, secure, battery-friendly, and efficient version of Flash would still never be allowed on the iDevices.
• I have to wonder what he thinks this letter will accomplish. The fact that he wrote it at all seems to imply either some desperation or annoyance over the fact that that Apple's anti-Flash stance hasn't been as widely accepted amongst the industry and amongst consumers as he'd like.  Perhaps he's looking to gain a few more converts to his stance at the cost of making his opposition that much angrier with him?