OpenLaszlo is a fascinating project, and got even more interesting when they went meta, and allowed you to general Ajax applications as well as SWF ones. The 4.1 release is a big one, as it brings full parity to the Ajax side of the house:
OpenLaszlo 4.1 is a major release bringing full support for both the DHTML/Ajax and the SWF/Flash platforms. It also includes over 800 bug fixes and a significantly improved documentation suite.
OpenLaszlo 4.1 has been fully-qualified across the following browser/platform combinations: Safari3/OSX, Firefox2/OSX, Internet Explorer 7/WinXP, Firefox 2/WinXP, and Firefox 2/Linux. We have tested the full suite of demos, samplers, and example applications with the requirement that, when possible, DHTML applications behave the same as their SWF counterparts.
OpenLaszlo 4.1 is now the recommended release for all developers on all platforms, and current users of OL 3.x and 4.0 should investigate upgrading to this new release.
Preliminary support for SWF9 is included in this release but has not been enabled in the developer console.
Google and Adobe have been working on improving the indexing of Flash applications. In the past we could simply look at the SWF files and try to grab strings out of them, but there was zero context.
To go further Google uses the SWF Searchable work from Adobe to be more of a ‘human’ actor on the application.
This is what it doesn’t do:
Googlebot does not execute some types of JavaScript. So if your web page loads a Flash file via JavaScript, Google may not be aware of that Flash file, in which case it will not be indexed.
We currently do not attach content from external resources that are loaded by your Flash files. If your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.
While we are able to index Flash in almost all of the languages found on the web, currently there are difficulties with Flash content written in bidirectional languages. Until this is fixed, we will be unable to index Hebrew language or Arabic language content from Flash files.
This is good news for all rich applications. One of the common worries when it comes to richer application development is “what do search engines see” and we sometimes see people go back to the simpler world just to make that happier. With the search engines stepping up themselves, we can go back to writing applications that make sense for our human users, and hope that the computers catch up. Of course, we always have to do so in a practical way.
Adobe AIR, the SDK & runtime which has become the popular choice for building desktop-enabled web applications, has been updated with enhanced support for internationalization. With AIR v1.1, Adobe has bumped the number of supported languages to ten including Japanese, Chinese, Russian, Spanish & Brazilian Portuguese and included support for double-byte keyboard input.
Other notable enhancements include:
Support for 64-bit editions of Microsoft Vista
API enhancements to report disk space availability
Ability to determine if the OS can support transparent windows
With Silverlight 2 aimed square at Flash, many of us were interested to see what Flash 10 would have in store for us. We get our first glimpse with the Flash 10 prerelease, code named “Astro”.
I installed the prerelease and recorded the demos so you can take a quick peak:
The biggest feature in my mind, is true 3D:
3D Effects - Easily transform and animate any display object through 3D space while retaining full interactivity. Fast, lightweight, and native 3D effects make motion that was previously reserved for expert users available to everyone. Complex effects are simple with APIs that extend what you already know.
There are other new features too. At a high level:
Custom Filters and Effects - Create your own portable filters, blend modes, and fills using Adobe Pixel Bender, the same technology used for many After Effects CS3 filters. Shaders in Flash Player are about 1KB and can be scripted and animated at runtime.
Advanced Text Layout - A new, highly flexible text layout engine, co-existing with TextField, enables innovation in creating new text controls by providing low-level access to text offering right-to-left and vertical text layout, plus support for typographic elements like ligatures.
Enhanced Drawing API - Runtime drawing is easier and more powerful with re-styleable properties, 3D APIs, and a new way of drawing sophisticated shapes without having to code them line by line.
Visual Performance Improvements – Applications and videos will run smoother and faster with expanded use of hardware acceleration. By moving several visual processing tasks to the video card, the CPU is free to do more.
If you delve into the release notes you see features such as:
Context Menu — Developers now have more control over what can be displayed in the context menu through the use of ActionScript APIs for common text field context menu items, supporting plain and rich text. The clipboard menu provides access to the clipboard in a safe and controlled way, and you can write handlers to paste text.
File Reference runtime access — Bring users into the experience by letting them load files into your RIA. You can work with the content at runtime and even save it back when you are done through the browse dialog box. Files can be accessed as a byteArray or text using a convenient API in ActionScript without round-tripping to the server. You no longer have to know a server language or have access to a server to load or save files at runtime.
Dynamic Streaming — Always show the best video possible with streams that can automatically adjust to changing network conditions. By changing bitrates, you can keep your user engaged and avoid start-and-stop video. Dynamic streaming provides the best possible experience to the video consumer based on their bandwidth environment. Video streams over RTMP from intended future releases of Flash Media Server can dynamically change bitrate as network conditions change. Quality of Service metrics, exposed via ActionScript and providing real-time network or CPU information, allow developers to take control of the video playback and adjust the streaming experience accordingly. This feature is part of Flash Player 10 but will only be available with intended future releases of Flash Media Server.
Text Layout Components — An extensible library of ActionScript 3.0 text components, coming in future to Adobe Labs, provides advanced, easy-to-integrate layout functionality that enables typographic creative expression. Layout and style text with tables, inline images, and column flow through components that are compatible with both Flash and Flex, all while getting the benefits of the new text engine. Rich text components allow designers and developers to flow text and complex scripts, such as Arabic, Hebrew, and Thai, across multiple columns like a newspaper, around tables and inline images, from right-to-left, left-to-right, bi-directionally, or vertically. Selection, editing, and wrapping of text are handled as would be expected for the different layouts.
It is also interesting to put this into context with JavaFX, which was hyped last week at JavaOne (without a release yet). There were some nice demos, such as 3D video globes, and a few people said “Flash couldn’t do that. No decent 3D or hardware acceleration.” The bar keeps rising for all.
I start with an aside; This must be the most un-Adobe website I have ever seen. Below is the entire website for the Open Screen Project:
As the site says, the details are in the press release which says:
The Open Screen Project is working to enable a consistent runtime environment — taking advantage of Adobe Flash Player and, in the future, Adobe AIR — that will remove barriers for developers and designers as they publish content and applications across desktops and devices, including phones, mobile Internet devices (MIDs), and set top boxes. The Open Screen Project will address potential technology fragmentation by enabling the runtime technology to be updated seamlessly over the air on mobile devices. The consistent runtime environment is intended to provide optimal performance across a variety of operating systems and devices, and ultimately provide the best experience to consumers.
The cool part of all of this, is the fact that the old restrictions on the SWF and FLV specifications are now in the past. The restrictions used to say that if you read the SWF spec, you couldn’t build something that would run SWF files. So, could build an editor, a tool, but not a runtime in anyway.
This has just changed by:
Removing restrictions on use of the SWF and FLV/F4V specifications
Publishing the device porting layer APIs for Adobe Flash Player
Publishing the Adobe Flash Cast protocol and the AMF protocol for robust data services
Removing licensing fees - making next major releases of Adobe Flash Player and Adobe AIR for devices free
With news of OpenJDK coming at JavaOne next week, we will see changes with the most deployed runtimes out there. Just the beginning of the path towards an open source Flash.
I keep thinking of the JVM playing FLV/SWF, and the Flash player grokking .class files!
Ryan Stewart of Adobe and I got to give a joint talk this morning that covered Adobe AIR, Gears, and how you can build offline and desktop applications right now.
Obviously, Ryan gave an overview of AIR, and I did the same for Gears. We also discussed reasons to be excited about Web development, some of the ideas that are out there in the community, and how AIR and Gears can be seen as complementary.
We had some requests to put the slides online, so here they are below. I know it is hard to peruse slides without the talk over, but just think of it as a fun exercise to wonder what we said :)
Adobe AIR for JavaScript developers provides an introduction to Adobe AIR for developers using interested in building AIR applications using JavaScript, HTML and CSS. The book has been updated for the latest and greatest, and is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. Yup, the book is free.
It is written by members of the AIR team itself, so you know that the information will be correct. Very smart of them to release it to the public like this. Congrats on finishing it guys!
Adobe continues to expand its support for the Linux platofrm by announcing the release of the Adobe AIR runtime for Linux. This expands the ability to deploy AIR desktop applications to the three major operating systems (Windows, OS X & Linux) while still using the standard web technologies developers have become accustomed to.
This release of AIR for Linux will be supported on the following distributions:
RedHat Desktop Linux 4
RedHat Enterprise Linux v5
Novell Desktop Linux 9
SUSE Linux Enterprise Desktop 10
Ubuntu 6.06
and the following features are available with this release:
Runtime/Application Install/Update and Uninstall.
HTML Loader with JS support to render HTML within AIR applications.
Local Database APIs
File system support with support for user folders like Desktop/Documents etc.
Desktop Integration with Drag and drop, clipboard support
Windowing support with System chrome none/standard
Basic transparency
Menu support with context menu, menu bar, pop up menus and menu events.
Networking
Network change detection (Event.NETWORK_CHANGE )
System wide idle detection (userIdle Event)
NativeApplication APIs
Capabilities (OS) API
Mouse events
Detection of running application (InvokeEvent.INVOKE)
Adobe has posted a FAQ to provide detailed information about this new product release.
Adobe Joins Linux Foundation
In addition to releasing AIR for Linux, Adobe has also joined the Linux Foundation to “collaborate on the advancement of Linux as a leading platform for rich Internet applications (RIA) and Web 2.0 technologies.
“Adobe’s decision to join the LF is a natural extension of its commitment to open standards and open source, which demonstrates its leadership and foresight in the software industry,†said Jim Zemlin, executive director at The Linux Foundation. “Adobe’s membership will contribute to our goal of increasing even more application development on Linux with a specific emphasis on Web 2.0 applications.â€
“Adobe delivers key RIA technologies for Linux users, such as Adobe® Flash® Player and now Adobe AIRâ„¢, to deploy RIAs in the browser and on the desktop,†said David McAllister, director of standards and open source at Adobe. “The Linux Foundation is a valuable resource, providing a forum where we can work with the community to ensure Adobe RIA technologies are compatible across the Linux software platform.â€
This announcement further solidifies Adobe’s commitment to the linux community, having already released server-side products that work natively on the Linux platform.
The launch of Adobe Photoshop Express has been much anticipated. We are seeing the move of a large software company going from desktop to Web for a major application.
I am a big fan of Picnik and for awhile was using it quite regularly, so I wanted to see how they compared.
It seems like Photoshop Express is pretty limited and seems very much focused on taking images, putting them online, and doing little touch-ups. One of the things that I am always doing is taking a picture and adding text and shapes to it, and this isn't available, so I kinda don't know when I would use this other than for simple cropping and resizing.
The interface is sleek and Flash-y but somehow doesn't feel as nice as Picnik to me.... I don't know why.
We all have bits of reusable code that we store in some fashion. These snippets prove to be invaluable at helping to not "reinvent the wheel" so storing them in a safe and convenient place is important.
The MooTools team wants to make it easy for you to store your snippets easily through the use of their new Adobe AIR application, Snippely. Using the MooTools JavaScript library and the AIR SDK, Valerio Proietti and Tom Occhino created a desktop application that allows easy storage of both code snippets and notes about the code.
When we were thinking about what type of application to make our AIR playground, we tried to think of something that we'd want to use ourselves. Valerio and I are notorious for storing countless bits of code in all sorts of different languages all over our hard drives, and thought it would be nice if we had a central place to store and organize those bits of code. We came up with the idea of 'snippets', and an application called Snippely.
The nice thing about this is that they've designed Snippely so that you can organize snippets by groups and that a snippet entry can consist of multiple snips or notes.
Finally, those looking to get into AIR development will certainly benefit from the fact that the Moo team has released the app as an open source project under an MIT license. The code for Snippely is hosted on Google Code and is available for you to review.
The intersection is where Kevin answers about Silverlight going offline:
Well, what about an offline Silverlight capability? Would that do it?
In order to do it well, your heart has to be in it. And if you look at what we're doing right now with our technologies like Flash and AIR, we're making sure they work reliably across operating systems. So that means Mac and Windows, but also Linux. We're releasing Flash Player now simultaneous for Mac and Windows. It took us a while to get their and now we're doing that, and it's the same core code.
If you look at what Microsoft is doing with Silverlight, they're not actually building the Linux version off the same code base. It's a new code base, which is unlikely to be compatible with the other code bases because it's just not built the same way. So there'll be different idiosyncrasies and we know that will be a problem. So we're really taking a passionate approach to reliability across OSes. And you really have to have that as the core essence of what you're doing or it won't really work that well.
Microsoft says it is coming:
Microsoft does not currently have specific plans to bring offline capabilities to Silverlight, but it's something it will eventually do, said John Case, general manager in Microsoft's developer division.
"It's something that we will want to do," Case said in an interview on Monday. "Eventually, customers will expect us to do it."
Darryl has a lot more meat in his article which asks:
As far as AIR deployment, why not just put it in Flash?
But isn't the Flash Player only about a 500K download? Couldn't you just up that a little, as you said bandwidth is increasing?
When are you planning to, or are you in fact planning to, open-source Flash?
So you said Tamarin was a first step. Does that mean you're going to do a second, third, fourth step and so on until Flash is fully open source?
I've watched this ongoing competition between Adobe and Microsoft. What do you think they need to do if they want to one-up AIR?
Well, what about an offline Silverlight capability? Would that do it?
So how do you address the criticisms about security with AIR?
You mentioned support for Linux with AIR. Can you expand on the importance of Linux for you guys and where you're headed with it?
Who is better at designer/developer workflow, Microsoft or Adobe? Do you concede that to them?
What's the status of the Adobe relationship with Google about Google Gears?
The value of this document is that it gives hints to us Ajax folk as we develop applications running on AIR. The main message is that the security sandbox that AIR gives you has subtle side effects that you need to be aware of.
For example, note the function(){} wrapper in the AIR-specific code:
There are other small issues such as not having eval() available post-load that you can see in the changeset. If you run into something as you develop your Ajax application in AIR, you have another resource to check (as well as the Adobe resources of course).
As well as making changes to get Dojo working in AIR, SitePen also added support for some of the AIR APIs themselves, including:
AirFileStorageProvider
The AirFileStorageProvider store the data in flat files in the app-storage directory. For example, a key of “MyKeyâ€, value of “Hello World!â€, and namespace of “MyNamespace†would create the file app-storage:/__DOJO_STORAGE/MyNamespace/MyKey which contains the text “Hello World!â€. This storage provider allows for large amounts of data to be stored. Not only can strings be stored, but also objects thanks to AIR's serialize/de-serialize functionality. On the downside, data is not encrypted on disk. It would be trivial however to encrypt the information using dojox.crypto before storing the data.
AirDBStorageProvider
The AirDBStorageProvider leverages AIR's embedded database. When the provider is initialized, a database file is created in the app-storage directory and the Dojo storage table is created. The table holds the namespace, key, and value. This provider is similar to the AirFileStorageProvider in which it can store large amounts, but it cannot store serialized objects because there is no way to de-serialize them due to eval() being unavailable post-onload. The database file is not encrypted, but you could encrypted the data using dojo.crypto prior to storing the data. One advantage of the AirDBStorageProvider is there is only one file written to disk whereas the AirFileStorageProvider writes a file for each key/value.
AirEncryptedLocalStorageProvider
The AirEncryptedLocalStorageProvider uses AIR's encrypted local data store functions. Data, such as passwords, will be encrypted when being stored and decrypted when being retrieved. Similar to the AirEncryptedLocalStorageProvider, objects cannot be stored because they cannot be
de-serialized with an eval(). One limitation of the AIR's encrypted local data store is it does not provide a way to enumerate keys. To solve this, the AirEncryptedLocalStorageProvider creates a registry using AIR's encrypted local data store to track the namespaces and keys.
Dojo adds it's name to the list of Ajax frameworks that are ready for AIR work. Since Dojo has a large coverage of features (especially via the dojox.* components) it can be well suited for larger desktop apps.
After recently installing Snitter, I have to say I've become a bit of a fanboy of Jonathan Snook. The guy just produces some good stuff. So when I saw that he announced a new AIR application, I had to get it installed and checked out.
While Snoto (ya know, Snook, Snitter, Snoto) isn't as polished as Snitter, it's not meant to be. Jonathan has released this as a foundation for those that want to understand how to build AIR applications.
The goal of this is not to create a Flickr client that "does it all". It was put together as a reference application for anybody interested in learning more about Adobe AIR. Snoto has been released under a Creative Commons license, so it's available for you to take and extend how you wish. The link to the source code is included at the bottom of the Snoto page.
This is a great help to many developers as interest in Adobe AIR has skyrocketed since the release of AIR v1.0. MooTools developers should be especially pleased with the fact that Snoto was built using the MooTools JavaScript library, specifically because of the ease with which AIR applications can be developed without jumping through hoops. While other JS libs are now updated to work with AIR's security model, MooTools was the first to be compatible even during the beta process.
Again, the biggest benefit is to those that want to learn about working with the AIR API:
From the AIR API, I haven't gone hogwild but rather kept it simple. You can see use of nativeWindow, context menu and EncryptedLocalStore.
Having access to Webkit made styling the interface very straightforward. Like Snitter, it's a combination of background images, PNG images, and some CSS3/border-radius to round things out.
The Snoto page has been setup with an AIR install badge which should make it easy to check it out.
Expanding on the project, Ted Patrick, Adobe technical evangelist, said the technology would allow for cross-compiling existing code from C, C++, Java, Python, and Ruby to ActionScript. This would enable components written in those languages to be integrated into a larger project, Patrick said. "That code becomes perfectly portable into our application platform," he said.
For example, an alternative PDF renderer providing a lighter version of PDF could be cross-compiled, and the Flash Player could read it and display PDFs.
"Right now, everything has to be written in ActionScript or our lower level byte code languages," said Patrick.
In Flash Player, everything has to compile down to SWF byte code, Patrick said. The byte code language inside SWF is called ActionScript byte code.
Of course, this has been talked aboutquite some time ago. As Tamarin grows up and becomes a solid VM, we are likely to see the polyglot come to being in full force.
To coincide with the release of Adobe's AIR v1.0, the Ext team released v2.0.2 of the Ext framework with enhanced support for the new AIR runtime. The Ext and Adobe teams collaborated during the AIR beta process to ensure that support for the updated AIR API and security sandbox would be available to Ext users from day one.
To demonstrate Ext's AIR capabilities, founder Jack Slocum went about updating the Simple Tasks application he initially created during the early AIR beta process.
Making extensive use of the newly updated AIR API, the Ext team enhanced the Ext.air package to handle such functionality as:
Managing native windows, event listeners and automatic state management for the windows.
Use of the new synchronous database access introduced in AIR beta 3.
Native drag and drop and clipboard access.
Playing sounds.
Minimizing AIR applications to the system tray.
Adding an icon to the system tray is now a trivial task as can be seen in this code sample:
