Custom Software Development

I was very excited to read Adobe’s beta release notes about AIR 2.  AIR gives developers a very easy way to develop good looking, cross-platform applications.  The problem is that, in order to ensure all applications are cross-platform, Adobe was very stingy about how much you can reach out and interact with the underlying OS.

Those of us investing time in developing AIR apps have been working with one hand tied behind our back, unable to do simple things like even launch a document in MS Word, let alone utilize the thousands of shell commands available inside the OS.  (Well, there are various alternatives and hacks to do similar things, but still…)  Simple functions like burning a CD or encoding an audio file were simply not possible because the underlying libraries that perform these functions are not accessible within the AIR sandbox – even if those libraries themselves are cross platform.  None of the other major cross-platform environments have this limitation.  AIR was designed to connect to a server via HTTP in order to do these types of things, which is great for a web-based solution but not so for a desktop solution.  So AIR sometimes gets a bad rap as a a “widget” development platform that is good for eye candy, but not able to have deep interaction with the OS.

With AIR 2 Adobe decided to lift even more of the constraints and allow developer to execute native commands.  What this means is that we might start seeing very handsome AIR apps that serve as SVN front-ends, MP3 encoders, network monitoring tools, disk utilities, etc.   AIR will be able to interact with other software on the machine such as legacy enterprise apps.  I know this was not Adobe’s original vision for AIR, but  I have always thought otherwise and I’m very glad Adobe decided to loosen the shackles.  There are several other interesting improvements in version 2, but I think the native call feature has the potential to open the floodgates for enterprise developers.

With the new functionality comes the inevitable risk that some AIR apps will only run on one platform, or they may require you to install an OS-specific component in addition to the AIR application.  It will also be possible to build an AIR app that requires a certain Windows-only or OSX-only command.  However, thoughtful developers will at least be able to make that choice for themselves.

AIR 2 is out in beta now and end users will start seeing new applications when the public release launches in the first half of 2010.

The timezone functionality in Flex (as of SDK 3.4.1) makes me wonder if this is the person who designed this behavior.  It’s clear that the functionality was designed to magically handle the difficult subject of timezone and I appreciate that.  The problem is that, athough Flex goes through the trouble of calculating the UTC time automatically, you have no clean way to obtain input or display date values in anything other than the local system time.  So in order to display dates in other timezones, you actually have to enter incorrect UTC values and “trick” flex into showing the value that you want.  Additionally the remote server communication is very confusing and inconsistent with local (AIR) db storage.  The server has no way of knowing what the real value of your Date is unless you also provide it with the local clients current timezone offset.  Meanwhile, dates saved to a local DB have no timezone info stored with them at all.  Saving dates locally (AIR) can be downright dangerous if the system timezone changes while the app is open, including daylight savings changes.

If this is something that has caused you grief, I encourage you to vote for the issue to be fixed in the Flex SDK.

Read more

If you work with Flex remoting and WebORB, you are probably familiar with the following errors:

• NetConnection.Call.Failed: HTTP: Status 500
• Channel Disconnected

You may have tried directing your browser to weborb.php only to get this message: “WebORB v3.5.0 Fatal error: Call to a member function getServiceURI()”

The getServiceURI message is actually a red herring error message.  This simply occurs because weborb.php is expecting the raw headers to contain Flash remoting AMF message data.  Your browser is just making a normal HTTP GET and doesn’t know anything about AMF.   So weborb.php winds up with a null object on which it tries to call getServiceURI().  I wouldn’t be surprised to see a future release of WebORB that catches this error, even though it isn’t the purpose of this particular file to run inside a browser.

Read more

Last year I posted a FlipCard component for Flex that allows you to place UI Controls on the front and back of a 3D “card” that can be flipped by the user.  It gives the user the visual effect that there are settings or options on the backside of the page, form, etc.

Read more

In Flex when you bind data to a UI control like a DataGrid, the grid cells refresh every time the dataSource changes. The reverse is also true if the DataGrid is enabled for editing. That is, the dataSource is also updated when you edit a cell.

The TextInput can be bound as well so that when the dataSource changes, the value of the TextInput will automatically update. However, unlike the DataGrid, changing the text of the TextInput will not automatically update the dataSource. Take the following code for example (assuming “source” is a String variable):

<mx:TextInput id="example" text="{source}" />

When the TextInput is changed, the value of source remains the same. It’s only bound one-way. If you want the value of source to be updated when TextInput changes, it’s actually easy, but there are at least five (5) different ways to do it of which I know. For the most straight-forward two-way binding, you could update the TextInput code like so:

<mx:TextInput id="example" text="{source}" valueCommit="{source = example.text;}" />

Technically source is not bound to the TextInput, but it does produce the desired result. source is updated manually whenever the valueCommit event fires. The valueCommit event fires when the TextInput text has been changed onBlur (ie when when TextInput loses focus). If you prefer source to be updated on every key stroke, you can change valueCommit to change instead and the update will occur on every keyUp. If I’m updating a database or making a service call, I prefer valueCommit so the back-end code only fires once after the user is finished updating the field. If the TextInput is an ajax-style auto complete or lookup, the change event might be more desirable so the application can react after each key stroke.

As I mentioned there are five methods to do this. You can bind controls using Flex’s binding features in either MX code or ActionScript. Depending on your application one may be better than the rest as far as keeping your code clean and consistent. For the most part they all achieve the same result. Attached is source code that demonstrates all five techniques:

Download TextInputBinding.zip

If you know of any other ways to bind data to UI Controls, please post a comment.