1 2 Previous Next 20 Replies Latest reply: Jul 5, 2013 9:51 AM by MobileADFDev RSS

    ADF Mobile : task-flow navigation takes at least 500 milliseconds

    Jan Vervecken
      hi

      While navigating the CompGallery sample application [1] I noticed that navigation between (what looks like) simple pages/views was rather slow.
      Surely, this can be caused by different things (possibly the device, the app implementation, the framework, ...).

      To review this, I tried to build a simple example application using JDeveloper 11.1.2.3.0
      at http://www.consideringred.com/files/oracle/2012/NavigationTimeMApp-v0.01.zip
      and as APK at http://www.consideringred.com/files/oracle/2012/navigationtimemapp-v0.01.apk

      It has a bounded task-flow with two views that allow to navigate to each other.
      see the screenshot at http://www.consideringred.com/files/oracle/img/2012/navigationtimemapp-20121025.png

      It has a simple TimerBean that allows to get an idea about how much time navigation requires:
      public class TimerBean
      {
           protected long fStartTimerMillis = 0;
      
           public void startTimer(ActionEvent pActionEvent)
           {
                fStartTimerMillis = System.currentTimeMillis();
           }
      
           public String getTimerInfo()
           {
                if (fStartTimerMillis == 0)
                {
                     return "no timer info yet";
                }
                long vMillisAgo = System.currentTimeMillis() - fStartTimerMillis;
                return "timer started " + vMillisAgo + " milliseconds ago";
           }
      }
      It allows for the following scenario (sc1):
      - (sc1-a) start the app
      - (sc1-b) click the "do goSecondView using a_TimerBean" button, which will navigate to "secondView" showing something like "timer started 621 milliseconds ago"
      - (sc1-c) click the "do goFirstView using a_TimerBean" button, which will navigate to "firstView" showing something like "timer started 537 milliseconds ago"
      - (sc1-d) if you care to stop the app, try a "Force stop" on the "App info" via "Apps" in the Android settings

      On my HTC Sensation Z710e I always get at least 500 milliseconds for each navigation.

      questions:
      - (q1) Anyone who wants to try scenario (sc1) and share his observed navigation times?
      - (q2) Which navigation times can be expected for simple navigation in ADF Mobile apps (like in scenario (sc1))?

      - [1] http://docs.oracle.com/cd/E35521_01/doc.111230/e24475/demoapps.htm#BACGDHDJ

      many thanks
      Jan Vervecken
        • 1. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
          Jan Vervecken
          fyi

          As clarification, the page firstView.amx contains these components:
              <amx:outputText value="a_TimerBean : #{a_TimerBean.timerInfo}" id="ot3"/>
              <amx:commandButton text="do goSecondView using a_TimerBean" id="cb2" action="goSecondView"
                                 actionListener="#{a_TimerBean.startTimer}"/>
          Currently (q1) and (q2) remain.

          regards
          Jan Vervecken
          • 2. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
            Frank Nimphius-Oracle
            ... forwarding internally. Jan, your testing, was it on Apple and iOS or Windows and Android?

            Frank

            Edited by: Frank Nimphius on Oct 26, 2012 8:01 AM
            • 3. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
              John Stegeman
              I have installed your APK on my SGS3, and I can report the following:

              a). Wow, 20MB for a simple APK ;)
              b). Takes quite a long time to start the app the first time around
              c). How do I quit the app? :)
              d). pf_TimerBean doesn't seem to work for me
              e). a_TimerBean gives me around 350ms +/- 30ms most of the time to do the navigation

              device.model = GT-I9300
              • 4. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                Jan Vervecken
                Thanks for your reply Frank, and for forwarding internally.
                Frank Nimphius wrote:
                ... forwarding internally. Jan, your testing, was it on Apple and iOS or Windows and Android?
                I tried only using Windows and Android. (But, ADF Mobile also seems to be aiming to abstract platforms.)

                regards
                Jan
                • 5. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                  Jan Vervecken
                  Thanks for your reply John.
                  John Stegeman wrote:
                  ... b). Takes quite a long time to start the app the first time around
                  Same for me. Suggestions to put a number (timing) on that are welcome.
                  c). How do I quit the app? :)
                  See step (sc1-d), suggestions for improvement are welcome.
                  d). pf_TimerBean doesn't seem to work for me
                  Same for me. To be reviewed.
                  e). a_TimerBean gives me around 350ms +/- 30ms most of the time to do the navigation

                  device.model = GT-I9300
                  So, that is already suggesting/confirming that the device plays a role.

                  regards
                  Jan
                  • 6. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                    Jan Vervecken
                    fyi
                    d). pf_TimerBean doesn't seem to work for me
                    Same for me. To be reviewed.
                    see "ADF Mobile : pageFlowScope managed-bean in bounded task-flow "
                    at http://java.net/jira/browse/ADFEMG-67

                    regards
                    Jan
                    • 7. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                      Joe Huang-Oracle
                      Hi, Jan, a couple of questions:

                      - Did you change CVM logging settings? When measuring performance, logging should be set to severe or logging will have a major performance impact.
                      - Did you deploy the application in release mode vs. debug mode in the deployment profile? You would want to deploy it in release mode.

                      Assuming both are set correctly, then what you observed is most likely accurate for the device you are using. To render the UI, basically the Device's JavaScript engine needs to render XML definition into HTML5, so page navigation performance (and overall UI performance) is primarily dictated by JS performance by the web engine on the device. Looks like the HTC device you are using is an 2.3 device. Android has made improvements in successive versions of the JS engine, but 2.x devices were problematic. Android JS performance should improve dramatically once the Chrome browser becomes the primary web engine in the Android devices.

                      To get a more realistic test case, I would actually look at an app like the HR demo app which gets data from the local DB, and see if it can meet your performance requirement. Component demo is a bit tricky because the performance can vary based on what component you are actually trying to invoke - I am not saying it would be faster or slower than HR demo, but just HR demo is more realistic.

                      At the end of the day, the actual performance of your application will be largely dictated by how you access data and the complexity of your screen. If you directly access server data sources via REST or Web Services, then your performance would subject to network traffic. If you cache the data to local DB, then you would have more consistent performance but it's more coding you have to deal with. The framework introduces some overhead, but in the overall timing, 500ms may or may not be significant compared with overall round trip time.

                      Thanks,

                      Joe Huang
                      • 8. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                        Jan Vervecken
                        Thanks for your reply Joe Huang.
                        Joe Huang wrote:
                        ... Did you change CVM logging settings? ...
                        I have not changed any defaults. If I unzip "navigationtimemapp-v0.01.apk", I find:
                        - assets\storage\jvm\lib\cvm.properties having things like "java.debug.enabled=false" and "javascript.debug.enabled=false"
                        - assets\storage\jvm\lib\logging.properties having only "level=SEVERE" configurations
                        If you refer to something else, please specify.
                        - Did you deploy the application in release mode vs. debug mode in the deployment profile? You would want to deploy it in release mode.
                        Looks like the default is debug, which I have used for "navigationtimemapp-v0.01.apk".
                        So, I configured on the Android Options the Build Mode as "Release" in the modified example application
                        at http://www.consideringred.com/files/oracle/2012/NavigationTimeMApp-v0.02.zip
                        and as APK at http://www.consideringred.com/files/oracle/2012/navigationtimemapp-v0.02.apk (now only 8 MB instead of 20 MB)

                        But, I don't see a big improvement, maybe about 50 milliseconds improvement per navigation (so, about 450 milliseconds instead of about 500 milliseconds).
                        ... so page navigation performance (and overall UI performance) is primarily dictated by JS performance by the web engine on the device. ...
                        How can I determine (in the app) which "JavaScript / web engine" a device uses?
                        At the end of the day, the actual performance of your application will be largely dictated by how you access data and the complexity of your screen. ...
                        Sure, but I explicitly avoided those aspects here to have some kind of "base line" behaviour before introducing other complexities (that can slow things down).

                        regards
                        Jan
                        • 9. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                          user404
                          I installed your apk on my Sony Experia Ion (model LT28h).

                          pf_TimerBean) Not working like said before
                          a_TimerBean) 472 ms
                          • 10. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                            Jan Vervecken
                            Thanks for your reply "962432".
                            962432 wrote:
                            I installed your apk on my Sony Experia Ion (model LT28h).

                            pf_TimerBean) Not working like said before
                            a_TimerBean) 472 ms
                            Thanks for trying. Was that using "navigationtimemapp-v0.01.apk" or "navigationtimemapp-v0.02.apk"?
                            Do you see any difference in navigation time between navigationtimemapp-v0.01.apk and navigationtimemapp-v0.02.apk?

                            (tip : You can use "Your Control Panel" to make your name visible in forum posts.)

                            regards
                            Jan
                            • 11. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                              Timo Hahn
                              Jan,
                              I spend some time testing your app (looking snooker :)) on different Android devices. Here are my findings:
                              Samsung galaxy s2 (GT-I9100):
                              V0.01: same times as John on his s3
                              V0.02: 310 ± 30
                              Lifetab (MD-LIFETAB-P9516)
                              V 0.01: 420 ± 40
                              V 0.02: 370 ± 40

                              V 0.02 loads visibly faster the first time on both devices. Fastest time I saw on the sg 2 was 213 ms, on the tablet 307 ms. I made three test once with allmy normal apps ruining and once with everything shut down (other then three needed apps. There was no difference in the timing I saw.
                              Pf_timerBean did not work in either version.

                              Timo
                              • 12. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                                Jan Vervecken
                                Thanks for your reply Timo.

                                So, your findings seem to confirm an about 50 milliseconds improvement per navigation with the Release Build Mode (in "navigationtimemapp-v0.02.apk") compared to the Debug Build Mode (in "navigationtimemapp-v0.01.apk").

                                regards
                                Jan
                                • 13. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                                  Joe Huang-Oracle
                                  Hi, everyone, thanks for trying this out on various Android devices. In our performance testing, when we just render a simple page with data locally generated in a local Java ban, great majority of the time is spent in the UI rendering, which is the time the JS engine in the webview takes to generate HTML 5 controls. This is one area that hybrid applications in general would be subjected to Android Webview support. As the platform gets better, performance will get better. Of course we are also looking for more ways to improve performance, as it is still our number one priority.

                                  That said, however, another major area of performance that's somewhat outside of our control is time needed to exchange data with server side services. If that is slow, screen rendering time would be trivial comparing to that. In a real life mobile app, you will need to think about when to and how much data to retrieve - for example take one shot upfront to retrieve data sufficient for the next few screens, and design the app to limit the data you want to retrieve. So it may take 3-4 seconds in going into first screen, but then less than 1 second for subsequent navigations. Based on our experiences with beta customers and Oracle internal teams, properly designing data retrieval ultimately has the greatest performance impact.

                                  And lastly, the ultimate judgement is comparing this with other Android apps that needs to get data across the wires.

                                  Thanks,

                                  Joe Huang
                                  • 14. Re: ADF Mobile : task-flow navigation takes at least 500 milliseconds
                                    Joe Huang-Oracle
                                    Hi, everyone:

                                    There is one more factor at play here, which may or may be counted into the time measurement here. The ADF Mobile UI framework itself has a built in ~500ms delay to allow page transition animation to occur. The screen typically slides during a page transition, and to allow animation to occur, there is a built in delay of 500ms to allow the transition animation itself to occur. This animation and data retrieval occurs concurrently, so even if you manage to get data back in <500ms, there is still a ~500ms delay.

                                    If we don't build in this delay, then page transition animation would look very abrupt. However, you can completely turn off page transition animation in the taskflow - it's controlled by the "transition" property of the control flow case. You can set it to none and this 500ms would go away. However, I am not sure if that would be optimal user experiences.

                                    Thanks,

                                    Joe Huang
                                    1 2 Previous Next