Rats, I've been singled out again. I was sort of hoping not to get too involved in this topic, but, since you asked...
First, a little about me: I'm an old DOS/Windows app developer turned AS developer. I wrote code that had to fit in 640K, and later in Windows 2 which were both single threaded environments. I've done some multi-threaded Windows 3 code in the past, but know almost nothing about servers, and you can print out all of the Java code I've written and still not cover your dining room table. My background probably makes me more willing to jump through hoops to make things work in the environment I've been given. I'm all about leveraging what's there and will sacrifice some maintainability in order to deliver a great user experience. I've written tons of assembly code, designed and implemented a custom overlay infrastructure to get MBs of code to run in 640K and lots of other 'crazy' things. To me, the Flash Player is a new paradigm/platform. I don't even consider it to be single-threaded, but rather, completely event-driven. We can wish it was Java, Windows XP, Linux, etc, but it isn't. It was designed to optimize animation in a browser plug-in environment, in the smallest possible download so as to encourage ubiquity. Plenty of studies show that proper use of animation in a presentation can significantly improve the chances your application will achieve its goals of learnabiity, reduced errors, task completion time, retention, etc. To me, that is the promise of ria. It is not an opportunity to offload servers. In fact, the whole principle of web-hosted apps is the notion of zero-install, i.e, not having to visit every desktop. The more work you push into your client, the greater the chances are that you'll have to visit them to upgrade their box. So, if I were in your shoes, I'd be trying to design apps that leverage these advantages, while working around the limitations via things like pseudo-threading, paging data, etc. However, I'm not in your shoes. I've never built and delivered a RIA. I'm stuck in a cubicle, improving the framework, but I never really have the time and opportunity to use it from your perspective; We rely on feedback from those of you who are in the trenches. I can only offer unproven ideas. Will there be threading in some future Flash Player? Probably. Do you need threading now? Probably. Can pseudo-threading solve it for now? Probably. Maybe I'll try to put together a general pseudo-threading engine. Keep in mind one thing about threading: While it will help you show progress or spin a busy cursor while cranking lots of data, if the user is waiting for its completion as part of the workflow, it will still seem painful to the user. It will always be better to try to design the app to avoid any serious cranking in the workflow. That's why paging of data is useful. If your DataGrid can only show 8 rows of data, go get 8 rows and get the rest later. Show a low-res thumbnail and get the high-res later. Use your imagination, learn how to think in this new platform, and design for the user, and forget for a moment that their computer is a fast as the server. After all, they may be running their virus scan at the same time as your app, or watching some video, so you cannot always factor that CPU into your load-balancing equation, and it in theory, it is the user's experience that matters most. Of course, I could be wrong... -Alex ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of danielggold Sent: Monday, November 12, 2007 9:11 AM To: [email protected] Subject: [flexcoders] Re: Where to do heavy lifting in a Flex app? (no threading?) Looks like quite a few people are tackling the same problems, or have at least had it in the back of their minds. I understand the history of the flash player, what kinds of applications it's been used for, and I also understand how large an undertaking it would be to make the current Flex components thread-safe, etc. The big problem I have, and I think others have already touched on it, Flex and AIR are being marketed as the evolution of RIAs, and I honestly believe they are. But there are some pretty big hurdles to overcome to make the user experience as rich as possible, the development as painless as possible, and the RIA as powerful as possible. In my case the server is doing a TON of the work, so "offload it to the server" is already pretty much the case. That being said you can't fine tune ALL your data for a particular view. The Flex UI I'm working on is just one of the consumers of the XML data available on the server. I get a large chunk of XML, I process it, and then I need to make intelligent decisions about updating various data models and the view reacts to those changes. The problem is when all of this happens serially in event listeners, the UI is blocked. I hear a lot of suggestions to split the work up and do it in the next frame. Most of my work prior to Flex has been Java and similar languages, so I'm still getting used to the idea of thinking in frames. Can someone give me a good example of how to split this work across frames? Most of the work is being done in the result of Cairngorm commands, which aren't DisplayObjects so callLater() isn't available. Do I need to have these commands somehow listen for a frame change on the application? That seems like a very un-clean way of handling this. I've been considering some of the suggestions of using a Timer. I may create a WorkQueue where I can pass function references and parameters. Start a timer and have the WorkQueue listen for the timerEvent and process the next action. I think it'd be great to hear from more Adobe employees such as Alex about how they are currently handling problems such as this, and any possible plans for the future of Flex and AIR to handle more client-side processing. Maybe a series of blog posts are in order. Thanks again for the great responses.
