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… .

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

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!

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

So, here’s my first impression of the device in a couple of pictures. First of all there’s the box, which is sturdy and looks pretty nice. But however nice it may be, it’s still the content of the box you’re after, right?

When booting the device for the first time you’re taking through a wizard that let’s you setup the device connections and then the first thing it does is download a 287MB update. So make sure that you are on a WiFi connection and have some patience.

After that minor inconvenience, you can then start to play with it. And I must say, the graphics on the device are looking pretty nifty. Below you can find a picture of the default weather application that shows how nice the application and screen looks.

Next thing I tried out was playing a video. Luckily the PlayBook has a HD demo video on board, so when I played it, I was amazed at how beautiful it looked and how crisp the screen was. Plus the fact that it plays HD video.

Last, but certainly not least, there’s the home screen on the device. This is a bit complicated at first glance, but makes sense after you play with it for a while. I think it’s more the fact that the bevel of the device acts as a trigger for several gestures as well that needs some getting used to. But it keeps everything well organised and removes the need for a lot of buttons.

Talking about buttons, there have been a lot of reviewers complaining about the power button being too small or the fact that it’s hard to find. I must say I don’t have any problems with that. Maybe that’s because I have small fingers. In that case I can certainly understand that giants will have problems with this…

Anyway, this is just my first impression. Next up is playing with it and using it thoroughly as a test device for AIR and Flex mobile. And then we’ll see what’s what. To be continued…

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>

So now I’m sitting in my hotel room, waiting to leave for the airport in half an hour. It gets me thinking about the past couple of days and the Flash Israel event.

First of all, for everyone who has been thinking about bringing Phidgets or Arduino on a plane: don’t do it. I mean, I did eventually make it to Israel in one piece (I’m not yet sure I’ll be getting back safely as well), but the security nowadays is so tight I actually needed a couple of hours to get past the security check. Even getting into the mall where the event was held turned out to be quite the challenge. Imagine a stranger walking up to security and then saying he’s carrying some batteries with some wires attached to that, which powers some electronic components… Right, that does sound suspicious, doesn’t it? But in the end they finally understood that it was actually quite harmless.

With that said, let’s turn the attention to the event. It has been a very good 2 days for me, meeting a lot of interesting people and kick-ass developers here in Tel Aviv. These guys do amazing stuff. I even learned that lots of things have been invented here in Israel, such as the flash drive and the firewall. Didn’t have a clue…
I also met a couple of guys who were already into Arduino programming and have gotten some insight to some great applications for that technology. I may find some inspiration there for my next Phidgets project.

The speakers at the event were top-notch as well. You had the ones we all know: Lee Brimelow, Kevin Schmidt, Ben Forta and Grant Skinner and their presentations rocked, as usual. But then you had a couple of unfamiliar faces (at least to me) and they definitely surprised me with their sessions. Apart from the fact their were a couple of presos in Hebrew, which I don’t understand at all, there was large variety of interesting topics, ranging from game development to LiveCycle Data Services.

Since it was my first time at this event and even my first time in Israel, I didn’t quite know what to expect. But the crowd here was very interactive and I loved being here. So, that means I say a big thank you to Almog Koren for inviting me over here and I certainly hope to be back next year.

So, now it’s finally here, the moment we’ve all been waiting for for quite some time now: Molehill has launched in a public beta version. You can download it from the brand new Incubator subsite on labs.adobe.com. Wait, what? Molehill, Incubator? What are you talking about?

Allright, so you don’t know about the Molehill codename of the latest and upcoming Flash Player version? What planet have you been living on lately? But anyway, let me explain what it is. “Molehill” is the code name for a new set of low-level, GPU-accelerated 3D APIs that will enable advanced 3D experiences across screens through the Adobe Flash Platform runtimes. These new low-level APIs will provide advanced 3D and 3D engine developers the flexibility to leverage GPU hardware acceleration for significant performance gains. If you want to learn more about using these 3D APIs, you should read up on this blog post from the Flash platform blog.

While we have been waiting on a public beta of Molehill since MAX last year, it’s completely understandable that you haven’t heard of the Incubator site, because this is completely new. What can you expect from this subsite? The Incubator is a new place on Adobe Labs for Adobe to share with developers features that are under development or under consideration for inclusion in future versions of the runtimes. The major difference with the beta releases is the fact that the features and capabilities of these Incubator releases may or may not make it into the final release versions.

