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…

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

One of the great features of mobile RIAs is the fact that you can connect your application to all kinds of different server technologies, such as PHP, Java, ColdFusion, .NET, … in exactly the same way as you would in your desktop AIR application. You can even work with the DataService component to use real-time data connections over the RTMP channel. Just think about real-time stock updates, video streaming, trader applications on mobile, collaboration across multiple devices … The sky really is the limit. Or is it?

I think all of this always sounds very nice, but people tend to forget one important thing when working on a mobile device and that is that if you’re not on a WiFi connection, your data contract can become very expensive when you use the sever connections. However, in Flex 4.5 there is a way to actually check whether you are working on your data contract or on a WiFi connection.

In the application you can access all of the device interfaces and check to see whether they are active or not. The only thing you need to know is which interface to look for. In the code below, you can see how I check for the “WiFi” and “mobile” interfaces. Based on what I find, I just check whether it is active. Remember, some people may have the possibility to work via a data contract, but didn’t sign up for it, so finding the “mobile” interface isn’t enough.

<?xml version="1.0" encoding="utf-8"?>
<s:View xmlns:fx="http://ns.adobe.com/mxml/2009" 
		xmlns:s="library://ns.adobe.com/flex/spark" 
		title="Connection Test"
		creationComplete="initView()">
 
	<fx:Script>
		<![CDATA[
			private function initView():void {
				var interfaces:Vector.<NetworkInterface> = NetworkInfo.networkInfo.findInterfaces();
 
				for(var i:uint = 0; i < interfaces.length; i++) {
					if(interfaces[i].name.toLowerCase() == "wifi" && interfaces[i].active) {
						lbl.text = "WiFi connection enabled";
						break;
					} else if(interfaces[i].name.toLowerCase() == "mobile" && interfaces[i].active) {
						lbl.text = "Mobile data connection enabled";
						break;
					}
				}
			}
 
		]]>
	</fx:Script>
 
	<s:Label id="lbl" horizontalCenter="0" verticalCenter="0"/>
</s:View>

In this example I’m simply setting the text property of a label, but you can also use this in a real world application to determine the update rate for your server data, for example.

There is one thing you should not forget to do when creating such an application. You have to set the proper permissions in the <applicationName>-app.xml file, in the android section. That section should contain the ACCESS_NETWORK_STATE and the ACCESS_WIFI_STATE permissions in order for it to work. If you don’t include this, you will get an empty Vector returned from the findInterfaces method.

<android>
    <manifestAdditions><![CDATA[
	<manifest>
		<!-- See the Adobe AIR documentation for more information about setting Google Android permissions -->
		<uses-permission android:name="android.permission.INTERNET"/>
		<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
		<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
	</manifest>
]]></manifestAdditions>
  </android>

Instead, they are now going for Hero, which is the next version of the Flex framework. That version should become a unified version, which will be cross-device. I can only hope that AIR 2.5 (which is the version for Android devices) is going to be included into the same framework, so there’s no more installing SDKs separately.

As you can see in this blogpost I wrote earlier, the applications I’m demonstrating are created with Flex (standard Flex 4/AIR2.5 that is) and they are running smoothly on Android. They have even been created via Flash Catalyst, which is definitely not optimised for mobile devices. But still they run smoothly, although I must admit that loading times could be faster. Can you imagine what performance you are going to get once this framework has been optimised? I can’t wait to get my hands on that SDK But it seems we’ll have to wait until later this year to be able to get a beta version of the SDK.

You can read the entire article on Adobe Labs.