Thought Delimited

Work has kept me from doing much personal coding lately, but when I had some time to spare I spent it building a mobile app with Flash Builder, and I've now released it (for free) on the Android Market.

It's called Quick Shopper.  It's a fairly unremarkable app that I built mainly for my own use, to replace the pen and paper list I would always take to the grocery store.  There are more than a few apps like it in the Android Market, but I felt like building my own. 

In fact, I had originally planned to code it as a native Android app but never got around to it, and after attending a workshop Adam Lehman gave to the local Flash/Flex user group that showed how easy it was to build and deploy an app with Flash Builder 4.5 I thought it would serve as a good learning experience.

And it was. I hadn't touched Flex since version 2, so while certain concepts were familiar I had to relearn a few things.  And of course all of the Spark stuff was brand-new.  But the documentation and blog posts I found online helped me figure out how to get everything working, and the device emulator and mobile device debugger in Flash Builder helped me work out some of the details via trial-and-error.

So am I a mobile Flex convert?  I'll put it this way:  when I come up with my next idea for an app I want for my Android devices, my first thought will be "can I build this with Flash Builder?"  If I can, and I don't see any significant advantage in coding the app in native Android code, then I'll probably go the Flash Builder route.  There may be some app designs that would work better as native apps (apps with widgets, or apps that utilize the scheduling and notification services of the Android OS), but now that Adobe's adding the ability to create native OS code extensions that work with Flex mobile apps, the number of cases where one would have no choice but to go the native route will probably get smaller.

As I said, it's not a very exciting app, but feel free to download it and check it out (it's free, after all).  I made use of the new feature in the Android Market that lets you provide multiple APKs for an app, so tablet users who download it will automatically get the tablet version with the larger icons and slightly tweaked UI layout, and phone users will get the "regular" version.

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 Lola J. Lee Beno shared on Google+ the link to Google's API page on how to add the Google "+1" button to your site.  It looked simple enough, so I figured I would go ahead and add the code to my blog so folks could "+1" my posts if they wanted to.

Then I remembered that I'm running Mango Blog, and while it's certainly possible to hack (err, "customize") the display files, the proper way to add new features like social networking buttons to the posts is with Mango plugins.

I knew how to install and use Mango plugins, but not how to write them.  What was I about to get myself into?

I found a Mango plugin called Twitter Retweet created by Nick Simone that did the same thing I was trying to do, only with Twitter.  By following his code and consulting the Mango documentation on plugins, I was able to create my Google Plus One plugin in an hour or two.  The only problems I ran into were ones of my own creation (the kinds of mistakes you can make when writing code late at night).  So now I have both the Twitter Retweet and Google Plus One plugins running on my blog.

I've submitted my plugin for consideration for the official Mango Blog plugin list on the Mango Blog site, but until it gets posted there Mango Blog users can download/install the plugin from the following URL:

http://www.thoughtdelimited.org/thoughts/downloads/googlePlusOne.zip

I've also put the code up on Github so that anyone who wants to fork it or improve on it can do so:

https://github.com/bcswartz/googlePlusOne

A client recently requested a new feature in an existing web app that would allow users to set an annual date for applying to an academic program.  I wanted to give the users the ability to set the date with a datepicker widget (so they could see if the date they were selecting was a weekday or not, for example), but I didn't want the datepicker to return a year because they wanted the option of keeping the month and day the same year after year.

My datepicker widget of choice is the jQuery UI Datepicker, but I wasn't 100% it would give me the option to leave off the year.  So I checked and found out that yes, by using the dateFormat() function of the datepicker, I could format the date returned by the widget to leave off the year:

http://jqueryui.com/demos/datepicker/#date-formats

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.