Earlier I had asked if anyone had any Flex questions I could ask Jeff Tapper when he came by to train the group, and a few people did. Unfortunately, the last day I had a major meeting maelstrom (try saying that three times fast) and so I didnt get to work on any of the cool stuff (but the rest of the team did and that was the point for the most part anyway). But I did ask a couple of questions that were posted. I do apologize for taking a week for putting these up but its been a crazy week.
Paul Rangel asked:
To sum it up.
Is there a way to load an XML config file while the Flex framework is loading and have that available in the app?
Save it in a shared object ( write it to the disk) and call it up once the app has creation completeded : ) . This solution is fine but I figure there has to be another way since we use this design pattern in 90% of our projects and I would like to make the most of the inital load since the user is waiting anyway.
So turns out the entire group has never written a custom preloader before (oh the shame!), but the idea of not being able to use the loaded data baffles the mind. Probable solution: Use a singleton class with no strings to the Flex framework to load the data and reference it in the application when the application is initialized. Go completely native and use the URLLoader and the URLRequest objects if you have to (I am not sure if HTTPService has any dependencies on the SystemManager being ready). And do let us know how that works out. If anyone else has seen the same issue or has a solution, please drop me/us a comment as well.
SmackDaddy asked :
So we wasnt sure about this. If the idea was to catch an error at ANY time, then wrapping your app in an uber-try/catch block was a possibility (ugh), although I dont think that would work for async httpService calls will it? However I dont think there is any official way to handle global exceptions.
Again, none of us have an answer to this since we hadnt ever done it. But I can imagine a solution where you load node data only when required and since the performance of such an app would suck, you could try an aggressive strategy where you load one subsequent node worth of data (other than the ones open) and when a user opens a node, you fetch another node down as well, the idea being you keep fetching data for nodes that the user may open next. The retrieved data can be then spliced into the dataProvider of the tree. I’ll try to dig up a link that also talked about data refresh without closing the whole tree (which seems to be Flex’s way of handling a change in the dataProvider)
I guess most of the answers here are “umm…., we could try …”. If any readers have the answers then please feel free to comment.
One thought on “The much awaited notes from Flex training day 3”