Prevent Android only plugin from being installed in ios platform

[Philipp Kursawe]

I wonder why there is no concept in plugins to specify in their metadata
(plugin.xml) for which platform they should be installed.

I tried to put the plugin directive in my config.xml under the  removed the iOS platform. Added it again and the plugin was
still installed in the iOS platform again.

Whats the recommended way to exclude plugins from certain platforms?

Re: Why doesn't `cordova.requestPermission` have an `callbackContext` arg?

[Philipp Kursawe]

I see. Cordova already uses a `permissionResultCallbacks` that holds the
user provided `requestCode`. It could additionally hold the
`callbackContext`.
And when android calls `CordovaInterfaceImpl.onRequestPermissionResult` it
could call a new plugin function with a new signature that contains the
`callbackContext`.


On Tue, Jun 28, 2016 at 10:36 AM, julio cesar sanchez <
jcesarmob...@gmail.com> wrote:

> onRequestPermissionResult is an Android method we have to override, so we
> can't choose which params to pass.
>
>
> https://developer.android.com/reference/android/support/v4/app/ActivityCompat.OnRequestPermissionsResultCallback.html
>
>
> 2016-06-28 10:29 GMT+02:00 Philipp Kursawe <phil.kurs...@gmail.com>:
>
> > I wonder about this API design decision.
> >
> > The current API forces us to save the callback context in some state
> > variable to have access to it
> > in the plugins `onRequestPermissionResult` like this:
> >
> > private void requestPermissionAction(CallbackContext callbackContext,
> > JSONArray permission) {
> >   this.permissionsCallback = callbackContext;
> >   cordova.requestPermission(this, REQUEST_CODE_ENABLE_PERMISSION,
> > permission.getString(0));
> > }
> >
> > @Override
> > public void onRequestPermissionResult(int requestCode, String[]
> > permissions, int[] grantResults) {
> >   if (this.permissionsCallback == null) {
> > return;
> >   }
> >
> >   if (permissions != null && permissions.length > 0) {
> > this.permissionsCallback.success();
> >   } else {
> > this.permissionsCallback.error("No permission");
> >   }
> >   this.permissionsCallback = null;
> > }
> >
> > This works but limits the concurrent calls to the plugins
> > `requestPermissionAction` to one caller from the script at a time (that
> > means until the success or error callbacks are called in the script).
> > Otherwise the `this.permissionCallback` would be set again for a second
> > call and when the first calls `onRequestPermissionResult` is called it
> will
> > actually call the handlers of the second `requestPermissionAction`
> > callbackContext.
> >
> > Wouldn't this API signature make more sense?
> >
> > cordova.requestPermission(CordovaPlugin plugin, int requestCode, String
> > permission, CallbackContext callbackContext);
> >
> > @Override
> > public void onRequestPermissionResult(int requestCode, String[]
> > permissions, int[] grantResults, CallbackContext callbackContext) {
> >   if (permissions != null && permissions.length > 0) {
> > permissionsCallback.success();
> >   } else {
> > permissionsCallback.error("No permission");
> >   }
> > }
> >
> >
> > And while we are at: Change `permission[]` and `grantResults[]` to an
> > object `results[permission] = grantResult`?
> >
>

Why doesn't `cordova.requestPermission` have an `callbackContext` arg?

[Philipp Kursawe]

I wonder about this API design decision.

The current API forces us to save the callback context in some state
variable to have access to it
in the plugins `onRequestPermissionResult` like this:

private void requestPermissionAction(CallbackContext callbackContext,
JSONArray permission) {
  this.permissionsCallback = callbackContext;
  cordova.requestPermission(this, REQUEST_CODE_ENABLE_PERMISSION,
permission.getString(0));
}

@Override
public void onRequestPermissionResult(int requestCode, String[]
permissions, int[] grantResults) {
  if (this.permissionsCallback == null) {
return;
  }

  if (permissions != null && permissions.length > 0) {
this.permissionsCallback.success();
  } else {
this.permissionsCallback.error("No permission");
  }
  this.permissionsCallback = null;
}

This works but limits the concurrent calls to the plugins
`requestPermissionAction` to one caller from the script at a time (that
means until the success or error callbacks are called in the script).
Otherwise the `this.permissionCallback` would be set again for a second
call and when the first calls `onRequestPermissionResult` is called it will
actually call the handlers of the second `requestPermissionAction`
callbackContext.

