navigator.onLine

[Bryan Higgins <bh...@rim.com>]

On BlackBerry 10, there is a native implementation of navigator.onLine. This is a more reliable test than checking connection.type. For example, the device could be connected to BlueTooth, but WebKit has no network connectivity.

Is there a reason we override this for other platforms? I understand the need to polyfill for platforms on which this isn't available.

Thanks,
Bryan
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: navigator.onLine

[Andrew Grieve <ag...@chromium.org>]

Most mobile browsers now do support online/offline events +
navigator.onLine out-of-the box. The thing Cordova adds ontop of this is
the navigator.connection.type API. We override onLine by default to ensure
that it stays in sync with what connection.type reports.

It's up to each platform to decide which properties for Cordova to handle,
and which ones should use the platform's implementation. It sounds like
maybe BB10 should just use the built-in one, or the networking API should
be updated to include 'bluetooth' as a type?

I'd file a JIRA issue :)



On Mon, Jan 21, 2013 at 12:46 PM, Filip Maj <fi...@adobe.com> wrote:

> Sorry for the late reply.
>
> On some platforms navigator.onLine doesn't update. I believe older
> Androids had this issue.
>
> Our API is event-based which is a bit more elegant than polling a dangling
> property off navigator. Not sure what the latest redux for the appropriate
> W3C spec is.
>
> On 1/18/13 12:39 PM, "Bryan Higgins" <bh...@rim.com> wrote:
>
> >On BlackBerry 10, there is a native implementation of navigator.onLine.
> >This is a more reliable test than checking connection.type. For example,
> >the device could be connected to BlueTooth, but WebKit has no network
> >connectivity.
> >
> >Is there a reason we override this for other platforms? I understand the
> >need to polyfill for platforms on which this isn't available.
> >
> >Thanks,
> >Bryan
> >---------------------------------------------------------------------
> >This transmission (including any attachments) may contain confidential
> >information, privileged material (including material protected by the
> >solicitor-client or other applicable privileges), or constitute
> >non-public information. Any use of this information by anyone other than
> >the intended recipient is prohibited. If you have received this
> >transmission in error, please immediately reply to the sender and delete
> >this information from your system. Use, dissemination, distribution, or
> >reproduction of this transmission by unintended recipients is not
> >authorized and may be unlawful.
>
>

Re: navigator.onLine

[Filip Maj <fi...@adobe.com>]

Sorry for the late reply.

On some platforms navigator.onLine doesn't update. I believe older
Androids had this issue.

Our API is event-based which is a bit more elegant than polling a dangling
property off navigator. Not sure what the latest redux for the appropriate
W3C spec is.

On 1/18/13 12:39 PM, "Bryan Higgins" <bh...@rim.com> wrote:

>On BlackBerry 10, there is a native implementation of navigator.onLine.
>This is a more reliable test than checking connection.type. For example,
>the device could be connected to BlueTooth, but WebKit has no network
>connectivity.
>
>Is there a reason we override this for other platforms? I understand the
>need to polyfill for platforms on which this isn't available.
>
>Thanks,
>Bryan
>---------------------------------------------------------------------
>This transmission (including any attachments) may contain confidential
>information, privileged material (including material protected by the
>solicitor-client or other applicable privileges), or constitute
>non-public information. Any use of this information by anyone other than
>the intended recipient is prohibited. If you have received this
>transmission in error, please immediately reply to the sender and delete
>this information from your system. Use, dissemination, distribution, or
>reproduction of this transmission by unintended recipients is not
>authorized and may be unlawful.