Why does the Dialogs plugin in inject itself into navigator and has no browser support?

[Philipp Kursawe <ph...@gmail.com>]

Hello,

sometimes I wonder the historical reasons why certain cordova plugins
choose to inject themself into "navigator" instead of their own namespace
or remain at cordova.plugins.<pluginname>.
For things where a native browser spec exists or is proposed like
"geolocation" it makes sense. Then you can just code against the native
browser API and when running on a device, that does not have this native
support the Cordova geolocation plugin poly-fills that behaviour.

I recently came across the "Dialogs" plugin which uses
"navigator.notifications" and I wonder why?
Why not "navigator.dialogs"? So I checked, maybe there is a W3C spec for
browser notifications. There isn't.

What is also interesting, that while browser have native support for alert
and prompt at the window level, the plugin neither polyfills them nor
provides any browser support at all.

One could just write the application with "window.alert()" and on mobile
devices the plugin would polyfill this behaviour.

Any insides in the though process of those decisions?

Thanks a lot!

Phil

Re: Why does the Dialogs plugin in inject itself into navigator and has no browser support?

[Raymond Camden <ra...@gmail.com>]

So on plugins.cordova.io, if you filter by Browser, Dialogs *does*
show up. But when you go to the docs, it isn't shown as supported - so
that could be a minor doc bug. I'll do a PR.

On Tue, Apr 19, 2016 at 10:22 AM, Raymond Camden
<ra...@gmail.com> wrote:
> I'm looking at the dialog plugin, and I swear I see code for browser
> support already in there. Going to test a bit.
>
> On Thu, Apr 14, 2016 at 3:59 PM, Jesse <pu...@gmail.com> wrote:
>> Notification pre-dates the use of plugin namespaces, most plugins
>> originally were hung off of navigator when a standard did not exist.
>> The notification plugin used to include things like displaying a loading
>> spinner, or vibrating the device, so it was much more about 'notifying'
>> than strictly dialogs.
>>
>> The problem with alert on various platforms is it is not consistent. It
>> does not even exist on windows, it displays a title of 'index.html' on iOS,
>> ...
>>
>> The additions for browser are coming, or you could do it and send a pr ;)
>>
>> Cheers,
>>   Jesse
>>
>>
>>
>> @purplecabbage
>> risingj.com
>>
>> On Thu, Apr 14, 2016 at 12:25 AM, Philipp Kursawe <ph...@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> sometimes I wonder the historical reasons why certain cordova plugins
>>> choose to inject themself into "navigator" instead of their own namespace
>>> or remain at cordova.plugins.<pluginname>.
>>> For things where a native browser spec exists or is proposed like
>>> "geolocation" it makes sense. Then you can just code against the native
>>> browser API and when running on a device, that does not have this native
>>> support the Cordova geolocation plugin poly-fills that behaviour.
>>>
>>> I recently came across the "Dialogs" plugin which uses
>>> "navigator.notifications" and I wonder why?
>>> Why not "navigator.dialogs"? So I checked, maybe there is a W3C spec for
>>> browser notifications. There isn't.
>>>
>>> What is also interesting, that while browser have native support for alert
>>> and prompt at the window level, the plugin neither polyfills them nor
>>> provides any browser support at all.
>>>
>>> One could just write the application with "window.alert()" and on mobile
>>> devices the plugin would polyfill this behaviour.
>>>
>>> Any insides in the though process of those decisions?
>>>
>>> Thanks a lot!
>>>
>>> Phil
>>>
>
>
>
> --
> ===========================================================================
> Raymond Camden, Developer Advocate for StrongLoop at IBM
>
> Email : raymondcamden@gmail.com
> Blog : www.raymondcamden.com
> Twitter: raymondcamden



-- 
===========================================================================
Raymond Camden, Developer Advocate for StrongLoop at IBM

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: Why does the Dialogs plugin in inject itself into navigator and has no browser support?

