07-21-2011 05:31 PM
When using HTML5's Offline Web Applications (with a manifest file) and launching a pre-cached application, if the browser is being launched with no reception (or with airplane mode enabled), it will have HTML5's navigator.onLine === true. The value is updated correctly once you go in and out of reception again (or simply by disabling and re-enabling airplane mode).
If there's reception when the browser is first launched, the flag is working as it should.
This is a major issue since it only allows Offline Web Applications to rely on network timeouts for decision making, which harm UX.
I am using BlackBerry Playbook 220.127.116.110.
07-22-2011 10:31 AM
Thanks for the bug, I don't even think this API is properly documented in the Webworks docs, so I posted this issue.
As a workaround you can simply use the webworks api System.hasDataCoverage
07-22-2011 10:43 AM
Saw this snippet already. Will give it a go Monday morning.
However, navigator.onLine is HTML5's standard way of implementing connectivity validation. And it works on the PlayBook, except in the provided scenario.
Our HTML5 app is expected to run within a regular browser. Is blackberry.system.hasDataCoverage automatically exposed in the browser, or is it only for bundled apps?
07-22-2011 10:55 AM
Sorry, the API is a WebWorks API, so you would need to make a bundled webWorks app to take advatage of the API.
07-22-2011 11:16 AM
No, this is the right forum I just didn't know you were running a mobile site.
07-22-2011 11:30 AM
Ok, so just to clarify:
We have an HTML5 web app that suppose to run when online or offline -- for that we use a manifest file. This works correctly.
On a different note, our app retreives data from our web services and videos from our video service, and caches it.
When the device is online, we decide, based on the data's age, whether we re-download it again or not.
When the device is offline (to supposedly be determine by navigator.onLine), we always recourse to cached data. If we instead try to initiate network retreival when offline, it tries and times out (after 20s).
From what I see, the PlayBook reports navigator.onLine correctly, except for when the browser launches without connectivity, and then until the connectivity status changes. However, this means that our (and others) webapps will assume network is connected at that time, and will try to contact servers.
07-22-2011 11:59 AM
I believe in this case you will recieve an appcache error event. As a workaround could you intercept the event and if so wait for the onLine to change before trusting the value?
07-22-2011 01:15 PM
Thinking it over, the solution is quite good, as it will give us another way to tell if the user is offline in the begginning, but it still has a problem.
Assuming we are considering the user to be offline if we get applicationCache error, even though navigator.onLine===true, when the app laucnhes. How would we know if and when the user reconnects? applicationCache error state is the last state applicationCache will ever be in, so we can't deduce from it. And navigator.onLine will remain true if the user actually connects. We would just couldn't tell that the user has re-connected.
07-22-2011 02:34 PM
I guess the only solution is a timer that does an XHR request until the request finally succeeds and then you can trust the property