Home Tutorials Forums Articles Blogs Movies Library Employment Press

Go Back   ActionScript.org Forums > Flex > Flex 2, 3 & 4

Reply
 
Thread Tools Rate Thread Display Modes
Old 07-18-2008, 03:18 PM   #1
kminev
Senior Member
 
Join Date: Jun 2008
Posts: 129
Default Assyncrhounous data loads on flex charts

Hi,

I have a flex chart which load very very large amount of data (50 000 - 200 000) records per load. Is there a way I can set my web service on the flex level to load data assoynchronously or can I do some kind of caching to make the users wait time either minimized or perhaps let the user see the data while loading some more data on the background.

Any tips will be appreciated.

Thank you.
kminev is offline   Reply With Quote
Old 07-18-2008, 07:08 PM   #2
fathwad
Registered User
 
Join Date: Jul 2008
Posts: 52
Default

Afaik, flash player is single-threaded with a few exceptions (I think uploading/downloading is one of those exceptions, if that helps...I'm not sure if this applies to loading from a remote call). What I have done before was ask for user interaction AFTER an upload has been initiated. It worked well since it made the upload time seem a lot shorter.

For your situation, you can try simply breaking up your calls. i.e., load 1000 at a time and do processing in between to show the user progress.
fathwad is offline   Reply With Quote
Old 07-18-2008, 10:08 PM   #3
kminev
Senior Member
 
Join Date: Jun 2008
Posts: 129
Default

Your idea about showing a progress bar on every 1000 records or so is a good idea, but it would be ultra cool if there is a way of caching data on the flex level. I know there is something built in to it, but not sure how to utilize it. thanks
kminev is offline   Reply With Quote
Old 07-19-2008, 12:35 AM   #4
Sleeve
Corrupted Whitespace
 
Join Date: May 2006
Location: Seattle, WA
Posts: 489
Default

kminev-

Look into the SharedObject for storing data locally on the users computer. I think you'll find that loading that many records from a remote call will lead to the app 'not responding' until the flash player parses all that data. Also, if the user is on a slow machine, the player may throw a timeout message and ask the user if they want to stop running the script which would be bad.
__________________
Some people smoke, some drink...I code Actionscript
Sleeve is offline   Reply With Quote
Old 07-19-2008, 02:32 AM   #5
fathwad
Registered User
 
Join Date: Jul 2008
Posts: 52
Default

I don't mean to undermine your advice Sleeve, but I don't think Shared Objects would work well in this context. SOs are roughly analogous to browser cookies so using that to "cache" would be a bad idea - just as saving the results of a remote call into a cookie would be. I believe the timeout is 15 seconds or so by default, but yes, there is a timeout. Using setTimeout as I mentioned won't cause a timeout on the client side since the process releases control in between each iteration.

e.g.

ActionScript Code:
load1000() {    //something    setTimeout(load1000,5); }

where 5 is some arbitrary time (that could be 0).

The timer is reset each time that function is called.


As for something built into the player, I can't say I know for certain. If you are just downloading something, you might find something in the Loader class. As I mentioned earlier, I believe this is a separate thread that won't timeout since it is not processing. This also lets you do other things (as expected from another thread).

From docs
ActionScript Code:
var ldr:Loader = new Loader(); var url:String = "http://www.unknown.example.com/content.swf"; var urlReq:URLRequest = new URLRequest(url); ldr.load(urlReq);

You should then look at the loader info (ldr.contentLoaderInfo) to generate your progress bar. Also, user interaction is possible I believe. To retrieve the data, listen to the complete event and access ldr.content.
fathwad is offline   Reply With Quote
Old 07-19-2008, 02:33 AM   #6
fathwad
Registered User
 
Join Date: Jul 2008
Posts: 52
Default

Forgot to mention, one disadvantage with using that Loader solution is that I don't think you can access the data while its loading.
fathwad is offline   Reply With Quote
Old 07-19-2008, 03:24 AM   #7
Sleeve
Corrupted Whitespace
 
Join Date: May 2006
Location: Seattle, WA
Posts: 489
Default

byte arrays, zlib compression and shared objects - you are all set up to 400k+ with compression.

..and shared objects are VERY different from cookies. Don't you read the documentation?
__________________
Some people smoke, some drink...I code Actionscript
Sleeve is offline   Reply With Quote
Old 07-19-2008, 05:47 AM   #8
drkstr
Flexpert
 
drkstr's Avatar
 
Join Date: Sep 2006
Location: Seattle, WA: USA
Posts: 1,587
Default

I'm with Sleeve on this one. Using a SharedObject with a custom loading framework is the best way to go. You can store quite a bit in a SharedObject. In my opinion, it would be an elegant solution to load and display the data in chunks. Load the first 1000 sets and hold it in memory and diaplay it to the user as soon as it's ready. Then behind the scenes, keep loading data in chunks of 1000 (or whatever you like) and store the chunks in a SharedObject. When a user changes the view, swap out the data held in memory with the data stored in SharedObject. If the data they want to view has not been loaded yet, they should be presented with a progress bar and that chunk should be queued to load next. As before, display the data when ready.

In my opinion, this would be an ideal application design. I'm sure you can get some help on this from many of the posters here if you need it.


Best Regards,
~Aaron
drkstr is offline   Reply With Quote
Old 07-19-2008, 09:44 AM   #9
creynders
flash veteran
 
creynders's Avatar
 
Join Date: May 2005
Location: Belgium
Posts: 914
Default

There really is no reason whatsoever to complicate things and start storing stuff in SO's. Just keep the data in memory. (And yes, do load them in chunks.)
Trust me, the swapfile communication runs a lot faster and smoother than SO-access.

And IMO SharedObjects are very much alike to cookies. It even says so in the documentation:
Quote:
Local shared objects are similar to browser cookies
granted remote sharedobjects are quite different, but that's not what we're talking about here.

Last edited by creynders; 07-19-2008 at 09:48 AM.
creynders is offline   Reply With Quote
Old 07-19-2008, 06:27 PM   #10
drkstr
Flexpert
 
drkstr's Avatar
 
Join Date: Sep 2006
Location: Seattle, WA: USA
Posts: 1,587
Default

Of course it would be easier to just keep all 500K+ records in memory, but that wasn't what he was asking. And yes, SharedObject is SIMILAR to cookies in that they both hold persistent data on the local machine, but the similarities end there. I don't remember off the top of my head the exact amount of storage, but it's in the hundreds of megabytes of binary data. That should be more then enough for a caching framework if this is the route you decide to go with. Otherwise, you can just let your app eat up all the available memory until it has to hit the swap file, as creynders suggests.

Best Regards,
~Aaron
drkstr is offline   Reply With Quote
Reply


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Adobe Flex 2.0 Chart with real time data tanusree Flex 2, 3 & 4 8 11-28-2008 09:06 AM
Granite vs. Flex Data Services? FlashBulb Flex 2, 3 & 4 2 04-24-2008 03:21 PM
Database simulated with arrays on a cd-rom lecasn5 Components 61 09-07-2004 11:40 AM
movie loads no data from PHP igorbt ActionScript 1.0 (and below) 2 02-25-2004 02:17 AM
best practice? loads of data -> javascript hangalot ActionScript 1.0 (and below) 0 05-22-2003 03:03 PM


All times are GMT. The time now is 09:55 AM.

///
Follow actionscriptorg on Twitter

 


Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Ad Management plugin by RedTyger
Copyright 2000-2013 ActionScript.org. All Rights Reserved.
Your use of this site is subject to our Privacy Policy and Terms of Use.