[Raymond Camden <ra...@gmail.com>]

I'm looking at the dialog plugin, and I swear I see code for browser
support already in there. Going to test a bit.

On Thu, Apr 14, 2016 at 3:59 PM, Jesse <pu...@gmail.com> wrote:
> Notification pre-dates the use of plugin namespaces, most plugins
> originally were hung off of navigator when a standard did not exist.
> The notification plugin used to include things like displaying a loading
> spinner, or vibrating the device, so it was much more about 'notifying'
> than strictly dialogs.
>
> The problem with alert on various platforms is it is not consistent. It
> does not even exist on windows, it displays a title of 'index.html' on iOS,
> ...
>
> The additions for browser are coming, or you could do it and send a pr ;)
>
> Cheers,
>   Jesse
>
>
>
> @purplecabbage
> risingj.com
>
> On Thu, Apr 14, 2016 at 12:25 AM, Philipp Kursawe <ph...@gmail.com>
> wrote:
>
>> Hello,
>>
>> sometimes I wonder the historical reasons why certain cordova plugins
>> choose to inject themself into "navigator" instead of their own namespace
>> or remain at cordova.plugins.<pluginname>.
>> For things where a native browser spec exists or is proposed like
>> "geolocation" it makes sense. Then you can just code against the native
>> browser API and when running on a device, that does not have this native
>> support the Cordova geolocation plugin poly-fills that behaviour.
>>
>> I recently came across the "Dialogs" plugin which uses
>> "navigator.notifications" and I wonder why?
>> Why not "navigator.dialogs"? So I checked, maybe there is a W3C spec for
>> browser notifications. There isn't.
>>
>> What is also interesting, that while browser have native support for alert
>> and prompt at the window level, the plugin neither polyfills them nor
>> provides any browser support at all.
>>
>> One could just write the application with "window.alert()" and on mobile
>> devices the plugin would polyfill this behaviour.
>>
>> Any insides in the though process of those decisions?
>>
>> Thanks a lot!
>>
>> Phil
>>



-- 
===========================================================================
Raymond Camden, Developer Advocate for StrongLoop at IBM

Email : raymondcamden@gmail.com
Blog : www.raymondcamden.com
Twitter: raymondcamden

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: Why does the Dialogs plugin in inject itself into navigator and has no browser support?

[Jesse <pu...@gmail.com>]

Notification pre-dates the use of plugin namespaces, most plugins
originally were hung off of navigator when a standard did not exist.
The notification plugin used to include things like displaying a loading
spinner, or vibrating the device, so it was much more about 'notifying'
than strictly dialogs.

The problem with alert on various platforms is it is not consistent. It
does not even exist on windows, it displays a title of 'index.html' on iOS,
...

The additions for browser are coming, or you could do it and send a pr ;)

Cheers,
  Jesse



@purplecabbage
risingj.com

On Thu, Apr 14, 2016 at 12:25 AM, Philipp Kursawe <ph...@gmail.com>
wrote:

> Hello,
>
> sometimes I wonder the historical reasons why certain cordova plugins
> choose to inject themself into "navigator" instead of their own namespace
> or remain at cordova.plugins.<pluginname>.
> For things where a native browser spec exists or is proposed like
> "geolocation" it makes sense. Then you can just code against the native
> browser API and when running on a device, that does not have this native
> support the Cordova geolocation plugin poly-fills that behaviour.
>
> I recently came across the "Dialogs" plugin which uses
> "navigator.notifications" and I wonder why?
> Why not "navigator.dialogs"? So I checked, maybe there is a W3C spec for
> browser notifications. There isn't.
>
> What is also interesting, that while browser have native support for alert
> and prompt at the window level, the plugin neither polyfills them nor
> provides any browser support at all.
>
> One could just write the application with "window.alert()" and on mobile
> devices the plugin would polyfill this behaviour.
>
> Any insides in the though process of those decisions?
>
> Thanks a lot!
>
> Phil
>