All 16 entries tagged Adobe

David Tucker's 10 common mistakes when building AIR applications

David Tucker recently posted an article on the Adobe Developer Centre citing 10 common mistakes with developing AIR applications and how to avoid them. I thought I’d quickly compare David’s points against my current AIR project, a remote file-system/transfer manager:

1. Making an application platform specific

David primarily refers here to the UI/UX differences between platforms, but I also found it essential because I encountered significant performance differences with some file system operations (icon getters, mostly), which were fixed with the help of the Flex Profiler. At the moment we can’t test it on the Linux Alpha, but hopefully we’ll be able to try that soon.

2. Not including update capability in an application

We included this as soon as the framework became available and it works very well – whenever the application starts it can check for a newer version of itself, and the user has control over whether to update or not.

3. Changing the application ID after an app has been released

Oops – I ran into this early on; changing the application ID means the update framework will break, amongst other things. Changing the name of your application halfway through the project also risks confusion.

4. Not planning for offline support

Our application relies on a live connection to work, but it does use AIR’s network monitoring APIs to check for a valid connection at startup and then continually monitor connection status, and warns the user if connectivity is lost.

5. Not thinking in AIR

I didn’t find this too difficult – some things were relevant and others weren’t. There have often been moments where I’ve discovered a capability and thought “I didn’t know it could do that”; we do use the application storage directory and the user’s temp directory for file transfers though, and the File , FileStream and FileReference classes were the key to making it work.

6. Using custom chrome to create confusing interfaces

We used the standard chrome, but most of the AIR applications I’ve seen that use custom chrome have done so pretty effectively. One of the most powerful aspects of AIR is that you have very fine control over the UI. As a counter to this though, in addition to the native window chrome there are valid use-cases for having access to native system controls, like toolbars, buttons etc. – platform UI differences can make this even more acute, so I’d like the ability to use standard UI elements where appropriate.

7. Not using the seamless install badge

We implemented this early on – having an install badge makes installation a snap for most people and like the update framework it works well – installation of the AIR runtime can be managed automatically and so far the whole thing has worked fine, except when I broke it myself by not updating the right fields in the updater XML file.

8. Not encrypting sensitive data

Not relevant for this application (yet) – we don’t store any information other than the last file-space used, using a standard SharedObject. AIR has an EncryptedLocalStore for this kind of thing though.

9. Not preserving native interaction

As yet we haven’t got a complete set of keyboard interactions in place (e.g. cut, copy and paste) but some are there. The core interaction type is dragging and dropping, and Flex/AIR gives you control over the process by splitting this action into discreet event-driven stages, so providing visual feedback about whether a drag/drop is allowed can be controlled via your own logic. Something I’ve not yet overcome is how to work with internal and external drag handling at the same time – I may be wrong here but so far it looks like the external drag management only knows about drag in/out operations at the application level, not at the component level, so I need to work on how to use the external drag management to allow items to be dragged into components with the same level of control as the internal drag manager.

A more difficult problem is when a standard component doesn’t quite mimic the operation of a native system control – take the Tree for instance, which will close when its DP is refreshed – in situations like these its nearly always possible to closely replicate the native behaviour by extending or over-riding the component default, but there can be some work involved when finding out what to do. At this point I’ll thank Peter Ent and the excellent Flex Examples Blog for their invaluable resources; they saved me a lot of time.

10. Assuming performance doesn’t matter outside of the browser

In this case, the performance issues highlighted when checking across platforms also highlighted the importance of using the Flex Profiler, the net result being a five-fold increase in speed on OSX and smaller but useful increases on Windows, plus reduced memory usage. The original performance on OSX was bad enough to almost make the application unusable, but after identifying and fixing/working around the problems, the application performs similarly in Windows and OSX.

Thanks to David for writing about what to avoid – fortunately most of them we’d already come across and fixed, so that’s good!

Steven Carpenter : 28 Aug 2008 13:04 |  Tags: Adobe Air Development Flex Rich Media |  Comments (1) |  Close comments |  Report a problem