Wouldn't this API signature make more sense?

cordova.requestPermission(CordovaPlugin plugin, int requestCode, String
permission, CallbackContext callbackContext);

@Override
public void onRequestPermissionResult(int requestCode, String[]
permissions, int[] grantResults, CallbackContext callbackContext) {
  if (permissions != null && permissions.length > 0) {
permissionsCallback.success();
  } else {
permissionsCallback.error("No permission");
  }
}


And while we are at: Change `permission[]` and `grantResults[]` to an
object `results[permission] = grantResult`?

Is there a way to wait for another plugin to initialize

[Philipp Kursawe]

I have a plugin that depends on another plugin being initialized first.
Does cordova already provide a documented way of doing that through
channels?

Coming from OSGi I'm thinking of something non-blocking like Plugin B is
only started if Plugin has been started.

Re: [Discuss] Why was device.name removed from the device-plugin?

[Philipp Kursawe]

> that might bring some trouble if the device doesn't have
bluetooth. We should decide what to return in that case, nothing? and
document it

We return manufactur + model in that case.

@Joe: the devices I checked had pretty useful BT sharing names. And it is
functionality belonging to the device. Where else would it belong to?

On Sat, Jun 18, 2016 at 12:42 AM, Joe Bowser <bows...@gmail.com> wrote:

> -1
>
> This is a new feature and something we never supported.
>
> The model feature was the user-readable type of phone on Android (i.e.
> Nexus 5X) where the name was the in-house codename for it, in this case
> bullhead.  When we switched to device.model, we removed device.name.
> Getting the Bluetooth sharing name could literally be anything like
> "MyHovercraftIsFullOfEels" or "ThisRentalCarSucks".
>
> This is entirely new functionality, and I think that it should exist in a
> separate plugin.
>
>
>
> On Fri, Jun 17, 2016 at 3:25 PM, julio cesar sanchez <
> jcesarmob...@gmail.com
> > wrote:
>
> > +1
> >
> > The only thing I see is the plugin he points get the android name from
> the
> > bluetooth adapter, that might bring some trouble if the device doesn't
> have
> > bluetooth. We should decide what to return in that case, nothing? and
> > document it
> >
> > 2016-06-18 0:15 GMT+02:00 Shazron <shaz...@gmail.com>:
> >
> > > I have no objection if the API property is unambiguous, unlike what it
> > was
> > > before (over 4 years ago!), and is supported by all the major platforms
> > > (looks like it is, from what you mentioned). Also -- Ubuntu/Linux looks
> > > like its just /etc/hostname. We'll just have to bump a minor version.
> > >
> > > What do the others think?
> > >
> > >
> > >
> > > On Fri, Jun 17, 2016 at 3:07 PM, Philipp Kursawe <
> phil.kurs...@gmail.com
> > >
> > > wrote:
> > >
> > > > To further emphasize one point. I fully agree with moving from
> > > device.name
> > > > to device.model + device.manufacturer + device.platform.
> > > > But I still ask all of you do consider bringing back a proper
> > > device.name.
> > > > As I wrote, on Windows its pretty easy to get the real name of the
> > > > PC/Phone. On iOS and Android the work is already done.
> > > >
> > > > On Sat, Jun 18, 2016 at 12:02 AM, Philipp Kursawe <
> > > phil.kurs...@gmail.com>
> > > > wrote:
> > > >
> > > > > Thanks for pointing this out. However the name is not used to
> > reference
> > > > > the device to the API. Thats what the device.uuid is being used
> for.
> > > The
> > > > > device name is used in the UI where the user can see its API
> enabled
> > > > > devices. You don't want to show the user the device id there (cause
> > she
> > > > has
> > > > > no point of reference to which physical device it belongs) but the
> > name
> > > > she
> > > > > gave her phone and knows her phone when she connects it to itunes,
> > > iphoto
> > > > > etc.
> > > > >
> > > > > So the reason to introduce the name property back is exactly the
> one
> > > you
> > > > > mentioned: The user can always change the name of her phone and
> there
> > > > knows
> > > > > its name and will recognize it in a list of devices.
> > > > >
> > > > > On Fri, Jun 17, 2016 at 9:23 PM, Shazron <shaz...@gmail.com>
> wrote:
> > > > >
> > > > >> Hi Philipp,
> > > > >> This was the rationale:
> > > > >>
> > > > >>
> > > >
> > >
> >
> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
> > > > >>
> > > > >> On iOS,  [UIDevice name] returns the name the user sets in iTunes
> > for
> > > > >> their
> > > > >> device i.e. "Shazron's iPhone 4", and can change anytime so
> relying
> > on
> > > > it
> > > > >> for API access would be problematic.
> > > > >>
> > > > >>
> > > > >> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe <
> > > > phil.kurs...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > I wonder why such an important piece of information is not
> > provided
> > > > >> anymore
> > > > >> > in the device plugin?
> > > > >> > What was the reason to remove the property?
> > > > >> >
> > > > >> > The name of the device, especially when users can
> authorise/revoke
> > > API
> > > > >> > access to apps on different devices, is an important variable to
> > > know.
> > > > >> >
> > > > >> > There is a plugin that brings back this functionality for
> Android,
> > > iOS
> > > > >> and
> > > > >> > for Windows it would be a one-liner only too.
> > > > >> > https://github.com/becvert/cordova-plugin-device-name
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: [Discuss] Why was device.name removed from the device-plugin?

