Tag Archives: air

adobe, flash, microsoft, professional

Adobe: no AIR planned for Windows Phone 7

1 Comment

I’m at the Adobe MAX conference in Los Angeles, and last night attended a couple of the “Meet the team” events where a bunch of Adobe engineers, product managers and others field questions about the products they are working on.

One of the events was on Adobe AIR, where an attendee asked whether we will see the AIR runtime on Microsoft’s Windows Phone 7. It is an interesting question, particularly at an event where mobile AIR has been highlighted. There is much talk of AIR for Android, and at the conference we have also discovered that the forthcoming Blackberry Tablet, the Playbook, uses AIR extensively for its user interface. AIR does not run on Apple’s iOS for iPhone and iPad, but Adobe has come up with a packager that compiles AIR apps to native code.

I have asked Adobe spokespersons before about AIR for Windows Phone 7 and have even been told that it will come, but it is a delicate matter. In fact, when I discussed this in a pre-MAX briefing with Adobe, I was informed was that Adobe would like to do it but that Microsoft will not permit it, though I doubt this is the whole story. The Flash runtime is known to be making its way to the device, though I have yet to see a date announced.

Last night the “Meet the team” presenter was clear. Adobe has no plans to deliver AIR for Windows Phone 7. We were told that Adobe sees Windows Phone 7 as a .NET device. The spokesperson (whose name I missed unfortunately – I’ll update if someone can tell me who it was) added mysteriously his belief that “it wouldn’t be the most successful endeavour for us.”

I would not assume from this that AIR will never appear on this platform; but it seems safe to say that it will not be soon.

The tension here is that supporting AIR would immediately increase app availability on Windows Phone 7, which would be to Microsoft’s advantage; but would also drive developers towards Adobe’s platform and away from Silverlight and .NET. The attraction of a cross-platform runtime is that you can develop once and deploy on a variety of devices, though there are always compromises involved.

Adobe may also have mixed feelings about supporting Windows Phone 7. Android is being heavily promoted here at MAX, even to the extent of handing a free Motorola Droid 2 to all attendees. If Windows Phone 7 becomes popular, Adobe will want its stuff to run there; but it might suit the company even better if it turns out to be a niche device.

adobe, microsoft, silverlight, software development

Native code interop in Adobe AIR vs Microsoft Silverlight

3 Comments

The latest versions of Adobe AIR and Microsoft Silverlight both allow access to native code, but with limitations. The two platforms take a different approach though – here is a quick comparison.

Native code access in AIR

The new version 2.0 of Adobe AIR is just about done. The runtime is available now (as is Flash Player 10.1), but we have to wait until June 15 for the final version of the SDK.

AIR lets you create cross-platform desktop applications that use the Flash runtime. Supported operating systems include Mac, Windows and Linux, and coming soon, Android. Sadly, supported operating systems do not include Apple’s iPhone or iPad.

One of the big new features in AIR 2.0 is access to native code. Of course this breaks cross-platform, unless you create identical native code extensions for all the platforms that AIR supports. Still, the ability to extend AIR without limit using native code is significant. So how do you use it, can you call a DLL or a dynamic shared library? What about COM on Windows, for automating Microsoft Office?

The answer is that you can do all these things, but not easily. There are actually three obvious ways to communicate with native applications in AIR 2.0:

1. Open a document using the default file handler. This is done using the new openWithDefaultApplication function. This is a handy way to open a PDF or Microsoft Office document, but you as the developer have little control over what happens. You do not know which application will open, and cannot control it once it does open.

2. Socket support. Your AIR application can send and receive data over a TCP socket. If you write a native code socket server and install it, you can get access to the local operating system APIs that way.

3. Native process support. This one looks promising. The new NativeProcess class lets you launch a native application and communicate with it via STDIN and STDOUT. Your native application could do anything, of course, such as calling a DLL or using COM, but it must use STDIN and STDOUT to communicate with AIR.

