On 11/28/16, 12:49 PM, "Frank Dahmen" <fr...@dahmenia.de> wrote:
>this looks like magic :) > >I'll try to understand the concept In fact, it is based on the principles that most professional magicians use, such as illusion. There is probably no requirement in your app to create, say, 200 UI widgets at the same time, just to give the illusion that you did. So, once you understand the behavior of the end-user, you might be able to create an illusion of creating 200 UI widgets by creating the 50 or so that must be on-screen right away, then adding others "later". In some scenarios, if the user must read something before deciding whether to scroll to see the other widgets, you can use that "read" time to make the remaining widgets. In computer time, a human reading something usually takes quite a bit time. But there are other scenarios where the user is just as likely to flip to the bottom of the screen, and then you have to take that into account. Also, usually, user interaction takes very little of the frame time in Flash. But doing too much makes the UI poorly-responsive. So it is possible to do little bits of work when the user is interacting, but not so much that he/she notices. The implementation in this FlexStore example uses multiple view states. Think of any live theater you've watched where the sets are changing on one corner of the stage while the spotlight focuses your attention on two people talking in the opposite corner. The theater director has choreographed what backdrops get raised and lowered and when certain stagehands carry in some furniture and when the actors arrive at the edge of the stage. The FlexStore example just uses two states, but you could use many more if that is what you need to do in order to create all the widgets and not make the app unresponsive. FlexStore waits for a stylesheet to load, but you could wait for creationComplete or updateComplete of whatever needs to be on-screen right away, then use callLater to change to the next state, where more widgets are created, then on updateComplete of those, callLater could switch to yet another state. I use StateGroups so that widgets have an "includeIn" of all states after the one they are create in. FWIW, one of the cool things about FlexJS is that MXML is converted into data instead of code, so it would be possible to create a "smart" container that only instantiates as many components as it can within an interval, then creates more on subsequent intervals. The result would be sort of a "reveal effect" if the rate of creation falls behind the user's demands. HTH, -Alex