[Philipp Kursawe]

To further emphasize one point. I fully agree with moving from device.name
to device.model + device.manufacturer + device.platform.
But I still ask all of you do consider bringing back a proper device.name.
As I wrote, on Windows its pretty easy to get the real name of the
PC/Phone. On iOS and Android the work is already done.

On Sat, Jun 18, 2016 at 12:02 AM, Philipp Kursawe <phil.kurs...@gmail.com>
wrote:

> Thanks for pointing this out. However the name is not used to reference
> the device to the API. Thats what the device.uuid is being used for. The
> device name is used in the UI where the user can see its API enabled
> devices. You don't want to show the user the device id there (cause she has
> no point of reference to which physical device it belongs) but the name she
> gave her phone and knows her phone when she connects it to itunes, iphoto
> etc.
>
> So the reason to introduce the name property back is exactly the one you
> mentioned: The user can always change the name of her phone and there knows
> its name and will recognize it in a list of devices.
>
> On Fri, Jun 17, 2016 at 9:23 PM, Shazron <shaz...@gmail.com> wrote:
>
>> Hi Philipp,
>> This was the rationale:
>>
>> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
>>
>> On iOS,  [UIDevice name] returns the name the user sets in iTunes for
>> their
>> device i.e. "Shazron's iPhone 4", and can change anytime so relying on it
>> for API access would be problematic.
>>
>>
>> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe <phil.kurs...@gmail.com>
>> wrote:
>>
>> > I wonder why such an important piece of information is not provided
>> anymore
>> > in the device plugin?
>> > What was the reason to remove the property?
>> >
>> > The name of the device, especially when users can authorise/revoke API
>> > access to apps on different devices, is an important variable to know.
>> >
>> > There is a plugin that brings back this functionality for Android, iOS
>> and
>> > for Windows it would be a one-liner only too.
>> > https://github.com/becvert/cordova-plugin-device-name
>> >
>>
>
>

Re: [Discuss] Why was device.name removed from the device-plugin?

[Philipp Kursawe]

Thanks for pointing this out. However the name is not used to reference the
device to the API. Thats what the device.uuid is being used for. The device
name is used in the UI where the user can see its API enabled devices. You
don't want to show the user the device id there (cause she has no point of
reference to which physical device it belongs) but the name she gave her
phone and knows her phone when she connects it to itunes, iphoto etc.

So the reason to introduce the name property back is exactly the one you
mentioned: The user can always change the name of her phone and there knows
its name and will recognize it in a list of devices.

On Fri, Jun 17, 2016 at 9:23 PM, Shazron <shaz...@gmail.com> wrote:

