11 Replies Latest reply on Aug 13, 2011 12:52 PM by drkstr_1

    Flex Mobile 4.5.1

    Francisc Level 3



      Why is Flex a bit slow when changing views.

      Basically, there's a list that when selected passes the list.selectedItem as data to the next.

      When I select an element of the list, there's a delay of 0.5 - 1 seconds before the transition happens.

      Is there anything I can do to make it faster?


      It happens even when the next view needs only the data passed from the previous view, no internet calls or database queries.

      And I can't say I notice a difference between when I request data from a local SQLite database in the next view and when I do not.


      Thank you.

        • 1. Re: Flex Mobile 4.5.1
          drkstr_1 Level 4

          I bet the delay is from the creation process. Creating and laying out elements is a heavy process. To conserve memroy, the view stacking architecture will delay creation until it's needed, and destroy the view when it's not (unless told otherwise). This means it will undergo that process whenever you change views (unless it's cached in memory).


          You say you are changing views every time you select an item in a list? Is that really necesary (as in, does each item in your list actually have a unique view attributed to it)?


          Perhaps what you need to do instead is use one view and bind it to the data that's selected, instead of creating and destroying the view every time a change is made. Onother option would be to only create part of the view, let it transition in, then create all of the children once it's in place. The exact stratety to take depends on your app.

          • 2. Re: Flex Mobile 4.5.1
            Log Home

            What are you testing on?

            - simulator / desktop

            - ios / droid?


            I find that the file size for the iOS is large for a seemingly small app (just returning XML), and yes switching between views is also quite slow.


            Loading 340 text strings from xml takes atleast 3 - 5 seconds, loading an image from XML takes more than 5 seconds.


            I have found that google maps is difficult to make work on iOS and there is little documentation for google maps on flex 4.5.1 on iOS, but mapQuest API for Flash is killer!



            • 3. Re: Flex Mobile 4.5.1
              Francisc Level 3


              I have several views, but a particular list will always open the same view but with different data. I interpret data and add children (etc etc) on the creationComplete handler for the view.

              If I were to slide in the fiew and then process data, I would probably still have the delay but in a different form, view slides in faster, but is empty, then content pops up a second or less later.

              How would I go about caching a view and if so, what event is fired when the view is called - before the transition preferably. cachePolicy?


              420 Colorado (TuTone):

              On the simulator it works very fast - as fast as I would want it to go on the device.

              I am currently only testing on Android and generally high end ones. Samsung Galaxy S with 2.3.3 is normally very fast, but in the case of Flex apps, it has a delay of response.


              I suspect it is a Flex Framework issue that will get solved in time or when devices get faster so I looked at Tour de Flex Mobile and it seems to have the same delay problem. It could be that there si nothing to do about it?

              • 4. Re: Flex Mobile 4.5.1
                drkstr_1 Level 4

                ...but a particular list will always open the same view but with different data...

                I don't believe  this is the best way to go about it. What problem are you trying to solve by doing it this way?


                The view creation process is a heavy operation, and it seems like a waste to undergo this process simply to change the data item. I think something like a DataGroup  that utilizes virtualization would be much more efficient.

                • 5. Re: Flex Mobile 4.5.1
                  drkstr_1 Level 4

                  I find that the file size for the iOS is large for a seemingly small app (just returning XML), and yes switching between views is also quite slow.


                  Loading 340 text strings from xml takes atleast 3 - 5 seconds, loading an image from XML takes more than 5 seconds.


                  You may want to consider compiling your XML into a binary object server-side, then sending it across the wire using an AMF implementation. If this is local XML, let the compiler do the work for you, not the client-side processor. XML is bulky and slow to parse, so best if you can push that work off onto another machine if at all possible.


                  I can assure you it's quite possible to have a responsive user experience in iOS using Flex. Our prototype app is running beautifully on a first generation iPad. This includes streaming video, dynamic generation of interactive content based on server-side data, and even a striped down version of TLF for dynamic text content.


                  Developing for mobile is not like developing for web or desktop. Resources are limited, and sometimes you have to go about a problem a bit differently than you would in a standard app, even if it seems less than ideal.


                  The key is to find the major bottlenecks and start getting creative on ways to circumvent them. The profiler helps a lot with this.

                  1 person found this helpful
                  • 6. Re: Flex Mobile 4.5.1
                    Francisc Level 3

                    I'm not sure what you mean.


                    By this: "but a particular list will always open the same view but with different data" I meant that listA will always open ViewA and listB, ViewB and so on.

                    You were saying that if a list always opens a view... etc. So yeah, a particular list will open the same view with different data.


                    It does seem like a waste of memory to keep destroying and recreating the views, both the one with the list and the one with detailed data of the element selected in the list, but how do you propose this should be done?



                    • 7. Re: Flex Mobile 4.5.1
                      drkstr_1 Level 4

                      It really just depends on your application and design goals.


                      It's actually not memory that's the problem, but processor speed. The view stacking mechanism was designed to conserve memory by providing a system for creating and destroying views as they are needed. The downside to this is that it must undergo a heavy process for creating and laying out all of the view elements every time you want to change views. This is not much of an issue when changing out unique views because it would have to undergo this process regardless. However, it may not be prudent to undergo the creation process every time you change the list selection.


                      A couple options that come to mind...


                      1. Optimize your view so it doesn't take as long to create.


                      2. Use a DataGroup with a virtual layout instead of a ViewNavigator, and add in some code for the transitioning based on the selected item. This may or may not be more efficient depending on your app. Most likely this would be more efficient.


                      3. Create a Group that holds all of the view's children and store two different instances of that group, one for the active view and one sitting in "standby". When transitioning to a new view update the data on the standby group then add it as an element to the view being transitioned in. The group that was on the active view will then go into standby for the next transition. This may take a bit of effort to get it to work right, but it may speed up the view creation process a bit by "caching" the heaviest part of this process. This type of system would probably work better in your own "view changer" component rather then using the ViewNavigator.


                      4. Only create a portion of the view when transitioning in and display some kind of "loading" indicator. When the view is activated, create the rest of the elements and add it to the view.

                      1 person found this helpful
                      • 8. Re: Flex Mobile 4.5.1
                        Francisc Level 3

                        Thank you for the tips, I appreciate it.


                        Still, I have a feeling that it is the Flex Framework that still needs a bit more time to grow - not long though.

                        I'm saying this based on Adobe apps that also have the delay problem as well as some of my own tests with views that are very very simple, like just a single StylableTextField and so on.

                        • 9. Re: Flex Mobile 4.5.1
                          drkstr_1 Level 4

                          Flex is obviously not as efficient as developing natively. Perhaps we have different expectations of good preformance. Our app preforms better than I was expecting (considering the complexity of it), and all the major stake holders in the project feel the same way. That is good enough for me.

                          • 10. Re: Flex Mobile 4.5.1
                            Francisc Level 3

                            I'm trying to look at it from a user perspective. Who won't care if it's native or not.

                            Maybe it's me that is doing something wrong, I'll keep digging.

                            • 11. Re: Flex Mobile 4.5.1
                              drkstr_1 Level 4

                              That's probably the difference in expectation than. I am looking at it more from a business perspective. For us, time to market is extremely important, and that is where we get value out of Flex. My expectation is for the app to perform well enough to get us first to market. As of now, it would appear Flex is fulfilling this expectation quite nicely. If you will need to compete on performance, than perhaps Flex is not the best way to go for you.