This is really an exiting time for 3D game developers, because now the Flash technology will enable you to create 3D games that work cross-platform with a single runtime. I sure wish I was more into games after seeing the capabilities of this Molehill release…

If you’ve been here a while ago, you may remember that I had such a solarlogger component in my sidebar. But then I decided to remove it and turn it into a mobile application. Now, next to the standard gauge that displays the current power output, I’ve added a chart that displays the power output throughout the day. Below you can see an example of what it looks like on a sunny day. (screenshot taken from HTC Desire phone, hence the portrait orientation)

Unfortunately, in Flex 4.5 there are no charts available. That’s really a shame and I really do hope Adobe is going to put that in as well, because I can see multiple applications that use these charts. Oh well… But we have to live with it now and find another solution. Christophe Coenraets wrote an excellent blog post about using FXG to draw some lightweight charts in a mobile Flex application, but after some thorough testing I’ve found some redrawing issues with using the FXG and rotating the device.

The solution I came up with, is simply drawing the graph yourself using ActionScript. What you need is some container that provides you with a graphics property on which you can draw the graph, clear the current drawing and get cracking at it. In the code below you can clearly see that I’m drawing each line part of the graph manually, ending in a horizontal line until the end of the graph, filling the result with a semi-transparent color. Within this application, I’ve used a tag to get me the graphics property to draw on.

var d:Date = solarData.getItemAt(solarData.length - 1).date;
d.setHours(6, 0, 0, 0);
minTime = d.time;
d.setHours(22, 0, 0, 0);
maxTime = d.time;
 
group.graphics.clear()
group.graphics.lineStyle(2, 0X009900, 1);
group.graphics.moveTo(0, group.height);
group.graphics.beginFill(0x009900, 0.5);
 
var xPos:Number;
var yPos:Number;
for (var i:int = solarData.length - 1; i >= 0; i--)
{
	// Calculate the y coordinate on the value axis
	yPos = group.height - (solarData.getItemAt(i).P_MomentTotal / maxPower) * group.height;
	// Calculate the x coordinate on the time axis
	xPos = (solarData.getItemAt(i).date.time - minTime) / (maxTime - minTime) * group.width;
	group.graphics.lineTo(xPos, yPos)
}
group.graphics.lineTo(xPos, group.height);
group.graphics.lineTo(group.width, group.height);
group.graphics.endFill();

This way, you can draw whatever you want on your application without having to use heavy components or cracking your head on Bezier curves. The graph can be drawn on any device now and is still very much lightweight. If you want to download and try out the SolarLogger application on your Android device, you can use this QR code with your barcode scanner application. Enjoy!

Well, there are 2 options you may choose from. The first one involves using ActionScript to attach an event listener. Upon initialisation of your View component, you write the following code:

private function initView():void {
    addEventListener(TransformGestureEvent.GESTURE_SWIPE, onSwipe);
}

The good thing about this method is the fact that it is exactly the same in plain ActionScript or Flash Professional projects. The second option can only be done in Flex applications and it is actually a little bit easier to implement. In fact, you just capture the gestureSwipe event on the View tag, as shown below.

<s:View xmlns:fx="http://ns.adobe.com/mxml/2009"
            xmlns:s="library://ns.adobe.com/flex/spark"
            gestureSwipe="onSwipe(event)"/>

So, that’s all there is to it for capturing the swipe on a touch enabled device, such as mobile phones, tablets or even large touch screens. But you only have one single swipe event, so how do you distinguish between a swipe left and swipe right? For that, you are going to have to use the event’s properties to determine the swipe direction. and more particularly, you’ll need the offsetX property for a horizontal swipe and the offsetY property for a vertical swipe.

private function onSwipe(event:TransformGestureEvent):void {
    // A swipe to the left means the offsetX property will be -1
    // A swipe to the right means the offsetX position will be 1
    if(event.offsetX == -1) {
        doSwipeLeft();
    } else if(event.offsetX == 1) {
        doSwipeRight();
    }
 
    // The same principle applies to the vertical swipe gesture, so
    // a swipe to the top means the offsetY position will be -1
    // A swipe to the bottom means the offsetY position will be 1
    if(event.offsetY == -1) {
        doSwipeTop();
    } else if(event.offsetY == 1) {
        doSwipeBottom();
    }
}