The .NET Platform
Development Tools
COM & COM+
Data Access
Web Development
XML Technologies
Windows Servers
Wireless & Mobile
Security issues
Design & Process
Career Development
Analysis & Comment
Disposable Objects
We found this book useful!
You are not logged in: login here to access all areas.
Coming up for AIR
We report from Adobe’s San Francisco office where we attended a meeting with Kevin Lynch, Chief Software Architect at Adobe, and other reporters including Simon Bisson, Tim Anderson, Ian Murphy and Jack Schofield of the Guardian newspaper.
Author: Matt Nicholson
Last updated: Nov 2007
Adobe has already built up a strong position in the creative world with tools like Photoshop, InDesign, Illustrator and – thanks to its acquisition of Macromedia – Dreamweaver. The acquisition also brought it Flash, which together with Acrobat provides the company with two well-established platforms for enriching the Internet experience. It is now consolidating its position with Flex, its development framework for creating Rich Internet Applications (RIAs), and with AIR, the Adobe Integrated Runtime for hosting applications on the desktop. Lynch opened by telling us how the AIR project built on Macromedia’s earlier Central project: “We started the Central project in around 2002. We had seen that people were starting to make RIAs that ran inside the browser, and we started thinking about where that was going to go over the next couple of years, and what we could do to prepare for that time. One of the things we figured was that RIAs would get increasingly functional and want to take on many of the aspects of desktop applications. We started asking ourselves how we could give such applications access to the local disk, help them raise notifications, how such applications might be installed, and so on. There are a lot of questions to be answered! “We focused at the time on Flash because that’s what people were primarily using to create RIAs as the AJAX wave hadn’t yet started. We learned a lot from that. First of all we learned that the Web isn’t just about Flash: people were making applications that combined Flash with HTML and even PDF for workflow, so we needed a runtime that could embrace all those formats. “We learned that the brand of the developer needs to be primary. With Central we created a shell that contained applications in much the same way as a browser contains Web pages. We thought that would help users understand this new space. What we found was that developers didn’t like to have another brand – in this case the Macromedia Central brand – ‘containing’ them. The other thing we learned was that the virtual machine inside the Flash Player wasn’t fast enough. “So we took a step back and worked with a small developer community through a series of ‘developer releases’ that brought us a lot of feedback, although we never actually launched an end-user runtime. That project fed into what is now AIR. The first codename for Central was ‘Mercury’ and then it became ‘Gemini’, following the names adopted by the US space project. The AIR project was codenamed ‘Apollo’ and, as I tell the team, it was the Apollo mission that actually made it to the moon! “So with AIR it’s the brand of the developer that you see – the Adobe brand doesn’t really appear, just as in Flash Player. We’ve widened the formats that we support, and of course HTML is a first-class citizen here. Rather than create a new HTML rendering engine we’ve adopted WebKit which is the open source engine used by Apple’s Safari browser. We have a great implementation of WebKit inside AIR, alongside the Flash and PDF engines. “On the performance side, we ended up spending around three years re-writing the Flash virtual machine. The result is Flash Player 9 which has a new virtual machine that includes a ‘just-in-time’ compiler that makes it about ten times faster than the previous version. “We are also heavily involved with ECMAScript which is the standard behind JavaScript and ActionScript. Flash Player 9 includes an implementation that supports features such as E4X (ECMAScript for XML), which is a way of using XML as a first-class data type alongside strings and integers. E4X allows you to assign a variable to a block of XML which makes it really easy to work with XML. We also incorporated regular expressions which allows you to pattern-match in a very efficient way. “We support strong typing too. Scripting languages usually use untyped variables, which means the runtime figures out whether the variable represents a string or an integer as it goes along. Untyped variables are easy to program but can cause challenges later in areas you don’t expect. Strong typing gets around those problems by informing the runtime of the type of the variable before the code is run. You can still use untyped variables but you can also use strong typing if you want. We also allow you to package up code in classes using a much stronger object-oriented programming model which really elevates the language to a much more sophisticated level and allows you to build much more sophisticated applications. All of this has been done through the standards process, and we’ve incorporated that standard into Flash Player 9. “What’s more, we’ve handed over our investment in the Flash virtual machine to the Mozilla Foundation as an open source project [called ‘Tamarin’] which means it will be incorporated into an upcoming version of the Firefox browser – probably version 4. This means that the same scripting engine will end up being used not only in Flash Player and AIR but also in the Firefox Web browser.” One possible issue here is that Firefox uses Mozilla’s own open source project Gecko to render HTML while Adobe has chosen WebKit, also open source but not managed by Mozilla, to perform the same function for AIR. Lynch acknowledged this and explains: “We looked hard at Mozilla and spent months deciding what technology we were going to use to render HTML in AIR. In the end it came down to the size of the HTML rendering engine and whether there was a mobile version or not, because it’s very important that these applications reach mobile devices. WebKit right now is a much smaller implementation, and there is already a mobile version which Nokia worked on. Nokia is an active WebKit developer, alongside ourselves, Apple and others. Our intention is also to look at integrating WebKit and Tamarin, which would then hopefully get adopted by Safari. “So version 1 of AIR basically integrates JavaScript as it is on the Web today with WebKit, and with the faster virtual machine that is used by Flash Player 9. After that we’ll move towards an engine that integrates WebKit with Tamarin. “Fortunately PDF also uses JavaScript, so we got lucky in that all three of the AIR formats chose the same scripting language! Back in the 1990s, when we were working on scripting for Flash, we almost created our own scripting language. Indeed with Macromedia Director we actually created a language called Lingo which was very popular within the Director community. However we decided to use JavaScript instead as it was becoming very popular on the Web. So yes, we do now have three JavaScript implementations and over time they will all become Tamarin, but it’s going to take a little while to get there.” One big difference between a Web application and an AIR application is the access that the AIR application has to system resources, such as the underlying file system. This has obvious security implications, as Lynch went on to explain: “With the Web browser, and with Flash running in the browser, there’s a security sandbox which prevents scripting code that has been downloaded from a Web site to do things like read or write the hard disk. You can store data in cookies, but it’s pretty limited. With AIR we’re allowing you to build desktop applications using Web technology, and desktop applications have capabilities you don’t have from inside the browser, such as accessing the file system or raising a notification. Our solution is to make sure the user knows what capabilities such an application is going to have when they install it. “For example, as you can see when you install Finetune Desktop from the Web site at http://finetune.com, you go through a series of dialogs that we’ve deeply usability tested to ensure people understand what’s happening. You’re told you’re installing an application from finetune.com. You’re told it’s been signed, so you can verify their identity if you want to. Your told that the application has the ability to read and write your hard disk – and we’ve made it a big yellow sign which our testing tells us that people understand. Just as with any native application, you shouldn’t go to an untrusted Web site and download what could be malicious code onto your computer. The security model in action: installing an AIR application from the Adobe Web site. You are informed that the publisher has been identified but that the application may put your computer at risk. “What we’re focusing on now is preventing third-parties from doing bad things to you through an AIR application that you’ve installed from a trusted source. For example, AJAX uses a technique called JSON (JavaScript Object Notation) which allows you to download JavaScript code from a server and have it execute locally in the client. It’s very convenient, and a lot of people are using it, but it’s fundamentally insecure because the downloaded script code can be injected by a third party. “For example, imagine you are building a Web blog aggregator and you’re simply showing the HTML code behind each blog post. Someone could have put some JavaScript into that HTML code which could be accessing the cookies on the client’s hard disk. That’s a security problem, and we’re becoming more active in working with other companies – including Yahoo! where the person who invented JSON works – to figure out a secure way for AJAX to access data without exposing you to such risks. “The risk is less if you’re working inside the browser because you’re running in a sandbox that doesn’t let you do too much damage, although you can still steal some information so there are still issues there. With AIR the risk is greater because AIR applications can read and write to the disk, so what we’re doing is creating a sandbox in AIR which prevents embedded script from using functions like eval() to call the AIR API. We’ve isolated the code in a space where it can’t do any damage, and we’ve then allowed developers to expose very specific connections between that ‘classic’ Web sandbox and the AIR API. You can, for example, create an API that lets the application add a new person to a contact list, without exposing all that AIR can do. “Version 1.0 of AIR will only support applications that install in the same way as native applications, but in future we’ll also support applications that you don’t have to explicitly install: where you just get a file, double-click it and it runs. Such applications will be isolated just as they are now on the Web. Because you haven’t gone through an installation process you haven’t been given the opportunity to trust the author, so they won’t be allowed access to your hard disk. “Examples might include a music album that you distribute as a file. It’s an AIR application so it runs outside the browser. It contains a nice multimedia presentation and has its own icon on the desktop, but you don’t have to explicitly trust it as it doesn’t require any special access to the client system. That’s something we’ll be supporting after version 1.0. We’re starting with the fuller security model in version 1.0 so that everyone can understand how AIR is different to the browser. We will be introducing the second security model later.” The discussion moves on to compare Microsoft’s strategy for the Web, embodied by .NET applications built around XAML and the Windows Presentation Foundation (WPF), and more recently Silverlight, with that of Adobe. Lynch is quick to point out that Silverlight and AIR are completely different: “Silverlight is a plug-in for a Web browser whereas AIR allows Web applications to be installed on the desktop, so a more direct comparison would be between Silverlight and our Flash Player. We’re certainly not resting on our laurels with Flash, particularly in the video area where Silverlight is really targeting Flash Player. Over 70 per cent of video content on the Web now runs on Flash, and Flash is Number One in terms of distribution. It has a wider reach than any other video player, including Windows Media. An AIR application can consist of a combination of Flash, PDF and HTML technologies, together with an object model and scripting through ECMAScript. “A more appropriate comparison would be between .NET applications and AIR, but .NET applications don’t run across multiple operating systems – you can’t run a .NET application on Mac OS X, for example. AIR enables you to install your application on multiple operating systems, which is something Microsoft is not particularly motivated to do as Microsoft likes Windows and hopes people keep using Windows. We’re motivated to make sure our customers’ content works reliably regardless of the client operating system. “We’re also focused on not making our users have to buy new computers. When a new operating system comes out, such as Windows Vista, there’s a lot of attention on persuading you to get a new computer. There’s an ecosystem in place that’s trying to motivate you to upgrade both your operating system and your hardware. “We’re not focused on making you go and buy a new computer. We make sure that Flash, for example, runs on operating systems that go back years. We’ve got a lab full of computers, many of them really old machines, to make sure that our client software works reliably across them. That’s how we differentiate our runtimes, and our customers tell us that’s an important factor. When they create interactive media they want to make sure that as many people in the world as possible can view it. “The other comparison is between WPF and AIR. WPF is a framework: a set of APIs for building an application. AIR is a runtime that enables things to run. You can use many different frameworks to build an AIR application, so the comparison with WPF would be against those other frameworks. “One of those is Flex Framework. This is a great framework and we’re moving it to open source. The source code is already published in the SDK; we are going to have an open bug database; we’re going to create a governed process for people to submit code. Flex Framework is designed for building really great RIAs. It’s very expressive: it takes full advantage of Flash so that you can work with audio, video and have great interactivity. Furthermore, unlike WPF, it runs across operating systems. “Alternatively there’s the many AJAX frameworks such as Dojo, ExtJS or YUI from Yahoo! There’s a lot of innovation happening right now at the framework level in the AJAX community – a lot more than I think we’re seeing with WPF.” An AIR application can interact with remote systems through Web Services and Flex Enterprise Services, and will run on Windows, Mac OS X and Linux operating systems. Another player in this field is Google with its Gears plug-in which allows you to build Web applications that can work offline. Lynch explains: “Google Gears is basically a plug-in for a browser that uses the open source database SQLite to provide local storage so you can work offline from within the browser. We are actually working on providing the same functionality in AIR, and by coincidence we’re also implementing it with SQLite. As a result we’ve agreed to cooperate and are working to align the APIs across Google Gears and the local database support in AIR so that it will be easier for developers who are using an AJAX framework or Flex to take advantage of local storage – whether the application uses Gears to run in the browser, or runs on the desktop through AIR. “We see Gears as complementary to AIR. Gears adds more functionality within the browser, but it’s not the full functionality that AIR provides in terms of allowing access to local processes, being able to raise notifications, appear on the Start menu as an application and so forth. “Fortunately we both picked the same database engine, but unfortunately we took completely different approaches from there on: AIR has an object-oriented asynchronous API while Gears has a more procedural synchronous API where you make a call and then wait for it to return. “I think initially what you’ll see is that we combine these at the framework level, as we’re both already a long way into version 1.0 of our respective low-level APIs. However the frameworks on top, such as Flex and Dojo, will present a consistent API to developers. I think that’s going to be the first step, and then over time we’ll see what people want us to do to the low-level APIs and then you may see more alignment there too.” Following on from this is the more difficult question of data synchronisation between the client and server in an environment where the application must work both online and offline. “We have a solution to that in our LiveCycle product. LiveCycle ES gives you a simple way to connect data on the client with data on the server. The model we have right now with Flex and LiveCycle is that you change the data on the client and it automatically replicates to the server and to other users who are connected to the server. Where there’s no conflict it works automatically. Where there is conflict it’s dealt with by conflict management handlers that run on the server and work out what to do. “You have to write these conflict management handlers yourself but we provide a lot of tools and information to help, such as time-stamping, so that you can resolve conflicts with your own business logic. Alternatively you can surface the conflict to the end user and ask them to choose between the two versions.” LiveCycle is a server product with a price tag, however many of Adobe’s products are available free of charge. Lynch took the opportunity to clarify the company’s business model: “There are some areas where the frameworks are completely free, and there are some areas where we try to generate revenue, and that will shift over time. Right now synchronisation is a hard problem. You can do it yourself if you want to, but we’ve spent years with very sophisticated developers working on an enterprise-class solution that surfaces for the developer through a very simple interface. I think we’ve done a great job. I think it has value. We’ll see whether people want to buy ours or choose something else. “It’s basically a balancing act that we perform as a vendor. We’ve got free runtimes for end users and our frameworks are becoming not only free but also open source. You don’t have to pay Adobe anything to use Flex Framework – you can make a great RIA for free using Flex Framework, Flash Player and AIR. “What we do sell are tools, so we’ve got a great tools business going around Flex Builder and Creative Suite. You don’t have to use our tools though – you can use anybody’s tools and there are other people making software that works with our platform. “On the server side, some of our solutions will be free and some will be sold as products. It’s a balancing act between having a great environment where people are interested in participating, and providing software that people find valuable enough to buy.” Taking over the operating system Returning to Flash and AIR, there is an opportunity here for these technologies to take over more of the functions of operating system itself. However Lynch does not see this as a direction in which Adobe should go: “I think operating system functionality is pretty well addressed already between Windows, Mac OS X and Linux, and we support all of those operating systems. I don’t really see a need for a new operating system at the kernel level, handling networking, storage access, rendering to the screen and such like, as those capabilities already exist and work pretty well. “Where I do see the need, though, is in continued innovation of new layers that get put on top of older layers. In the very early days of computing we were toggling things into computers with switches, and then people started adding high-level languages, compilers and graphical user interfaces, all layered on top of previous technologies. “The new layer we see right now stretches across operating systems to deliver for applications what is available today for content on the Web. It doesn’t matter what machine you are using, you can browse a Web page. We’re trying to make that same promise come true for applications. Regardless of what operating system you have, or what machine you have, you can run that application. We see that as another layer that sits above existing operating systems. It doesn’t need us to re-invent the operating system to do that. “We’ve been doing cross-operating system development for a long time. When Web browsers appeared we did cross-browser development. One of the strengths of Dreamweaver, for example, is that it can create pages that work across browsers reliably. That’s part of the soul of the company: being able to work ‘across’ things and making the experience consistent. With devices it’s the same thing: with mobile phones, for example, we do it with Flash. We’re taking that same approach to operating systems.” Time-line versus state development A potential problem for Adobe is that Flash development has traditionally been based around time-lines and storyboards, while RIAs need to be more aware of state. Lynch agrees: “In the early days our thinking was to extend the Flash authoring tools to support RIAs. It seemed to make sense, but we soon learned that it meant changing the Flash model too much for the Flash developer. Flash is focused around frames and time-lines, which are foreign concepts for the application developer. After all they’re not animating; they’re creating an application. “So we started looking at the difference between animations and applications from a tooling perspective, which brought us to the concept of state. Applications are not animating from one key-frame to another; they are moving between states. An application might go from log-in screen to list view screen, and from list view screen to detail pane. These are the different states of the application. There may be cinematic effects that take you from one state to another, and they may involve animation, but that’s secondary to considerations of which state the application is handling. So we built states into a new tool called Flex Builder, which we created specifically for building RIAs, enabling Flash to focus more on interactive multimedia design.” Lynch acknowledges that handling complex user interfaces which have multiple states can be difficult with Flex Builder as it stands: “There’s an opportunity for us to make state management more powerful, absolutely. We have an early version of state management right now but I think the concept is right and we’re going to keep investing in it to make it more robust.” User interface design in the Wild West Lynch moves on to consider the design of user interfaces: “The other problem is how to involve both designers and developers in creating those user interfaces. Here we’ve done a lot of work already inside Creative Suite 3. You can use Adobe Illustrator CS3, for example, to draw a user interface with vector graphics, and then bring the result inside Flex Builder as a skin. We’re working on a lot more of those types of connections between our tools to enable that kind of workflow. We’re investing a lot in that area.” This raises a more fundamental issue. A Windows user knows how a Window application should look and feel; a Mac user knows what a Mac application should look like and how it should behave. However no-one knows, as yet, what an AIR application is going to look like. Lynch agrees: “User interface design on the Internet is the Wild West right now, and we’re bringing that to the desktop with AIR. What’s happening now is similar to the early days of the PC when word processors like WordStar and Ami Pro used different control sequences. Even copy and paste was different depending on the application you used. It took years for that to solidify into common patterns. “Of course it did happen, but it happened faster on the PC than it has on the Web. We’re now more than ten years into the Web and that consolidation still hasn’t happened. With the desktop computer it started to happen with the Apple Macintosh which came out around 1984, only some five years after the PC revolution started. The Web is taking longer. I think that’s partly because Web designers have relied on the browser to handle many of those activities, but I also think it’s down to the frameworks. “There are too many frameworks around right now, but I think there will be a shake-out. Developers want to gain skills in the frameworks that are more popular and that should naturally lead to a reduction in numbers. After all, you don’t want a framework on your resume that only ten people in the world are using – you want to be skilled in a framework that is widely used. That shake-out could result in more consistent user interfaces on the Web. “Hopefully Flex Framework will help establish a consistent look and feel for RIAs. You can ‘skin’ Flex applications – change the colours and things like that – to establish your own brand, but scroll bars look like scroll bars and list boxes sort as list boxes should, so there’s a lot of consistency there. We’re trying to balance between expressiveness of brand and consistency of interaction. That’s the approach we’re taking right now.” Of course AIR applications run directly on the desktop, so arguably an AIR application running under Windows should look and feel like a Windows application, while the same application running on an Apple Macintosh should look and feel like a Mac OS X application. Here Lynch disagrees: “Our bet is that, rather than making desktop applications, people are making Web applications. We’re betting on that being a general trend. This is especially true within companies: where you might have once used Visual Basic to create a desktop solution, these days you’re looking for a Web-based solution. It’s easier to host, deploy and maintain. “What we’re doing is enabling Web applications to make a full circle back to the desktop. People are still going to make native applications when it comes to high performance games or big packages like Microsoft Office, but the trend is towards Web applications. “What gets me excited is that it brings back the thrill of the early days of making applications. It’s really easy to make an AIR application. You don’t need to use all these huge tools: instead you can use lightweight Web tools and make an application in a couple of days. You can get started with these technologies without buying anything. Flash, AIR and the SDK are all free, and you can use the free editor of your choice – there’s a lot of development environments out there that are free. As you get more sophisticated you might want the benefit of Flex Builder or something like that, but that’s still not expensive for a professional, and we do have educational pricing for students.” Adobe AIR and related technologies such as Flex can be found at http://labs.adobe.com. The full range of Adobe products, including Creative Suite 3 and Flex Builder 2.0, can be bought from www.greymatter.com/adobe/. How AIR compares with Silverlight As Lynch explains, the AIR runtime allows applications built using Flash, PDF and Web technologies to be downloaded from the Internet and run directly on the desktop. Silverlight, by contrast, runs applications built using Windows Presentation Foundation (WPF) and .NET technologies within the Web browser. Otherwise they are fairly similar, running on both Windows and Mac OS X with Linux versions to come (through the open source ‘Moonlight’ project in the case of Silverlight). Both also allow applications to access data stored on the user’s hard disk. In the case of AIR, it looks as though applications are able to access the local file system with all the rights of a full-blown Win32 application. Users are warned of the implications when they download such an application but are given a simple choice of ‘install’ or ‘cancel’. Silverlight 1.1 (currently in alpha) also allows applications to read and write files to the hard disk, but only within an Isolated Storage area that is unique to each application. This is similar to the ‘local shared objects’ mechanism employed by Adobe Flash Player. In addition, Silverlight 1.1 applications can pop up a File Open dialog which allows the user to pass it a file from the hard disk, but at no time does the application have any idea where the data is actually stored. This is an important difference. A Silverlight 1.1 application would not be able to search through your file system for email addresses or passwords. An AIR application presumably could. It is very early days yet, but it will be interesting to see how the more secure model of Silverlight limits the capabilities of its applications in contrast to AIR.
The other important difference is of course that Silverlight applications run within the browser whereas AIR applications run directly on the desktop. However, Silverlight applications are essentially .NET applications, and .NET applications are perfectly capable of running on the desktop (indeed Isolated Storage is a .NET 3.0 technology) so presumably it would be fairly trivial for Microsoft to put together a variation of Silverlight which allowed applications to be run directly from the desktop. Such a technology would of course compete directly with AIR.
Shortly before its MAX 2007 conference, Adobe invited a group of technology reporters to its San Francisco office. Here we met Kevin Lynch who joined Adobe from Macromedia as Chief Software Architect. Lynch heads the Platform Business Unit which is primarily concerned with Adobe’s client technologies and programming model, making him directly responsible for Flash Player, AIR, Acrobat PDF, the Flex framework and Flex Builder.
Click here for our Privacy Statement. Copyright © Matt Publishing. All rights reserved. No part of this site may be reproduced without the prior consent of the copyright holder.