> Hi Philipp,
> This was the rationale:
>
> https://lists.apache.org/thread.html/e3b0e5f87ba3929d5578308b25ee9a6af5b91177b94015878970fa8e@1352248856@%3Cdev.cordova.apache.org%3E
>
> On iOS,  [UIDevice name] returns the name the user sets in iTunes for their
> device i.e. "Shazron's iPhone 4", and can change anytime so relying on it
> for API access would be problematic.
>
>
> On Fri, Jun 17, 2016 at 1:51 AM, Philipp Kursawe <phil.kurs...@gmail.com>
> wrote:
>
> > I wonder why such an important piece of information is not provided
> anymore
> > in the device plugin?
> > What was the reason to remove the property?
> >
> > The name of the device, especially when users can authorise/revoke API
> > access to apps on different devices, is an important variable to know.
> >
> > There is a plugin that brings back this functionality for Android, iOS
> and
> > for Windows it would be a one-liner only too.
> > https://github.com/becvert/cordova-plugin-device-name
> >
>

[Discuss] Why was device.name removed from the device-plugin?

[Philipp Kursawe]

I wonder why such an important piece of information is not provided anymore
in the device plugin?
What was the reason to remove the property?

The name of the device, especially when users can authorise/revoke API
access to apps on different devices, is an important variable to know.

There is a plugin that brings back this functionality for Android, iOS and
for Windows it would be a one-liner only too.
https://github.com/becvert/cordova-plugin-device-name

[Plugin: Geolocation] Wrong permission message displayed

[Philipp Kursawe]

I tried to post this to the issue tracker, but it would just spin the
spinner and never let met create the issue.


So I post it here instead:


-

When having this react component

{code}
import React from "react"
import { connect } from "react-redux"
import { update } from "../geolocationActions"

class GeoLocation extends React.Component {
  constructor(props) {
super(props)
this.updatePosition = position => props.update(position)
this.onError = () => props.update(null)
  }

  componentWillMount() {
this.watchId = navigator.geolocation.watchPosition(this.updatePosition,
this.onError)
  }

  componentWillUnmount() {
navigator.geolocation.clearWatch(this.watchId)
  }

  render() {
return null
  }
}
GeoLocation.propTypes = {
  update: React.PropTypes.func.isRequired,
}
export default connect(null, { update })(GeoLocation)
{code}

Sometimes the phone displays the correct permission question:
https://1drv.ms/i/s!AjrwWLsSkwcs1YlgMrdeK9AvkCwe7g

but sometimes (even right after the first dialog) another dialog is
displayed and the app hangs after it has been closed.
https://1drv.ms/i/s!AjrwWLsSkwcs1YlfkCT9F6OKUK9iRQ

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

[Philipp Kursawe]

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..
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: [DISCUSS] Deprecate cordova-wp8

[Philipp Kursawe]

+1
WP8 always dragged in the C# runtime which increased memory footprint.
Most of the things that plugins for WP8 do can now be better done in WinRT,
which is available from Windows Phone 8.1.

On Thu, Dec 10, 2015 at 4:44 AM, Sergio Nader <
sergio.na...@brasilisdigital.com.br> wrote:

> Thanks, Julio. I really have missed the answer.
> Regards!
>
> Sérgio Nader
>
> Skype: sergio.nader.br
>
> Tel: 55 11 9 9101 4590
>
>
>
> ​www.brasilisdigital.com.br
>
> Tecnologia & Inovação​
>
>
> On Thu, Dec 10, 2015 at 1:29 AM, Tommy Williams 
> wrote:
>
> > +1
> >
> >
> >
> >
> > > On 9 Dec 2015, at 9:45 AM, Jesse  wrote:
> > >
> > > Deprecation is not the end, just the beginning of it.
> >
> >
>

[DISCUSS] Loading plugins async or on demand

[Philipp Kursawe]

I am new to the list, and somewhat new to Cordova.

I wonder why all plugins are loaded before "deviceready" is emitted? I
understand for plugins that extend the hosts "navigator" object to mimic
webbrowser functionality like location or sensors you might want to have
them guaranteed to be accessible via global objects on "navigator" once the
app has been loaded.
Was there ever an async/on demand approach considered?
Like "cordova.getPlugin("plugin.google.maps").then(maps) {}"

I am asking because I would like to reduce the startup time. Loading the
webview already takes a lot of time. Loading all JS takes another fair
amount of time all the while cordova is busy loading all plugins. And I
don't need any of those plugins functionality right after startup.

Happy coding,
Phil