5 Replies Latest reply on Dec 3, 2012 6:46 AM by Michael Teti

    White Screen issue in RhoElements 1.0.3.11

    Michael Teti

      I am hoping someone can shed some light into the scenario I am experiencing:

       

      1. Wake up MC9190-G (Windows CE 6.0)
      2. Start RhoElements 1.0.3.11 and navigate to remote web page. Web page loads fine.
      3. After the screen is loaded, I turn off the handheld.
      4. Lets say after 5 minutes, I wake up the handled to resume activity.
      5. Once the page is responsive, I click a link on the web page to and rather than navigating to the destination web page, I received a "Blank White Screen".

       

      This scenario only occurs when the handheld is responsive yet the wireless has not reestablished a connection to the access point.  In this scenario, I would imagine that if the network is unavailable, that the request would timeout (currently set to 45 seconds in Config.xml) and navigate to the BadLinkURI.  However, in this scenario, it navigates to nowhere, which in it's kiosk mode, requires a device reboot to recover.

       

      Any help on this matter is greatly appreciated!

        • Re: White Screen issue in RhoElements 1.0.3.11
          Darryn Campbell

          Hi,

           

          It sounds like a bug, what you describe as the expected behaviour would also be what I expect.  It's not a bug I've seen before so I can't say if it would have been fixed in 2.1.  As a work around you could use the network API to detect when the network is re-established, preventing navigation until the network connection is re-established.  One way of preventing navigation would be to disable the screen (stylus API)

           

          Darryn.

            • Re: White Screen issue in RhoElements 1.0.3.11
              Michael Teti

              Thanks Darryn!

               

              I agree that this can be managed via the RhoElements API.  However, I have also experienced the white screen when RhoElements first initializes and attempts to navigate to the start screen URL. If RhoElements can't resolve the first screen (even with full network availabiltiy) and doesn't have any inherent retry logic built-in, then the ability to leverage the RhoElements API is not possible.

               

              Other thread suggested creating an internal landing pagem which will check network availabilty and redirect to the target remote page. Hosting content both remotely and locally seems counter-productive to the web application model.

                • Re: White Screen issue in RhoElements 1.0.3.11
                  Darryn Campbell

                  Hi,

                   

                  Yes, I believe there is a bug already in the system for the initial navigation to a remote start page, I'll chase it as it should get resolved.

                   

                  I stand by the suggestion of a local landing page (which can then connect to your web server back end), this is no different from having your bad link page locally on the device and will also improve the perceived start up performance for your users.  The initial page wouldn't need to have any UI.

                   

                  Thanks.

                   

                  Darryn.

                • Re: White Screen issue in RhoElements 1.0.3.11
                  Jason Beneteau

                  I am having a very similar problem with RhoElements 1.0.3.11. For testing, I set the wifi to CAM, always on, and am monitoring the network module and displaying the status on the page using the example showed on the network module docs page. It shows that I am connected and my ajax is working perfectly, but if I let RhoElements sit for a few minutes the ajax stops working and if I try and click a link to go to another page, I just get a white screen. On my web server I never see the request from RhoElements during this time.

                   

                  I downgraded to 1.0.2.3 and the problem went away. Is this fixed in 2.1?

                  Also, since I downgraded to 1.0.2.3 I noticed my ajax callbacks are processing much faster on the client side.