Entries Tagged as 'AIR'

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.

A few weeks ago, Peter Bell wrote a blog post about the Pomodoro Technique, a time management technique that advocates setting aside a set amount of time to turn off all distractions (e-mail, IM, Twitter) and focusing on a single task. I had just recently starting adopting the practice of shutting down my e-mail client once in awhile so as not to be distracted by incoming messages, so the idea made a lot of sense to me.

Not having a physical kitchen timer like the Pomodoro folks use and finding my stopwatch to be somewhat inadequate, I decided to try and write an AIR application to fit my needs. And so the focusTimer was born.

It's a very simple app: set the amount of time you want to focus (the 25 minutes advocated by the Pomodoro folks is the default), and click the "Start" button. I didn't want to get caught up in checking to see how much time was left, so I added a button so I could toggle between seeing the time left and just a status message.

I wanted to keep the window small so that it could be moved out of the way, but I also wanted a strong visual cue for when the time was up, so the color of the window changes to green when you start the countdown, switches to yellow for the "2-minute warning", and ends in red when the timer runs out. In the two days I've been using it at work, I've found that I can move the window to the far end of my secondary monitor and still catch the color change out of the corner of my eye.

Finally, even though the idea is to block out all distractions, there are some interruptions that cannot be ignored, so the "Start" button toggles between a "Pause" button and a "Resume" button once the countdown has started. If your focus session goes completely off the rails, you can use the "Cancel" button to break out of it and start all over again.

Even though I wrote this AIR app primarily for myself, I figured other folks might find it useful, so it's now available for download up on RIAforge:
http://focustimer.riaforge.org

In an earlier entry, I mentioned the announcement at MAX of Durango, a framework for allowing end-users to build AIR applications out of shared components.
I took some time last night to check it out, and here's what I learned...

First off, the components that make Durango work are Flex-based, so if you like to create AIR applications using HTML/CSS/JavaScript, it doesn't look like you can make use of Durango.

Durango allows a developer to make the Flex components they build (whether visual or non-visual/service-based in nature) reusable in other AIR applications. The 10-page long PDF file on the Durango page on Adobe Labs explains how to add Durango functionality to components. It also explains how to configure your AIR application such that it can either donate Durango-enabled components, receive Durango-enabled components, or do both.

The installation package available on Adobe Labs lets you experience Durango in action. Once the install is complete, you are then able to create a blank AIR application (one set to receive Durango-enabled components) simply by choosing the "New AIR Application" option now enabled in your OS (on Windows, you can simply right-click on the desktop to get to that option). Then you can open one of 4 sample AIR apps included in the install (all of which are set to donate their Durango-enabled components) and put it in "reuse" mode. Once the sample app is in reuse mode, the Durango-enabled components can be clicked and dragged onto the window of the blank AIR app you created, and now that component also exists in your AIR app, and you can save the changes to the AIR app. Certain properties of the component can be coded in such a way that the user can change them in the new AIR app, allowing for some customization of the borrowed component.

All in all, it seems like a fairly straightforward idea for making components reusable. The big question is whether or not end-users will utilize this feature. Folks who use a lot of separate AIR applications may see some value in taking bits and pieces from multiple apps and combining them. And it remains to be seen how AIR developers will feel about allowing the components they worked so hard to build to be taken and repurposed by other developers.

I was a little surprised this morning to find little or no mention of the announcements made at the Sneak Peek session at MAX last evening on any of the ColdFusion blogs aggregated by Adobe Feeds. Either I'm missing something or everyone had too much fun at the after-session party last night. :)

I don't really have any of the details about the announcements, since I was only half-paying attention to the live blogging from the event and the Twitter stream, but two items stood out for me.

One was the announcement that server-side ActionScript is in the works. For those who don't know, ActionScript is the language of Flex, which is a client-side technology. Someone on Twitter said that the announcement meant that you could run ActionScript on the ColdFusion server, so that you could code certain things in ActionScript rather than CFML, but I don't know if that's really the case or not (I'm sure that will be clarified within the next few days).

The second announcement that caught my attention was about Durango. To quote the Durango web page on Adobe Labs (it's already available for download): "Durango is a framework that allows developers to build Adobe AIR applications that can be customized by end-users." Basically, it sounds like a means of allowing user-created mashups in an AIR application. Giving end-users the ability to make their own mashups seems to be a trend in the industry lately. It remains to be seen whether users will make use of that kind of power and flexibility.

Anyway, I expect folks who are actually at MAX will blog about these items and provide some more details, but I figured I put these items out there so people know what to look out for in upcoming posts from the community.

After seeing the Six Revisions post, I decided to check colorPicker's download numbers on RIAForge and got another surprise: the download count was just shy of 800.

As of today, four days after the blog exposure, the download count stands at 1119.

I built the colorPicker mainly for myself (and I still use it). I put it up on RIAForge because I thought a FEW people might prefer something a bit simpler than Kuler (Adobe's color palette tool). But given the number of slick color designer AIR apps that are out now, I would never have expected that many people to have given colorPicker even a glance.

It just goes to show that you never know what apps or code other people might find worthwhile.