Another limitation is that AIR applications which use this function must be installed with a native installer, rather than by downloading an .AIR file. A further limitation is that auto-update does not work for these applications. You will have to write your own code to check for updates and download an updated installer if necessary.

Native code access in Silverlight

Microsoft Silverlight 4.0 also has the ability to run on the desktop and to call native code – but the native code part only works on Windows, and is restricted to applications that are “Trusted”, which means the user has approved the installation. A trusted Silverlight 4.0 desktop application can call COM via AutomationFactory.CreateObject. Presuming it is successful, your application can call methods on the returned object. If what you really want is to call a DLL, for example, you would have to write a COM DLL (or an application with a COM API) that calls the native DLL.

In addition, Silverlight 4.0 trusted applications have socket support, so that would be another possible approach. However, unlike Adobe AIR 2.0, you cannot simply open a document using the default file handler for its type. That said, it would be trivial to do so using COM and the WScript object, for example. You can also use the browser to do this – see here for an interesting case study from Beat Kiener, who does this with remote documents.

The main limitation of native code access in Silverlight is that it only works on Windows. Even if it does go cross-platform at some point, you would not use COM on Mac or Linux, so some other mechanism will be necessary.

Comparing the two

First, let’s acknowledge that native code interop is not something to use lightly in a cross-platform runtime. If you have to use native code, maybe AIR or Silverlight is not the right choice.

Opening files using the default file handler is a different case, as you can do this without any platform-specific code.

Still, if you can do almost everything in AIR or Silverlight, but need to call a native API for just one or two important features, it may be a reasonable approach.

My immediate observation is that native code interop is easier in Silverlight, though wrecked by being restricted to Windows only. The packaging and updating limitations in AIR, plus being restricted to STDIN and STDOUT, is more arduous than using COM in Silverlight.

Further, it is a shame that neither platform lets you simply call a dynamic library. It would then be relatively easy to write some conditional code to load the appropriate library on different platforms, and many tasks could be accomplished without needing to build and deploy your own native code executable for each platform.

Will you be using native code interop in either AIR or Silverlight? I’d be interested in hearing of examples, and how well it is working for you.

adobe, apple, flash, mobile

Flash developers are now mobile developers

1 Comment

Adobe’s announcement of AIR for mobile today at the Mobile World Congress means that any Flash or Flex developer can compile an AIR application that will run on a supported mobile device. I understand that AIR for mobile is a subset of desktop AIR, but does include Flash Player 10.1, local database support with SQLite, and access to local storage, so it is not lacking in capability. Apparently it will be possible to have a single .air file that will run across desktop and devices, perhaps with conditional code to account for differences in device capability. Some features, such as multitouch and accelerometer support, are more likely to be found on a mobile device than on a desktop, though things like screen size and available storage will be more constrained.

Until now it has been Java that comes closest to providing a common runtime across desktop and devices. Flash promises a more consistent runtime as well as stronger multimedia and graphics capability. Thanks to Apple, the app store concept is now well established and AIR applications fit well with this model, though not exclusively so. It will also be possible to deploy AIR applications from your own web site. I think there will be considerable interest and take-up for AIR on mobile.

Initial support will be for Google’s Android OS, with others to follow – with the exception so far being Apple.

This is where it gets interesting. Whereas Flash in the browser is blocked on Apple iPhone and (as far as we know so far) iPad, Adobe has a native compilation option for Flash applications targeting these devices, preserving some kind of deployment story. Clearly from Adobe’s perspective it would be better and easier if Apple allowed the AIR runtime onto the device. It’s less clear that Apple device users are really losing out though, and there is even an argument that they benefit, if you think that native code is a better solution for a mobile device.

In other words, the introduction of AIR for mobile does not really put any pressure on Apple, since Adobe has already come up with a good alternative. There may be some indirect pressure, since growing use of the Flash runtime outside the browser may also increase its significance within the browser.

A lot hinges on the quality of the mobile AIR runtime, particularly in respect of memory usage, which has tended to be greedy in desktop AIR.