Flash SEO, Adobe manoeuvres

Kudos to Adobe, Google and Yahoo for creating the mechanism for Flash content to be indexed on search engines. With one or two reservations (like how to distinguish between application content and a site) I think this is another significant move towards maintaining the ubiquity of Flash. It seems as though Adobe is steadily, but impressively quickly, removing piece by piece the most-cited drawbacks of Flash. Some of the most significant announcements (in no particular order):

• H.264 video support
• Open-sourced Flex SDK, BlazeDS
• Opened access to Flash Player APIs
• 3D support (thanks to Papervision, Away3D etc.)

Obviously it doesn’t take a genius to work out that, in part, Adobe has had to make some of these moves – HTML5, advances in Javascript and browser technologies promise or already offer many features that up until now Flash had to itself; the canvas and video tags in HTML5, DHTML effects, processing.js, SproutCore, the list goes on – it was inevitable that some of Flash’s functionality would be adopted and integrated into other technologies, but I think that those people who still maintain that they ‘hate Flash’ should still agree that it has been a primary driver of change on the web. This is particularly true in three areas; animation, user experience and video. Flash may responsible in their eyes for evil banner ads and inaccessible sites/UIs, but those things are created by people, and a technology that provides a degree of creative freedom is open to abuse – there are plenty of bad DHTML sites around and more than a fair share of annoying DIV-based floating ads out there already, but there is also a great number of fantastic and successful experiments in user interface design, animation and application experience. Flash has enabled developers to do things on the web they could not have easily done by other means, and those people that attribute bad practice to Flash are both ignorant and in for shock if they believe the same things won’t happen when other technologies catch up. Up until now it’s been far too easy to blame Flash, when Flash isn’t the problem. Use it where it works, not where it doesn’t (like whole sites).

In addition to the technology itself, Adobe has provided the means to develop and deploy it effectively, with the Flex SDK and FlexBuilder. Personally I have no objection to proprietary technologies when they a) work, b) don’t break anything and c) positively drive change and allow people to do things that standards-based technologies often take much longer to enable (and often not quite as well). Flash and Flex won’t be the standard, they will peacefully co-exist with other technologies (along with man, and fish); a single unified standard just isn’t possible in a competitive world, nor is it always desirable. Someone has to innovate, and attacking Flash (or Apple come to to think of it) for being proprietary is like attacking Ferrari for making a better sportscar (and charging for it). If it enables you to go faster, better, and (similar to Java and JS) is on 90-something% of desktops, who can blame Adobe for adding features and functionality that will maintain or increase edge and adoption? And at the same time if it is making key components of its platforms open, regardless of motivation, it’s A Good Thing*. So long as the standards do catch up, it’s fine.

There is I think, one thing left to do at the moment, the final hurdle as I see it – accessibility. It’s kind of in there, but if Adobe could make Flash and Flex as accessible as a typical web page, or at least as easy to make accessible as a web page, it would remove the one last stick with which it gets beaten. In fact and to bring this full circle, the same mechanism by which search indexing now works may also prove the key to unlocking accessibility, so maybe that’s already possible?

*None of these arguments apply to Microsoft, especially the Ferrari analogy. Silverlight is neither better or faster.

Steven Carpenter : 01 Jul 2008 21:02 |  Tags: Adobe Flash Flex Rich Media |  Comments (6) |  Close comments |  Report a problem

Flash Player 10 ('Astro') pre–release on Adobe Labs

Writing about web page http://labs.adobe.com/technologies/flashplayer10/

A pre-release of Flash Player 10 is now out on Adobe Labs. Astro has a number of new features; P2P support, Speex voice codec (no more having to use ASAO!), dynamic streaming support and RTMFP, 3D, improved hardware acceleration and more sophisticated text control being the ones I’m most looking forward to.

The full feature list can be found here

Steven Carpenter : 15 May 2008 08:55 |  Tags: Adobe Flash Rich Media |  Comments (13) |  Close comments |  Report a problem

