All 51 entries tagged Flex
August 28, 2008
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!
August 19, 2008
July 01, 2008
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.)
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.
May 29, 2008
I’ve just spent a few days trying to implement a specific feature in my current AIR project. Having tried several approaches and workarounds with varying degrees of nearly-but-not-quite-ness, I’ve had to admit defeat for now and have moved to a different implementation that I’m less happy with, but still allows basic functionality. At the same time Kieran has recently started work on his first Flex project and it’s been interesting to see how an experienced developer, when faced with a feature or issue he can’t easily implement or find a solution for, has quickly fallen back to a ‘next best’ solution, and moved onto getting the application functional and usable.
Time pressures obviously play a part here – the amount of time you have available before the project has to go out the door is going to impact on how much you are able to include desirable features over essential ones, but I think what I’ve picked up from this is that as soon as you encounter an issue, if you can’t predict reasonably accurately how long it’s going to take you to solve it, you need to set limits on how long you spend trying to make it work and at same time identify what is achievable if you fail to get it done within that limit.
If all this sounds like common sense, it is of course – but I found that in this instance I got too focused on a specific feature, rather than on getting the application functional enough that users can start using it sooner rather than later.
May 09, 2008
Chris was talking today about intra-team/department skills sharing, which I think is a great idea. With regard to Flash and Flex development at Warwick we’ve recently embarked on something along these lines, with the formation of a University Flash and Flex developers group consisting of people actively using (or just interested in) Actionscript development. It started with a forum that was initially populated with ITS people (plus one or two others), but since starting to deliver some Flash courses for ITS Training I wanted to maintain contact with what attendees did with the skills they’d acquired after the course, and the forum was opened up to allow more people to contribute. We held the first ‘skills session’ a couple of weeks ago, in the Teaching Grid. It was purposely an informal gathering, consisting of developers from ITS and departments, plus lots of coffee and biscuits. The session was an opportunity for everyone to show what they’d been working on and share expertise and a mix of ongoing Flash, Flex and AIR projects were demonstrated, plus discussion on development approaches and potential applications in the future.
Overall I thought it went well (we ran out of time in the end) and although next time some structure to the session might help us cover ground more efficiently, the informality and range of projects kept it interesting, and it was especially good to share ideas with others while receiving questions and feedback. As a result of the session, I’ve been asked to present a more formal hour-long session on AIR to the CIS Team next week, which I think I’ll prepare some slides for.
Anyway, my point is that personally I found it quite fun/rewarding to find out what other people were doing or planning to do with the technology, and to see and discuss approaches/methodologies and alternatives; we should definitely do more of this kind of thing in future. Time will tell whether we maintain the Flash/Flex/AIR group sessions but I hope we can.