Mailing-List: contact users-help@flex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@flex.apache.org
Subject: Re: reduce creation time of view in mobile app
To: users@flex.apache.org
References: <1480298499765-14230.post@n4.nabble.com>
 <D4610150.7B580%aharui@adobe.com> <1480313766036-14234.post@n4.nabble.com>
 <D4610FDF.7B590%aharui@adobe.com> <1480315507119-14236.post@n4.nabble.com>
 <e06b61b6-06fa-1ab5-b588-6a50f5dee003@dahmenia.de>
 <CACK5iZdObeGUUzkiGL7Fw7w+T3M1UOKNKukds=78SHqAQYQHhw@mail.gmail.com>
 <1496e94d-07bf-56a5-bced-1005016e9c6f@dahmenia.de>
 <76d038f5-2e5c-43b6-0982-2878f6e9923a@after24.net>
 <d77dde41-8c45-e5f5-c0c5-478990f2ceed@dahmenia.de>
 <ce14cc93-b0c9-c8f1-61b8-2301f0521de4@after24.net>
 <5d774acc-ff1d-a25c-52f3-1886d4caf34b@dahmenia.de>
 <207f2f05-675c-70a5-56a6-7f4d21616546@after24.net>
 <3f0ebe76-37f8-f287-62e4-649946555fb8@dahmenia.de>
 <D4619A64.7B61B%aharui@adobe.com>
 <74185906-8beb-9e33-302f-a7cfa30094d7@dahmenia.de>
 <D461EA16.7B78D%aharui@adobe.com>
From: Frank Dahmen <frank@dahmenia.de>
Message-ID: <372ec607-b1aa-b799-3548-5ac30d2ba495@dahmenia.de>
Date: Tue, 29 Nov 2016 08:33:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <D461EA16.7B78D%aharui@adobe.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Tue, 29 Nov 2016 07:33:53 -0000

thanks Alex

I will try to figure out if and how I could apply it to this view


Am 28.11.2016 um 23:26 schrieb Alex Harui:
>
> On 11/28/16, 12:49 PM, "Frank Dahmen" <frank@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
>