iPad / Safari or Chrome recovery time / hang

[Brian Biales]

I am currently still using WebSync 3, and am wondering if upgrading
might help a particular situation. I have a page with “live” updates
using WebSync, keeping the data up to date, and users are on the iPad
(latest release). I noticed that when they are not using the device,
and it goes into its “sleep” mode for a while, when they push the
button to wake it up, the browser UI is completely frozen for up to a
minute. I believe this is while it tries to resume communication over
an HTTP session that the server dropped a long time earlier. So
eventually it discovers the connection is broken, reconnects,
resubscribes (all automatically) and all eventually returns to normal.
It seems to me that it is websync that is doing some sort of blocking
call that takes a long time, but I don’t have any proof. There isn’t
much else going on with the page, though... It is just waiting for
new information to display. This seems to occur in both Safari and
the Chrome browser on the iPad.

Please let me know what you think of this, any suggestions about how
to diagnose or even fix the total lockup of the browser UI for up to a
minute when waking up. This is not how I want this page to perform...

Thanks.

[Anton Venema]

Hey Brian,

Debugging mobile browsers can be tricky. WebSync itself doesn't have any blocking code unless you have explicitly set the 'synchronous' flag to true in any of your client-side method calls.

WebSync 4 did overhaul the connectivity management. Relevant piece for you is that invalid client IDs are discovered sooner after a failed connection. Without actually plugging it into your code, I'm not sure if that would resolve your issue, but it's definitely worth a try.

Also, you may want to try launching your website from a home-screen link instead of from within Safari/Chrome as a quick experiment. I've read that iOS doesn't terminate the JS processes for web-apps launched from the home screen even if the device goes into sleep mode. If you see the same issue, then the problem might not be JS-related.

If none of that helps, I would try throwing some log statements into the code, especially where the XMLHttpRequest instances are created, to see if you can get a bit more info about what JS is actually doing.

Anton Venema

Frozen Mountain Software
604-227-2458 (Canada)
919-300-5520 (United States)
888-379-6686 (Extension 102)
www.frozenmountain.com

--
You received this message because you are subscribed to the Google Groups "WebSync" group.
To unsubscribe from this group and stop receiving emails from it, send an email to websync+u...@googlegroups.com.
To post to this group, send email to web...@googlegroups.com.
Visit this group at http://groups.google.com/group/websync?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Brian Biales]

Thanks, Anton - I plan to go to Websync 4 but am working on client UI
issues first. Good to know that v4 will use HTML 5 sockets if
available. And that invalid ids are discovered quicker. And that
putting the app on the home screen may let it run in the background!
All good things to know.

The good news is that it was not the Websync re-connection that was
locking the UI. I discovered that the re-subscription processing on
my end was horrendously inefficient, and it was my code that was
taking so long! I fixed that and the reconnect / resync of the UI
occurs pretty quickly now.
Thanks again.