Quick reminder that tomorrow Tuesday 16th June is FlashCamp Birmingham. If you’re interested in the Flash Platform in any way at all, try and grab one of the last few remaining places. The presentations and list of speakers is really great and should make it a fantastic day for beginners and experts alike. See you there!
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!
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):
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.
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
Copyright © 2010 YAY!MEDIA. All rights reserved.