AIR/Flex: Memory optimisation

Moving to doing some optimisation within my AIR application now, using the Flex 3 Profiler. I was noticing some interesting results, primarily that removing redundant event listeners and display children doesn’t always result in memory being freed up back to the system. Not as bad as a memory leak, but not quite what I wanted. As a result I’ve just been reading up a bit on optimising memory and garbage collection in Flex/AIR. From what I can see, although garbage collection in AS3 is actually quite good, there are a few tips, tricks and caveats…

Weak-referencing
It’s possible to help garbage collection along a little by using weak references on events listeners:

myObject.addEventListener("eventName", handlerFunction, false, 0, true);

The last parameter being the weak reference flag. This saves having to manually remove the listener and means objects will be automatically removed by the garbage collector, but it can make debugging problems difficult because the collector won’t necessarily remove the object on its next pass. A solution to this is to force the collector to sweep and remove de-referenced objects.

Manual garbage collection
Sean Christmann (eBay Desktop) demonstrates a method whereby it’s possible to manually force the garbage collector to sweep and remove memory objects using

flash.system.System.gc();
flash.system.System.gc();

(yes you need to call it twice, once to flag objects, once to remove them). As Sean describes though, using weakly-referenced objects can make it harder to track problems:

Trust me when I say that its a lot easier to debug an application with memory leaks due to strong listeners, then it is to debug an app in which users report random failures because underneath the hood weakly referenced objects are getting accidentally destroyed when the GC kicks in.

Flash Player
Flash Player’s garbage collector may sometimes ‘swap out’ dereferenced-but-not-yet-destroyed objects for new ones under its normal garbage collection process, that is it will maintain a certain memory ceiling and not go above it, but some object types are harder to destroy than others because they get referenced into the player – these are generally the types of object that work asynchronously, Loaders being one example; see Flash’s Dirty Secret, and Timers are another. Memory paging can also get quite fragmented because Flash was never optimised for the kinds of application where it might be running for hours, days or even weeks as an AIR application in the System Tray.

AIR Windowing
I’d not really considered this before moving to AIR, but the windowing capabilities mean that managing objects and garbage collection across multiple windows should be handled with care, because it’s possible to lose the ability to reference objects when application windows can be closed, or the application is running in the Tray and therefore has no focus. Sean describes another caveat where any EnterFrame handlers (which you might be using to control the collector) must be re-referenced across multiple windows.

The Elastic Racetrack
Finally, although this isn’t a memory thing, a word about execution time in Flex/AIR; each ‘frame’ of execution in your application is tied to the elastic racetrack concept. Flex has to balance the load between AS code execution, rendering and event broadcast/handling around a single continuous loop of execution, with allocation within each cycle dependent on the load for each. The depth of the display tree, or the execution time of a method will affect what gets done when during a particular frame or ‘lap’.

Steven Carpenter : 29 Apr 2008 16:56 |  Tags: Adobe Development Flex |  Comments (4) |  Close comments |  Report a problem

Cairngen

Writing about web page http://code.google.com/p/cairngen/

I wish I’d come across Cairngen a bit sooner, having recently just set up two Cairngorm-based AIR projects via cutting and pasting a skeleton Cairngorm project structure from Rob’s earlier examples.

Cairngen will set up a Cairngorm project structure for you (using Ant), and much more besides. For example it’s capable of auto-generating what are termed ‘sequences’, which are sets of event-command-delegate templates (plus other alternative combinations) that create the FrontController, ModelLocator and VOs required, plus all the relevant mappings and basic classes. The core templates can also be modified so that classes contain whatever boilerplate text you need. A little downtime now learning how to use Cairngen should save me work in future, and if I set up a basic project script anyone else using Flex/AIR here can should be able to get projects up and running more quickly.

Steven Carpenter : 15 Apr 2008 23:24 |  Tags: Adobe Air Development Flex Ria Rich Media |  Comments (2) |  Close comments |  Report a problem