There a basically two well-known solutions for you when you want to indulge yourself in physical computing and some real-world fun and games: Arduino (http://www.arduino.cc) and Phidgets (http://www.phidgets.com). The biggest difference between the two is that with Phidgets you can buy plug-and-play circuit boards that are ready to go. You just connect them together and hook them up to a main controller board, which usually runs on a USB connection with your computer and you’re set to go. Phidgets is very easy to use and I highly recommend it if you want to get started with this type of applications, since you don’t really need to know much about electronics to get started. The downside is that it doesn’t run stand-alone (unless you buy the super expensive SBC stand-alone board which runs a full Debian OS).

The advantage of using Arduino is that it does run stand-alone and it is even not that hard to get the chip out of the circuit board and onto a prototype board which you can build into any application you like.The biggest downside to Arduino is that you have to have at least some basic knowledge of electronic components and wiring. I don’t really consider this to be a downside, because you can make whatever you want, but it does make it a higher threshold to get started with it. Another downside is that the programming is a bit harder to do, especially for this LED cube type of application, since you will not be using the standard programming interface you might be used to if you’ve been doing some Arduino programming before. Having never touched a soldering iron before, I decided I liked the challenge and chose the Arduino approach to create a stand-alone version which I can easily reprogram if necessary.

Before I get started on telling you how to build such an LED cube, let me quickly show you the end result:

Now, this will be a multi-part blog post spread over the next couple of weeks, since there is a lot of information to share on this. But I can already say that some credits have to go to the author of this post for getting me started on the project. Even though there are quite some mistakes in the post and it has been made more complex that necessary for my purpose and intention, it provides a good starting point. So, keep tuned for the first part of the build…

First thing I couldn’t help but notice is the beautiful location, in the middle of the mountains covered with snow. This alone makes the trip worthwhile. It must be one of the most unique locations for a conference.

Then there’s the format of this conference, which is skiing and other activities during the day and sessions at night. And yes, I do mean AT NIGHT, because sessions didn’t stop before 1 AM at least. I still find it amazing to have so many people staying for the last sessions after a full day of intensive skiing.

Unfortunately, due to the fact that I haven’t been skiing for over 12 years, I didn’t want to risk breaking and arm or leg, but that didn’t stop me from having some fun in the snow. But you know, this isn’t a vacation, it’s a conference. Well, at least, that’s what I told my boss .

About that conference, it has a great atmosphere. With a limited amount of participants the stress lies on networking. It is nice to be able to talk with so many geeks. I must say, I’ve had some inspiring conversations and got to know a couple of designing and coding nut cases.

As for my session, that was about using ORM in AIR (mobile) applications. At first I thought it would be way to much code oriented for this conference. Especially when I looked at the other session descriptions. But when I saw those sessions, I began to wonder whether it would be complex enough for this conference . I knew some of the speakers already and from them I knew what to expect. But I was pleasantly surprised by the speakers I didn’t know. There was some really great talent there and I certainly got inspired by some of the sessions.

I want to express my thanks to Fernando Colaço for organizing this awesome event and for letting me be part of it. I’ve had a wonderful time, met wonderful people, got inspired and I hope to be part of it again next year. I’ll have to make sure I’ll take some skiing lessons before that though… .

I completely agree that it has been poor communication from Adobe, especially after what they have announced at AdobeMAX this year. So, timing could have been better and the messages that they initially shared could have been better formulated. Adobe acknowledges this and have sent out their apologies for that as well. But the harm was already done. I even saw people leaving prerelease and other programs (I can’t mention by name) furious about what happened and turning their backs on Adobe entirely. I respect those decisions, but come on, is it really such a bad thing?

For those of you who are not quite up to speed on what exactly is going on at Adobe. Let me briefly state the latest developments.

Let’s start with LiveCycle. For those of you who don’t know what LiveCycle is, it is a product that allows you to define information workflows, mainly based on PDFs. So, for example, you could fill out a job application form in a PDF, digitally sign it with you eID card (in Belgium at least) and send it to a specific email address. The PDF attachment gets picked up from the mailbox and the information is extracted and put in a database. After that a “thank you” email is sent to the applicant, while in the mean time the HR manager is notified of a new application. Upon approval by the HR manager in the so called “workspace” a new PDF is sent to the unit manager, notifying him that he should interview this candidate, together with the candidate’s résumé. After the interview the unit manager can then input his findings in a evaluation form and LiveCycle will pick that up as well to put it into the database and notify the HR manager that the evaluation has been submitted. Would the candidate be rejected, the can be marked in the “workspace” again for example, an automatic email will be sent to the candidate notifying him of his rejection.

Now, this is just one example of what LiveCycle can do. Even though Adobe is shifting its focus towards other strategic solutions, they will continue to develop LiveCycle (as you can read here), invest in finding new customers and product support is still guaranteed, so you’re not left alone with your solution if you’re currently using LiveCycle.

As for dropping the Flash Player on mobile devices, I don’t think that is a bad thing. You see, if Adobe wants to keep the same version of the Flash Player on all devices (desktop, mobile, tablet) then a lot of code will have to go in checking whether or not things certain features are available. This requires a lot of effort and slows down progress on the features that matter the most. I mean, come on, when did you actually use a Flash based website on you mobile device? Either it wasn’t mobile optimized causing frustration in content that is not scaled properly, or it just was overkill for a mobile device.

Now Adobe has the opportunity to focus on the desktop platform and make full use of the GPU hardware acceleration and other cool features that require more processing power than what the other devices can offer at this moment. It is clear that Adobe wants to move in the direction of gaming with Flash, which I have been expecting for some time now.

Remember, I just said that the Flash Player will be dropped on mobile. That does not mean that the cross-device AIR solution is being dropped. On the contrary! AIR for mobile devices will continue to be developed by Adobe and is one of the key products/features they will maintain. So you don't have to worry about your cross-device development.

However, the Flex SDK is going to be put into the Apache project, bringing along a new produt name as well, since Adobe won’t own the SDK anymore. Once the incubator is accepted, the product will be called "Apache Flex". You can read all about the Apache Flex Incubator right here.

That means that from that point on the SDK will be developed and maintained by the community. That will be a good thing in the sense that probably we’ll get more features more rapidly developed. But – and there’s a big "but" in here – I do see a problem in the adopt of the Flex technology in big companies. You see, what companies want is a support contract with time frame commitment. They want a red phone to the help desk when they encounter serious problems and at the moment they are paying big money for that. Once Flex is owned by the community, Adobe probably won’t be doing anymore support, because it is now up to the community.

This lack of support is what could harm Flex in the high end business companies. But then again, this will also lead to new opportunities for companies such as multimediacollege in the sense that we can now write and publish our own training material, as well as provide support contracts for helping out companies who need assistance with some Flex problems.

So, is Flex dead? Definitely not! And it isn’t dying either. We will have a huge community supporting the development and some highly skilled developers working on the features. I wish I had some magical device that allows me to see into the future to see what will happen with Flex when it becomes completely Open Source. But for now, I’m not yet worried about it’s future…

Tonight I got one of the “coolest” emails you can get: I’ve been invited to give a session at gotoAndSki(); Switzerland on January 26th, 27th and 28th, 2012, which is really awesome. Unfortunately I haven’t been to this conference before, but I’ve heard very nice things about it and let’s face it, skiing during the day and conferences with diner at night is not your typical conference setup. So I’m really looking forward to it.

Now, about my session, it’s going to be titled “Database Driven Mobile Applications: the power of ORM”. Now, some of you may think “what the hell is ORM?”. Well let me reassure you that it is not magic, but it does some really magical stuff.

ORM allows you to create database driven applications by writing virtually no SQL statements.Normally, this type of feature is restricted to the server side of your application, but now you can use this server-side feature on the client-side in an AIR application.

This session will talk you through the basics of using ORM in AIR and how to “automagically” synchronise your local data with a remote server. Whether that’s a PHP, Java or ColdFusion, it doesn’t matter. That’s not all: we’ll go one step further and take that ability to create database driven applications onto the mobile platform as well. Just like that!

If you are digging this and the other topics presented at gotoAndSki(); make sure you get your tickets in time to enjoy the conference and the gorgeous surroundings of the Swiss Alps. I hope to see you there: switzerland.gotoandski.com

Getting Started with Web Application Development Using ColdFusion
http://adobe.ly/CFWeek01
Monday 10AM PDT

Working with PDFs Made Easy with ColdFusion
http://adobe.ly/CFWeek02
Monday  1PM PDT

Introduction to ColdFusion Components (CFCs)
http://adobe.ly/CFWeek03
Monday  4PM PDT

Improve Your ColdFusion Code Through Unit Testing
http://adobe.ly/CFWeek04
Tuesday  10AM PDT

Using ColdFusion Frameworks for Application Development
http://adobe.ly/CFWeek05
Tuesday  1PM PDT

Understanding and Using the ColdFusion Server Monitor
http://adobe.ly/CFWeek06
Tuesday  4PM PDT

ColdFusion Builder: The Professional IDE to Boost Your Productivity
http://adobe.ly/CFWeek07
Wednesday  10AM PDT

Expand Functionality with ColdFusion Builder Extensions
http://adobe.ly/CFWeek08
Wednesday  1PM PDT

Developing Your First Application Using ColdFusion 9 and ORM
http://adobe.ly/CFWeek09
Thursday  10AM PDT

Speed Up Your Apps with Caching in ColdFusion
http://adobe.ly/CFWeek10
Thursday  11:30AM PDT

ColdFusion and Mobile – Browser-Based Applications Made Easy
http://adobe.ly/CFWeek11
Thursday  1PM PDT

Become ColdFusion Empowered in Under an Hour
http://adobe.ly/CFWeek12
Thursday  4PM PDT

Accessing ColdFusion Services From Flex Applications
http://adobe.ly/CFWeek13
Friday  10AM PDT

Securing your ColdFusion Applications
http://adobe.ly/CFWeek14
Friday  11:30AM PDT

Make Your Site Searchable with Solr
http://adobe.ly/CFWeek15
Friday  1PM PDT

Bringing ColdFusion to Java SpringMVC
http://adobe.ly/CFWeek16
Friday  4PM PDT

• Bind the value of one input field to a data model
• Bind the value from a data model to an input field or label
• Bind the value of one input field to a label or another input field

Now, this binding mechanism always worked by mean of events that triggered an update of the bound field. Usually this is the change event, but you can define your own events that will trigger an update of the binding expression. I’m sure most of you already know this. But did you also know hat you can use a similar binding mechanism in ColdFusion 9?

The binding expressions in ColdFusion enable you to create dependencies between form elements, client-side recordsets, ColdFusion AJAX container elements and information fetched from background data requests. You can use binding with all AJAX-aware tags, but the exact syntax varies a little bit for every tag and for every different source of the data. Let me give you a couple of examples to clarify this.

Using a CFC

When you want to bind data to a public property of a ColdFusion Component (CFC) or to the result of a function within that CFC, the syntax will have to indicate that it needs to work with such a component. Assume you have a CFC named Test. Within that CFC you have a public function called multiply that takes 2 parameters and outputs the result of the calculation. The code could look something like this then.

<cfset test = new Test()/>
<cfdiv bind="cfc:test.multiply(3, 4)"/>

Creating field concatenations

Sometimes you want a certain input field to get a default value based on other input fields. This way you can aid the user in suggesting a certain value based on what he has already filled out. One such example could be the automatic generation of an email address. Suppose you have a form which requests the user’s first and last name and you’ll probably want the email address to be firstname.lastname@company.com (unless this would create a duplicate email address or illegal characters in some cases). So why should you be bothered to fill out the email address in 99% of the times you fill out this form?

You could make use of field binding in ColdFusion and concatinate the first and last name with a fixed string for the last part of the email address. To get the binding working you will have to define when the email address is updated. In this particular case I’m just going to update it on every keystroke in either the first name or last name field. The code then looks like this.

<cfform>
    First Name:<br />
    <cfinput type="text" name="firstname"><br />
    Last Name:<br>
    <cfinput type="text" name="lastname"><br />
    E-Mail:<br />
    <cfinput type="text" name="email" 
             bind="{firstname@keyup}.{lastname@keyup}@company.com">
    <br />
    <cfinput name="btnSubmit" type="submit">
</cfform>

Using a JavaScript Function

Sometimes it’s not that simple to concatenate values and perhaps some additional checks have to be performed before you can output the value to another field. Or maybe you just want the first letter of the first name instead of the full first name in the email address. These would be a perfect situations where you would want to use a JavaScript function. So you define a function that does the concatenation for you and simply display the result of the function.

This is quite similar to using a CFC, so the syntax is quite similar as well. Just check the code below to see what I mean.

<html>
<head>
    <script language="javascript">
        emailAddress = function(firstname,lastname) {
            return (firstname.substring(0,1) + lastname + '@company.com');
        }
    </script>
</head>
<body>
    <cfform>
        First Name:<br />
        <cfinput type="text" name="firstname"><br />
        Last Name:<br />
        <cfinput type="text" name="lastname"><br />
        E-Mail:<br />
        <cfinput type="text" name="email"
                 bind="javascript:emailAddress({firstname@keyup},{lastname@keyup})">
        <br/>
        <cfinput name="btnSubmit" type="submit">
    </cfform>
</body>
</html>

These are a few examples and situations where you could make use of the binding expressions. Of course there are still other ways of using them, such as binding the result of an AJAX call to a <cfselect> tag. Or you could use binding with a <cfajaxproxy> tag as well as a few others. But this blog post acts as a teaser, so hopefully you’re curious now and start working with binding expressions in ColdFusion 9, because this is some good stuff…

Now, the problem with these validators is that they are geared towards validating one single visual component, such as a TextInput, TextArea, ComboBox, List etc. But what about compound components, such as a DateField combined with a TextInput field for the time? Or, as I will explain in this post, a RadioButtonGroup, which is a non-visual component, but actually comprises the different RadioButton components?

Before I go into how I solved that problem, let me explain a bit about the Flex Validator class. This is the base class for all the different validators and can only check on a field being required or not. This also means that we are going to inherit from this component to create our own validator classes. Of course, you can extend other validator classes as well, but for my purpose of checking to see if a RadioButton in the list has been selected, the Validator base class will be just fine.

<mx:Validator source="{componentToCheck}" property="propertyToCheck" 
              trigger="{componentToMonitor}" triggerEvent="eventToMonitor" 
              required="true(default)|false" 
              requiredError="errorMessage"/>

As you can see in the code sample above there are a couple of important properties in the base class we have to keep in mind when developing our own validator class. First of all, the componentToCheck will be an instance of RadioButtonGroup and the propertyToCheck will be the selection property. You can use the trigger and triggerEvent properties to determine when the validation needs to take place. Leaving out the trigger property and explicitly setting the triggerEvent to an empty string will make sure that the Flex framework will never trigger the validation by itself. That means that we have to do that manually at the exact time that we want the validation to happen.

In the code below you can clearly see the usage of these properties in both <co:RadioGroupValidator/> instances. For all good purposes I’ve also made both a Spark and Halo form to show you the RadioGroupValidator works with both Spark and Halo components.

<fx:Declarations>
	<s:RadioButtonGroup id="rbgSpark"/>
	<mx:RadioButtonGroup id="rbgHalo"/>
	<co:RadioGroupValidator id="vRbgSpark" source="{rbgSpark}" property="selection" triggerEvent=""/>
	<co:RadioGroupValidator id="vRbgHalo" source="{rbgHalo}" property="selection" triggerEvent=""/>
</fx:Declarations>
 
<s:Form defaultButton="{btnSubmitSpark}">
	<s:FormHeading label="Spark form"/>
	<s:RadioButton label="Choice 1" group="{rbgSpark}"/>
	<s:RadioButton label="Choice 2" group="{rbgSpark}"/>
	<s:RadioButton label="Choice 3" group="{rbgSpark}"/>
	<s:RadioButton label="Choice 4" group="{rbgSpark}"/>
	<s:Button id="btnSubmitSpark" label="Submit" click="sparkSubmitHandler(event)"/>
</s:Form>
 
<mx:Form defaultButton="{btnSubmitHalo}">
	<mx:FormHeading label="MX form"/>
	<mx:RadioButton label="Choice 1" group="{rbgHalo}"/>
	<mx:RadioButton label="Choice 2" group="{rbgHalo}"/>
	<mx:RadioButton label="Choice 3" group="{rbgHalo}"/>
	<mx:RadioButton label="Choice 4" group="{rbgHalo}"/>
	<mx:Button id="btnSubmitHalo" label="Submit" click="haloSubmitHandler(event)"/>
</mx:Form>

As for the RadioGroupValidator class itself, the only thing we need to do there is to override the validate method to see wether or not the validation succeeded. If the validation failed we need to loop over all the RadioButton components that belong to this group and set their errorString to the proper message, as you can see in the code below.

import mx.events.ValidationResultEvent;
import mx.validators.Validator;
 
public class RadioGroupValidator extends Validator {
	public function RadioGroupValidator() {
		super();
		requiredFieldError = "Please choose an option from the list."
	}
 
	override public function validate(value:Object=null, suppressEvents:Boolean=false):ValidationResultEvent {
		var result:ValidationResultEvent = super.validate(value, suppressEvents);
 
		for(var i:uint = 0; i < this.source.numRadioButtons; i++) {
			if(result.type == ValidationResultEvent.INVALID) { 
				this.source.getRadioButtonAt(i).errorString = result.message;
			} else {
				this.source.getRadioButtonAt(i).errorString = null;
			}
		}
 
		return result;
	}
}

Now, as you can see I’ve also set the errorString in the constructor to a specific message. This doesn’t mean that you can’t provide your own specific message anymore in the instance declaration. The reason for this is that setting a property in MXML actually uses the implicit setter method and that one is executed after the constructor has initialized the object, which means it will simply overwrite the default value.

P.S.: If you test the forms, you will see that the Spark form doesn’t show the red error indicator as well as the MX form. Maybe that’s a glitch in the framework, maybe not. I’m still hunting that little sucker down, but no luck so far. I will update this example when I solved this problem.

So far, I was quite happy with my PlayBook, but I did have some concerns regarding its functionality. For example, one of the preinstalled software was Bing maps, which uses the GPS to get a fix on your position. However, documentation on the PlayBook stated that it has a GPS on board, but I never could get a lock on any satellites, no matter which geolocation application I was trying. Even testing the GPS availabilty with an Adobe AIR application by checking the GeoLocation.isSupported property gave me a confirmation that the device has a GPS (which I was doubting after all my efforts).

Talking about AIR applications, those of you who tried to get an app on the PlayBook have noticed that up until now the operating system only supports version 2.5, whereas creating mobile AIR applications required AIR 2.6 or higher. That was a problem, but it could be fixed by adding the -forceAIRVersion 2.5 option to the BlackBerry packaging options in Flash Builder. (Or you could of course compile and create the package using the command line tools). Although being solvable, this remained an inconvenience

Now, with the latest update things have changed. First of all, I’m delighted to say that the GPS is finally working properly and I even get a lock when indoors, which cannot be said for most GPS devices. Not that I’m using it that much, since the PlayBook only has WiFi available and no 3G connectivity (well, mine doesn’t have that, but future devices could), which means you cannot use it on the road. But it’s the thought that counts…

Then I noticed the screenshot above and the fact that the operating system now supports AIR 2.7. This is awesome news, because that means that we don’t have to fiddle around with PlayBook specific packaging settings anymore. You can now simply take your AIR application and compile it both for Android and BlackBerry PlayBook without having to worry about the AIR runtime version on the devices. Well, at least until Adobe enforces another higher version of AIR for some reason. But even then, it seems that BlackBerry is keeping up with those releases pretty well.

So, to all that have been postponing BlackBerry PlayBook development using AIR and Flash Builder 4.5 because of the additional hassle you had to go through: go forth and start working on cool AIR apps!

In a second part join Tridib Roy Chowdhury, Senior Director of Products, and Priyank Shrivastava, Senior Product Marketing Manager, for an exceptional meet the team session where you will get the highlights of ColdFusion and ColdFusion Builder roadmap. This is also your best chance to come and raise your hand for questions and/or recommendations you have about ColdFusion.

PROGRAM:

18.30: Coldfusion powered AJAX Applications with jQuery
19.45: Meet The Team
21.00: Free drinks and networking

This event is free of charge, but seats are limited. Make sure you register quickly!

The CFUG team, Cyril & Steven

But for now, she’s not getting hold of the device, because I want to try several things out. And one of those things is the real cross-device development using the Flash Platform. In my case, that means Flex of course. That’s what I’ve be doing for the past couple of days and I must say it’s really working once you get the procedure down. That’s the tricky bit for now, so let me take you through my struggles and maybe I can save you from making the same endeavors as I needed in order to get it working.

Setting up the development environment

This is the first part you’ll have to go through. Blackberry has issued a tablet OS SDK, which is a plugin for Flash Builder that allows you to compile applications for the PlayBook directly from within Flash Builder. While this all sounds great, the latest releases of that plugin do not support Flex Mobile applications. That means you cannot use that SDK to compile your Flex Mobile application. You can only work with ActionScript Mobile application.

A second issue is the fact that the SDK is installed on top of an existing Flex 4.5 SDK and without giving away too much information, it is not compatible with all Flex 4.5 SDKs, so compiling and packaging the application from within Flash Builder is not possible with the latest versions. Hopefully BlackBerry will release another version of their SDK this is compatible soon.

Taking these two issues into accounad the fact that as a Flex developer I want to use a Flex Mobile project, I’ll have to package the application using the command line.

Compiling and packaging the application

Since the option of compiling directly for the playbook is not possible with the latest builds, I’ve used a little shortcut to get the release build of my application. I mean, if you’re working on a Flex mobile application and you compile using Flash Builder, you can only opt for the Android APK file. There is no release build that gives you the release version of the SWF file.

So that’s exactly what I’ve done. Then I unzipped the APK file and searched for the release version of my SWF file and used that to package my BAR file. The command to do the packaging is as follows

blackberry-airpackager -package <BAR file> <application>-app.xml <application>.swf blackberry-tablet.xml <assets required by the application>

Signing the application

Once you have the BAR file ready you have come to the trickiest part: signing the application. This is best done via command line again, but hopefully this will be included in the Flash Builder plugin once it’s updated to work with the latest builds and with Flex Mobile projects.

First, you need to be registered as a vendor with BlackBerry in order to obtain you code signing key. This is done only once per developer or company, depending on how you want to register yourself. Obtaining the key is done by filling out this form.

The key you receive will be a CSJ file. It all starts with that file, because now you have to register that CSJ file as well as create a keystore to communicate with the BlackBerry signing authority. So, we’ll start by setting up that keystore, which is done via the following command

blackberry-signer -csksetup -cskpass <create a password>

Then you need to register the CSJ file by using the following command

blackberry-signer -register -csjpin <PIN> -cskpass <csk password from previous step> <CSJ file>

The last thing to get you set up is to generate a coding certificate, a .p12 file that is not unlike the certificate you create for regular AIR applications. This is done by executing the following command:

blackberry-keytool -genkeypair -keystore <certificate.p12> -storepass <create a password> -dname “cn=<company name>” -alias author

Once you have this set up, you are all set to start signing your application. When signing an application for the BlackBerry App World you actually have to sign it twice. Once for the code signing itself and a second time to add the author data to the BAR file. This can be done by executing these two statements in this particular order.

blackberry-signer -verbose -cskpass <csk password> -keystore <p12 certificate> -storepass <certificate password> <application>.bar RDK

blackberry-signer -keystore <p12 certificate> -storepass <certificate password> <application>.bar author

If you go through this signing process several times, make sure that you increase the application versionNumber in the <application>-app.xml file every single time. Otherwise you will get the error message that the application was already signed.

Deploying the application on the device

At this point your application is ready to be submitted to the BlackBerry App World. However, you might want to install it on your own device already and not wait for approval. This can be done via command line too and it can only be done with the signed BAR file. Unsigned applications can be installed using a debug token that expires after 30 days, but the following command is not suited for that type of deployment. It will only work with signed BAR files.

blackberry-deploy – installApp -device <device IP> -password <device password> <application>.bar

When you execute this command the application will be installed on your BlackBerry PlayBook and you can run it as if you installed it through the App World.

This might not be the best way to get your Flex Mobile application on the PlayBook, but it sure has worked for me and as far as I know it is the only way to do this with my current setup of Flash Builder and PlayBook SDK.

If someone has a better way of doing this, please let me know as I find this not an easy process to do (what should be) a simple task