You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Becky Gibson <gi...@gmail.com> on 2012/03/19 15:45:39 UTC
Plan for device specific APIs?
What is the plan for the device specific APIs that have existed in the
platform JS files? For example, iOS has a more efficient api for watching
the compass heading, watchHeadingFilter and clearWatchFilter. iOS also
has apis for bringing up the native contact picker to display, select or
edit a contact. Are we still going to provide those in the device
specific js files? Will they become "general" plugins? Perhaps an optional
"core" plugin? I don't think we should lose this functionality and it
should somehow be available with 1.6.
-becky
Re: Plan for device specific APIs?
Posted by Filip Maj <fi...@adobe.com>.
One more thing: the specific implementation changes to cordova-js (for
platform overrides and cleaning up the platform definition files) is being
tracked in that issue Pat linked to:
https://issues.apache.org/jira/browse/CB-280
On 3/19/12 10:43 AM, "Filip Maj" <fi...@adobe.com> wrote:
>+1 from me in everything turning into a plugin down the road.
>+1 for refactoring the filter method into a "quirk" property of the
>Compass Options that is iOS-specific
>
>And yes, currently the overriding/merging implementation in the JS is not
>optimized. As Pat says, we are wasting bytes every time we do a
>platform-specific merge or override. That being said, putting a bit more
>love into the build process and platform definition files can solve that
>problem.
>
>On 3/19/12 10:39 AM, "Jesse MacFadyen" <pu...@gmail.com> wrote:
>
>>I think the 2 iOS calls for compass can coexist peacefully if it is
>>refactored to use the filter value as an option in the original call
>>to watchHeading. Other platforms could ignore this option, or even
>>implement it and this could be considered a quirk. Exposing another
>>method on compass, (and presumably possibly geolocation, and
>>accelerometer) for this makes no sense to me.
>>
>>For contact picker functionality IMHO this should be a plugin, but
>>that does not mean it cannot augment the existing navigator.contact
>>object.
>>
>>Cheers,
>> Jesse
>>
>>Sent from my iPhone5
>>
>>On 2012-03-19, at 10:16 AM, Becky Gibson <gi...@gmail.com> wrote:
>>
>>>> No, the user would NEVER have to add the new modules/plugin, the build
>>>> would "make it so". Is that what you mean by API? Or do you mean the
>>>>iOS
>>>> compass API is SUPPOSED to be different than the portable compass API?
>>>> I
>>>> thought the idea with the 'device-specific' APIs is that a platform
>>>>could
>>>> provide an alternate implementation that had the exact same interface.
>>>> In
>>>> the iOS compass case, providing an alternate, closer-to-the-metal,
>>>>more
>>>> performant implementation, that still matched the Cordova portable API
>>>>for
>>>> compass.
>>>
>>> We are on the same page, here. I guess I didn't explain it well
>>>enough.
>>> iOS DOES implement the 'portable' compass apis which request compass
>>> headings over time. People developing a cross platform application
>>>would
>>> want to use the portable apis. However, iOS has additional apis that
>>>are
>>> better suited to reading the compass changes on iOS based on a distance
>>> filter rather than over time. I want to add these device specific apis
>>> into the compass object so someone who is developing only for iOS OR
>>>who is
>>> willing to have divergence in their HTML/JS code could take advantage
>>>of
>>> the more efficient api for iOS. I just don't understand what our
>>>mechanism
>>> is/will be for achieving this. The same goes for Contacts - iOS has
>>> ADDITIONAL features that are currently implemented off of the contact
>>> object.
>>>
>>> I don't want to add them using our current plugin implementation
>>>because
>>> that creates a new JS api -window.plugins.compass.watchHeadingFilter
>>> rather than the current navigator.compass.watchHeadingFilter. But,
>>>I'm
>>> not sure if this type of extension is in our plans?
>>>
>>> -becky
>>>
>>> On Mon, Mar 19, 2012 at 12:37 PM, Patrick Mueller <pm...@gmail.com>
>>>wrote:
>>>
>>>> On Mon, Mar 19, 2012 at 12:16, Becky Gibson <gi...@gmail.com>
>>>> wrote:
>>>>
>>>>> Ok, so I understand the desire for the JS to be "unified" for
>>>>>development
>>>>> and testing purposes however, we still do have device specific
>>>>>versions
>>>> of
>>>>> the main Cordova javascript file. Thus, I don't see why we can't
>>>>>add
>>>> the
>>>>> device specific API's that were already there, back into the "main"
>>>>>JS?
>>>> If
>>>>> we do not, then we have broken the existing apis. A person that was
>>>> using
>>>>> the iOS device specific contact apis, now has to add in a plugin and
>>>> modify
>>>>> their code to use a different namespace for these apis.
>>>>>
>>>>
>>>> There's a couple of thoughts here. I DO want to allow for
>>>> 'platform-specific module implementations' for things like compass.
>>>>The
>>>> only question is how to easily integrate this into the existing source
>>>> directories, and the build.
>>>>
>>>> re: "we have broken the existing apis. A person that was using the iOS
>>>> device specific contact apis, now has to add in a plugin and modify
>>>>their
>>>> code to use a different namespace for these apis."
>>>>
>>>> No, the user would NEVER have to add the new modules/plugin, the build
>>>> would "make it so". Is that what you mean by API? Or do you mean the
>>>>iOS
>>>> compass API is SUPPOSED to be different than the portable compass API?
>>>> I
>>>> thought the idea with the 'device-specific' APIs is that a platform
>>>>could
>>>> provide an alternate implementation that had the exact same interface.
>>>> In
>>>> the iOS compass case, providing an alternate, closer-to-the-metal,
>>>>more
>>>> performant implementation, that still matched the Cordova portable API
>>>>for
>>>> compass.
>>>>
>>>>> I continue to dream of the day when all our
>>>>>> existing "plugins" are structured as 3rd party plugins anyway.
>>>>>
>>>>> However, I don't believe we plan to get to this goal for 1.6. I also
>>>> don't
>>>>> believe we will have a mechanism for the user to modify a "standard"
>>>>>file
>>>>> to select just the features they want in the main cordova js file or
>>>>>to
>>>>> extend existing objects in the JS file for 1.6? Thus, when this
>>>>>does
>>>> get
>>>>> implemented they will again have to modify their code to adjust the
>>>> api's.
>>>>> I think it would be best to mitigate as much of this churn as
>>>>>possible.
>>>>> IOW I'm advocating for adding the device specific api's into the 1.6
>>>>>main
>>>>> cordova js file with the idea that eventually they could be removed
>>>>>when
>>>> we
>>>>> provide a user option to selectively add them back in.
>>>>
>>>>
>>>> I don't think that a user of a Cordova plugin, whether it's provided
>>>>by us,
>>>> or someone else, in the long term, should even have a choice of
>>>>whether
>>>> they get the 'device specific' or 'portable' implementation. That's
>>>>up to
>>>> the plugin provider to decide. If some user REALLY, REALLY wants to
>>>> override the implementation of the provider of the plugin, now you're
>>>> venturing into "fork" territory. Which is absolutely fine, assuming
>>>>you
>>>> know what you're doing.
>>>>
>>>> --
>>>> Patrick Mueller
>>>> http://muellerware.org
>>>>
>
Re: Plan for device specific APIs?
Posted by Filip Maj <fi...@adobe.com>.
+1 from me in everything turning into a plugin down the road.
+1 for refactoring the filter method into a "quirk" property of the
Compass Options that is iOS-specific
And yes, currently the overriding/merging implementation in the JS is not
optimized. As Pat says, we are wasting bytes every time we do a
platform-specific merge or override. That being said, putting a bit more
love into the build process and platform definition files can solve that
problem.
On 3/19/12 10:39 AM, "Jesse MacFadyen" <pu...@gmail.com> wrote:
>I think the 2 iOS calls for compass can coexist peacefully if it is
>refactored to use the filter value as an option in the original call
>to watchHeading. Other platforms could ignore this option, or even
>implement it and this could be considered a quirk. Exposing another
>method on compass, (and presumably possibly geolocation, and
>accelerometer) for this makes no sense to me.
>
>For contact picker functionality IMHO this should be a plugin, but
>that does not mean it cannot augment the existing navigator.contact
>object.
>
>Cheers,
> Jesse
>
>Sent from my iPhone5
>
>On 2012-03-19, at 10:16 AM, Becky Gibson <gi...@gmail.com> wrote:
>
>>> No, the user would NEVER have to add the new modules/plugin, the build
>>> would "make it so". Is that what you mean by API? Or do you mean the
>>>iOS
>>> compass API is SUPPOSED to be different than the portable compass API?
>>> I
>>> thought the idea with the 'device-specific' APIs is that a platform
>>>could
>>> provide an alternate implementation that had the exact same interface.
>>> In
>>> the iOS compass case, providing an alternate, closer-to-the-metal, more
>>> performant implementation, that still matched the Cordova portable API
>>>for
>>> compass.
>>
>> We are on the same page, here. I guess I didn't explain it well
>>enough.
>> iOS DOES implement the 'portable' compass apis which request compass
>> headings over time. People developing a cross platform application would
>> want to use the portable apis. However, iOS has additional apis that
>>are
>> better suited to reading the compass changes on iOS based on a distance
>> filter rather than over time. I want to add these device specific apis
>> into the compass object so someone who is developing only for iOS OR
>>who is
>> willing to have divergence in their HTML/JS code could take advantage of
>> the more efficient api for iOS. I just don't understand what our
>>mechanism
>> is/will be for achieving this. The same goes for Contacts - iOS has
>> ADDITIONAL features that are currently implemented off of the contact
>> object.
>>
>> I don't want to add them using our current plugin implementation because
>> that creates a new JS api -window.plugins.compass.watchHeadingFilter
>> rather than the current navigator.compass.watchHeadingFilter. But, I'm
>> not sure if this type of extension is in our plans?
>>
>> -becky
>>
>> On Mon, Mar 19, 2012 at 12:37 PM, Patrick Mueller <pm...@gmail.com>
>>wrote:
>>
>>> On Mon, Mar 19, 2012 at 12:16, Becky Gibson <gi...@gmail.com>
>>> wrote:
>>>
>>>> Ok, so I understand the desire for the JS to be "unified" for
>>>>development
>>>> and testing purposes however, we still do have device specific
>>>>versions
>>> of
>>>> the main Cordova javascript file. Thus, I don't see why we can't add
>>> the
>>>> device specific API's that were already there, back into the "main"
>>>>JS?
>>> If
>>>> we do not, then we have broken the existing apis. A person that was
>>> using
>>>> the iOS device specific contact apis, now has to add in a plugin and
>>> modify
>>>> their code to use a different namespace for these apis.
>>>>
>>>
>>> There's a couple of thoughts here. I DO want to allow for
>>> 'platform-specific module implementations' for things like compass.
>>>The
>>> only question is how to easily integrate this into the existing source
>>> directories, and the build.
>>>
>>> re: "we have broken the existing apis. A person that was using the iOS
>>> device specific contact apis, now has to add in a plugin and modify
>>>their
>>> code to use a different namespace for these apis."
>>>
>>> No, the user would NEVER have to add the new modules/plugin, the build
>>> would "make it so". Is that what you mean by API? Or do you mean the
>>>iOS
>>> compass API is SUPPOSED to be different than the portable compass API?
>>> I
>>> thought the idea with the 'device-specific' APIs is that a platform
>>>could
>>> provide an alternate implementation that had the exact same interface.
>>> In
>>> the iOS compass case, providing an alternate, closer-to-the-metal, more
>>> performant implementation, that still matched the Cordova portable API
>>>for
>>> compass.
>>>
>>>> I continue to dream of the day when all our
>>>>> existing "plugins" are structured as 3rd party plugins anyway.
>>>>
>>>> However, I don't believe we plan to get to this goal for 1.6. I also
>>> don't
>>>> believe we will have a mechanism for the user to modify a "standard"
>>>>file
>>>> to select just the features they want in the main cordova js file or
>>>>to
>>>> extend existing objects in the JS file for 1.6? Thus, when this does
>>> get
>>>> implemented they will again have to modify their code to adjust the
>>> api's.
>>>> I think it would be best to mitigate as much of this churn as
>>>>possible.
>>>> IOW I'm advocating for adding the device specific api's into the 1.6
>>>>main
>>>> cordova js file with the idea that eventually they could be removed
>>>>when
>>> we
>>>> provide a user option to selectively add them back in.
>>>
>>>
>>> I don't think that a user of a Cordova plugin, whether it's provided
>>>by us,
>>> or someone else, in the long term, should even have a choice of whether
>>> they get the 'device specific' or 'portable' implementation. That's
>>>up to
>>> the plugin provider to decide. If some user REALLY, REALLY wants to
>>> override the implementation of the provider of the plugin, now you're
>>> venturing into "fork" territory. Which is absolutely fine, assuming
>>>you
>>> know what you're doing.
>>>
>>> --
>>> Patrick Mueller
>>> http://muellerware.org
>>>
Re: Plan for device specific APIs?
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Mar 19, 2012 at 15:09, Becky Gibson <gi...@gmail.com> wrote:
> Not to belabor the point but I want to make sure we all understand the
> details.
>
> ... details ...
>
> Thus, there are no additional JavaScript apis for iOS, the optional
> implementation is hidden in the existing watchFilter api. However, it does
> have the implication that iOS will now have a device specific
> implementation of the JavaScript watchHeading definition. I assume folks
> are comfortable with that?
+1
As long as the programming interface is the same as other platforms (modulo
'platform-specific' option properties), and the behavior is the same as
other platforms, platforms should be able to replace the 'common'
implementation with their own.
Perhaps it will get tricky when folks want to leverage 'common' code in
platform-specific versions of their plugins. We'll see.
--
Patrick Mueller
http://muellerware.org
Re: Plan for device specific APIs?
Posted by Filip Maj <fi...@adobe.com>.
I think the benefits outweigh the negatives in this case. We would need to
document this approach somewhere though.
On 3/19/12 12:09 PM, "Becky Gibson" <gi...@gmail.com> wrote:
>Not to belabor the point but I want to make sure we all understand the
>details.
>
>The whole idea behind changing the iOS implementation is to make it more
>efficient and NOT use a timer to request the heading. However, the
>watchHeading Javascript is written to repeatedly call the device
>getHeading
>api based on a timer. In order to implement the more iOS specific
>version
>with a filter option I will need iOS specific JavaScript code. This code
>would use the standard timer implementation if no filter parameter if
>provided but would call out to the iOS watchHeadingFilter device
>implementation if one is provided.
>
>
>Thus, there are no additional JavaScript apis for iOS, the optional
>implementation is hidden in the existing watchFilter api. However, it
>does
>have the implication that iOS will now have a device specific
>implementation of the JavaScript watchHeading definition. I assume folks
>are comfortable with that?
>
>-becky
>
>
>On Mon, Mar 19, 2012 at 2:10 PM, Patrick Mueller <pm...@gmail.com>
>wrote:
>
>> Ah, I see what you're talking about now Becky.
>>
>> On Mon, Mar 19, 2012 at 13:39, Jesse MacFadyen <purplecabbage@gmail.com
>> >wrote:
>>
>> > I think the 2 iOS calls for compass can coexist peacefully if it is
>> > refactored to use the filter value as an option in the original call
>> > to watchHeading. Other platforms could ignore this option, or even
>> > implement it and this could be considered a quirk. Exposing another
>> > method on compass, (and presumably possibly geolocation, and
>> > accelerometer) for this makes no sense to me.
>> >
>>
>> +1 on enabling additional functionality via 'options' passed to an API
>> +1 on not adding additional methods to enable additional functionality
>>in
>> an API
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
>>
Re: Plan for device specific APIs?
Posted by Becky Gibson <gi...@gmail.com>.
Not to belabor the point but I want to make sure we all understand the
details.
The whole idea behind changing the iOS implementation is to make it more
efficient and NOT use a timer to request the heading. However, the
watchHeading Javascript is written to repeatedly call the device getHeading
api based on a timer. In order to implement the more iOS specific version
with a filter option I will need iOS specific JavaScript code. This code
would use the standard timer implementation if no filter parameter if
provided but would call out to the iOS watchHeadingFilter device
implementation if one is provided.
Thus, there are no additional JavaScript apis for iOS, the optional
implementation is hidden in the existing watchFilter api. However, it does
have the implication that iOS will now have a device specific
implementation of the JavaScript watchHeading definition. I assume folks
are comfortable with that?
-becky
On Mon, Mar 19, 2012 at 2:10 PM, Patrick Mueller <pm...@gmail.com> wrote:
> Ah, I see what you're talking about now Becky.
>
> On Mon, Mar 19, 2012 at 13:39, Jesse MacFadyen <purplecabbage@gmail.com
> >wrote:
>
> > I think the 2 iOS calls for compass can coexist peacefully if it is
> > refactored to use the filter value as an option in the original call
> > to watchHeading. Other platforms could ignore this option, or even
> > implement it and this could be considered a quirk. Exposing another
> > method on compass, (and presumably possibly geolocation, and
> > accelerometer) for this makes no sense to me.
> >
>
> +1 on enabling additional functionality via 'options' passed to an API
> +1 on not adding additional methods to enable additional functionality in
> an API
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: Plan for device specific APIs?
Posted by Patrick Mueller <pm...@gmail.com>.
Ah, I see what you're talking about now Becky.
On Mon, Mar 19, 2012 at 13:39, Jesse MacFadyen <pu...@gmail.com>wrote:
> I think the 2 iOS calls for compass can coexist peacefully if it is
> refactored to use the filter value as an option in the original call
> to watchHeading. Other platforms could ignore this option, or even
> implement it and this could be considered a quirk. Exposing another
> method on compass, (and presumably possibly geolocation, and
> accelerometer) for this makes no sense to me.
>
+1 on enabling additional functionality via 'options' passed to an API
+1 on not adding additional methods to enable additional functionality in
an API
--
Patrick Mueller
http://muellerware.org
Re: Plan for device specific APIs?
Posted by Jesse MacFadyen <pu...@gmail.com>.
I think the 2 iOS calls for compass can coexist peacefully if it is
refactored to use the filter value as an option in the original call
to watchHeading. Other platforms could ignore this option, or even
implement it and this could be considered a quirk. Exposing another
method on compass, (and presumably possibly geolocation, and
accelerometer) for this makes no sense to me.
For contact picker functionality IMHO this should be a plugin, but
that does not mean it cannot augment the existing navigator.contact
object.
Cheers,
Jesse
Sent from my iPhone5
On 2012-03-19, at 10:16 AM, Becky Gibson <gi...@gmail.com> wrote:
>> No, the user would NEVER have to add the new modules/plugin, the build
>> would "make it so". Is that what you mean by API? Or do you mean the iOS
>> compass API is SUPPOSED to be different than the portable compass API? I
>> thought the idea with the 'device-specific' APIs is that a platform could
>> provide an alternate implementation that had the exact same interface. In
>> the iOS compass case, providing an alternate, closer-to-the-metal, more
>> performant implementation, that still matched the Cordova portable API for
>> compass.
>
> We are on the same page, here. I guess I didn't explain it well enough.
> iOS DOES implement the 'portable' compass apis which request compass
> headings over time. People developing a cross platform application would
> want to use the portable apis. However, iOS has additional apis that are
> better suited to reading the compass changes on iOS based on a distance
> filter rather than over time. I want to add these device specific apis
> into the compass object so someone who is developing only for iOS OR who is
> willing to have divergence in their HTML/JS code could take advantage of
> the more efficient api for iOS. I just don't understand what our mechanism
> is/will be for achieving this. The same goes for Contacts - iOS has
> ADDITIONAL features that are currently implemented off of the contact
> object.
>
> I don't want to add them using our current plugin implementation because
> that creates a new JS api -window.plugins.compass.watchHeadingFilter
> rather than the current navigator.compass.watchHeadingFilter. But, I'm
> not sure if this type of extension is in our plans?
>
> -becky
>
> On Mon, Mar 19, 2012 at 12:37 PM, Patrick Mueller <pm...@gmail.com> wrote:
>
>> On Mon, Mar 19, 2012 at 12:16, Becky Gibson <gi...@gmail.com>
>> wrote:
>>
>>> Ok, so I understand the desire for the JS to be "unified" for development
>>> and testing purposes however, we still do have device specific versions
>> of
>>> the main Cordova javascript file. Thus, I don't see why we can't add
>> the
>>> device specific API's that were already there, back into the "main" JS?
>> If
>>> we do not, then we have broken the existing apis. A person that was
>> using
>>> the iOS device specific contact apis, now has to add in a plugin and
>> modify
>>> their code to use a different namespace for these apis.
>>>
>>
>> There's a couple of thoughts here. I DO want to allow for
>> 'platform-specific module implementations' for things like compass. The
>> only question is how to easily integrate this into the existing source
>> directories, and the build.
>>
>> re: "we have broken the existing apis. A person that was using the iOS
>> device specific contact apis, now has to add in a plugin and modify their
>> code to use a different namespace for these apis."
>>
>> No, the user would NEVER have to add the new modules/plugin, the build
>> would "make it so". Is that what you mean by API? Or do you mean the iOS
>> compass API is SUPPOSED to be different than the portable compass API? I
>> thought the idea with the 'device-specific' APIs is that a platform could
>> provide an alternate implementation that had the exact same interface. In
>> the iOS compass case, providing an alternate, closer-to-the-metal, more
>> performant implementation, that still matched the Cordova portable API for
>> compass.
>>
>>> I continue to dream of the day when all our
>>>> existing "plugins" are structured as 3rd party plugins anyway.
>>>
>>> However, I don't believe we plan to get to this goal for 1.6. I also
>> don't
>>> believe we will have a mechanism for the user to modify a "standard" file
>>> to select just the features they want in the main cordova js file or to
>>> extend existing objects in the JS file for 1.6? Thus, when this does
>> get
>>> implemented they will again have to modify their code to adjust the
>> api's.
>>> I think it would be best to mitigate as much of this churn as possible.
>>> IOW I'm advocating for adding the device specific api's into the 1.6 main
>>> cordova js file with the idea that eventually they could be removed when
>> we
>>> provide a user option to selectively add them back in.
>>
>>
>> I don't think that a user of a Cordova plugin, whether it's provided by us,
>> or someone else, in the long term, should even have a choice of whether
>> they get the 'device specific' or 'portable' implementation. That's up to
>> the plugin provider to decide. If some user REALLY, REALLY wants to
>> override the implementation of the provider of the plugin, now you're
>> venturing into "fork" territory. Which is absolutely fine, assuming you
>> know what you're doing.
>>
>> --
>> Patrick Mueller
>> http://muellerware.org
>>
Re: Plan for device specific APIs?
Posted by Becky Gibson <gi...@gmail.com>.
>No, the user would NEVER have to add the new modules/plugin, the build
>would "make it so". Is that what you mean by API? Or do you mean the iOS
>compass API is SUPPOSED to be different than the portable compass API? I
>thought the idea with the 'device-specific' APIs is that a platform could
>provide an alternate implementation that had the exact same interface. In
>the iOS compass case, providing an alternate, closer-to-the-metal, more
>performant implementation, that still matched the Cordova portable API for
>compass.
We are on the same page, here. I guess I didn't explain it well enough.
iOS DOES implement the 'portable' compass apis which request compass
headings over time. People developing a cross platform application would
want to use the portable apis. However, iOS has additional apis that are
better suited to reading the compass changes on iOS based on a distance
filter rather than over time. I want to add these device specific apis
into the compass object so someone who is developing only for iOS OR who is
willing to have divergence in their HTML/JS code could take advantage of
the more efficient api for iOS. I just don't understand what our mechanism
is/will be for achieving this. The same goes for Contacts - iOS has
ADDITIONAL features that are currently implemented off of the contact
object.
I don't want to add them using our current plugin implementation because
that creates a new JS api -window.plugins.compass.watchHeadingFilter
rather than the current navigator.compass.watchHeadingFilter. But, I'm
not sure if this type of extension is in our plans?
-becky
On Mon, Mar 19, 2012 at 12:37 PM, Patrick Mueller <pm...@gmail.com> wrote:
> On Mon, Mar 19, 2012 at 12:16, Becky Gibson <gi...@gmail.com>
> wrote:
>
> > Ok, so I understand the desire for the JS to be "unified" for development
> > and testing purposes however, we still do have device specific versions
> of
> > the main Cordova javascript file. Thus, I don't see why we can't add
> the
> > device specific API's that were already there, back into the "main" JS?
> If
> > we do not, then we have broken the existing apis. A person that was
> using
> > the iOS device specific contact apis, now has to add in a plugin and
> modify
> > their code to use a different namespace for these apis.
> >
>
> There's a couple of thoughts here. I DO want to allow for
> 'platform-specific module implementations' for things like compass. The
> only question is how to easily integrate this into the existing source
> directories, and the build.
>
> re: "we have broken the existing apis. A person that was using the iOS
> device specific contact apis, now has to add in a plugin and modify their
> code to use a different namespace for these apis."
>
> No, the user would NEVER have to add the new modules/plugin, the build
> would "make it so". Is that what you mean by API? Or do you mean the iOS
> compass API is SUPPOSED to be different than the portable compass API? I
> thought the idea with the 'device-specific' APIs is that a platform could
> provide an alternate implementation that had the exact same interface. In
> the iOS compass case, providing an alternate, closer-to-the-metal, more
> performant implementation, that still matched the Cordova portable API for
> compass.
>
> >I continue to dream of the day when all our
> > >existing "plugins" are structured as 3rd party plugins anyway.
> >
> > However, I don't believe we plan to get to this goal for 1.6. I also
> don't
> > believe we will have a mechanism for the user to modify a "standard" file
> > to select just the features they want in the main cordova js file or to
> > extend existing objects in the JS file for 1.6? Thus, when this does
> get
> > implemented they will again have to modify their code to adjust the
> api's.
> > I think it would be best to mitigate as much of this churn as possible.
> > IOW I'm advocating for adding the device specific api's into the 1.6 main
> > cordova js file with the idea that eventually they could be removed when
> we
> > provide a user option to selectively add them back in.
>
>
> I don't think that a user of a Cordova plugin, whether it's provided by us,
> or someone else, in the long term, should even have a choice of whether
> they get the 'device specific' or 'portable' implementation. That's up to
> the plugin provider to decide. If some user REALLY, REALLY wants to
> override the implementation of the provider of the plugin, now you're
> venturing into "fork" territory. Which is absolutely fine, assuming you
> know what you're doing.
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: Plan for device specific APIs?
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Mar 19, 2012 at 12:16, Becky Gibson <gi...@gmail.com> wrote:
> Ok, so I understand the desire for the JS to be "unified" for development
> and testing purposes however, we still do have device specific versions of
> the main Cordova javascript file. Thus, I don't see why we can't add the
> device specific API's that were already there, back into the "main" JS? If
> we do not, then we have broken the existing apis. A person that was using
> the iOS device specific contact apis, now has to add in a plugin and modify
> their code to use a different namespace for these apis.
>
There's a couple of thoughts here. I DO want to allow for
'platform-specific module implementations' for things like compass. The
only question is how to easily integrate this into the existing source
directories, and the build.
re: "we have broken the existing apis. A person that was using the iOS
device specific contact apis, now has to add in a plugin and modify their
code to use a different namespace for these apis."
No, the user would NEVER have to add the new modules/plugin, the build
would "make it so". Is that what you mean by API? Or do you mean the iOS
compass API is SUPPOSED to be different than the portable compass API? I
thought the idea with the 'device-specific' APIs is that a platform could
provide an alternate implementation that had the exact same interface. In
the iOS compass case, providing an alternate, closer-to-the-metal, more
performant implementation, that still matched the Cordova portable API for
compass.
>I continue to dream of the day when all our
> >existing "plugins" are structured as 3rd party plugins anyway.
>
> However, I don't believe we plan to get to this goal for 1.6. I also don't
> believe we will have a mechanism for the user to modify a "standard" file
> to select just the features they want in the main cordova js file or to
> extend existing objects in the JS file for 1.6? Thus, when this does get
> implemented they will again have to modify their code to adjust the api's.
> I think it would be best to mitigate as much of this churn as possible.
> IOW I'm advocating for adding the device specific api's into the 1.6 main
> cordova js file with the idea that eventually they could be removed when we
> provide a user option to selectively add them back in.
I don't think that a user of a Cordova plugin, whether it's provided by us,
or someone else, in the long term, should even have a choice of whether
they get the 'device specific' or 'portable' implementation. That's up to
the plugin provider to decide. If some user REALLY, REALLY wants to
override the implementation of the provider of the plugin, now you're
venturing into "fork" territory. Which is absolutely fine, assuming you
know what you're doing.
--
Patrick Mueller
http://muellerware.org
Re: Plan for device specific APIs?
Posted by Becky Gibson <gi...@gmail.com>.
Ok, so I understand the desire for the JS to be "unified" for development
and testing purposes however, we still do have device specific versions of
the main Cordova javascript file. Thus, I don't see why we can't add the
device specific API's that were already there, back into the "main" JS? If
we do not, then we have broken the existing apis. A person that was using
the iOS device specific contact apis, now has to add in a plugin and modify
their code to use a different namespace for these apis.
I agree with Pat,
>I continue to dream of the day when all our
>existing "plugins" are structured as 3rd party plugins anyway.
However, I don't believe we plan to get to this goal for 1.6. I also don't
believe we will have a mechanism for the user to modify a "standard" file
to select just the features they want in the main cordova js file or to
extend existing objects in the JS file for 1.6? Thus, when this does get
implemented they will again have to modify their code to adjust the api's.
I think it would be best to mitigate as much of this churn as possible.
IOW I'm advocating for adding the device specific api's into the 1.6 main
cordova js file with the idea that eventually they could be removed when we
provide a user option to selectively add them back in.
-becky
On Mon, Mar 19, 2012 at 11:23 AM, Patrick Mueller <pm...@gmail.com> wrote:
> On Mon, Mar 19, 2012 at 10:54, Drew Walters <pu...@gmail.com> wrote:
>
> > In the short term you can look at how BlackBerry uses the 'objects' and
> > 'merges' objects in the platform file to do complete replacement or api
> > level overrides.
>
>
> The only problem with this, is that we end up pulling in the original
> common source, as well. For instance, if you look at
> pkg/cordova.blackberry.js, you see that it includes the common
> cordova/plugin/notification module, as well as
> the cordova/plugin/blackberry/notification module. But the one used in the
> end is the blackberry one, and so the common one is just wasted bytes.
> Hopefully no one is accidentally using the common one between the time the
> common is set up and the blackberry one is installed.
>
> Issue https://issues.apache.org/jira/browse/CB-280 may help with this; eg,
> blackberry can provide it's own 'cordova/plugin/notification.js' module,
> which at build time would override the common one. The build would need to
> be a little smarter to do this, but not much.
>
> It's not a perfect answer, because it's crude - we would be allowing file
> overwriting by the platform. What if you to want to NOT have one of the
> common module files, for some reason - how do you 'delete' it, in the
> platform? We might just say: "there is no deletion, just create an empty
> module in the platform directory, and we'll end up creating a zero-line
> module". Perhaps you'd want to throw an error in that 'empty' module, just
> to make sure no one is using it, accidentally.
>
> I'm not sure we would even run into this case.
>
> But there's another complication that may arise here. Once we split the
> plugins directory into a set of directories per plugin (instead of having
> them all lumped together as now), what does 'override' mean? Do we
> override the entire directory? Or merge them? Merge sounds better, but
> obviously I think we'd need to see how well this would work for realz.
>
> Perhaps a better way to think about this is, what do we want 3rd party
> plugin developers to do? I continue to dream of the day when all our
> existing "plugins" are structured as 3rd party plugins anyway.
>
> --
> Patrick Mueller
> http://muellerware.org
>
Re: Plan for device specific APIs?
Posted by Patrick Mueller <pm...@gmail.com>.
On Mon, Mar 19, 2012 at 10:54, Drew Walters <pu...@gmail.com> wrote:
> In the short term you can look at how BlackBerry uses the 'objects' and
> 'merges' objects in the platform file to do complete replacement or api
> level overrides.
The only problem with this, is that we end up pulling in the original
common source, as well. For instance, if you look at
pkg/cordova.blackberry.js, you see that it includes the common
cordova/plugin/notification module, as well as
the cordova/plugin/blackberry/notification module. But the one used in the
end is the blackberry one, and so the common one is just wasted bytes.
Hopefully no one is accidentally using the common one between the time the
common is set up and the blackberry one is installed.
Issue https://issues.apache.org/jira/browse/CB-280 may help with this; eg,
blackberry can provide it's own 'cordova/plugin/notification.js' module,
which at build time would override the common one. The build would need to
be a little smarter to do this, but not much.
It's not a perfect answer, because it's crude - we would be allowing file
overwriting by the platform. What if you to want to NOT have one of the
common module files, for some reason - how do you 'delete' it, in the
platform? We might just say: "there is no deletion, just create an empty
module in the platform directory, and we'll end up creating a zero-line
module". Perhaps you'd want to throw an error in that 'empty' module, just
to make sure no one is using it, accidentally.
I'm not sure we would even run into this case.
But there's another complication that may arise here. Once we split the
plugins directory into a set of directories per plugin (instead of having
them all lumped together as now), what does 'override' mean? Do we
override the entire directory? Or merge them? Merge sounds better, but
obviously I think we'd need to see how well this would work for realz.
Perhaps a better way to think about this is, what do we want 3rd party
plugin developers to do? I continue to dream of the day when all our
existing "plugins" are structured as 3rd party plugins anyway.
--
Patrick Mueller
http://muellerware.org
Re: Plan for device specific APIs?
Posted by Drew Walters <pu...@gmail.com>.
In the short term you can look at how BlackBerry uses the 'objects' and
'merges' objects in the platform file to do complete replacement or api
level overrides.
On Mar 19, 2012 9:46 AM, "Becky Gibson" <gi...@gmail.com> wrote:
> What is the plan for the device specific APIs that have existed in the
> platform JS files? For example, iOS has a more efficient api for watching
> the compass heading, watchHeadingFilter and clearWatchFilter. iOS also
> has apis for bringing up the native contact picker to display, select or
> edit a contact. Are we still going to provide those in the device
> specific js files? Will they become "general" plugins? Perhaps an optional
> "core" plugin? I don't think we should lose this functionality and it
> should somehow be available with 1.6.
>
> -becky
>
Re: Plan for device specific APIs?
Posted by Gord Tanner <go...@tinyhippos.com>.
I would assume these would be brought in as device specific plugin's.
There is the ability to merge in behavior to the standard plugins but the
end goal should be to keep things standard.
On Mon, Mar 19, 2012 at 10:45 AM, Becky Gibson <gi...@gmail.com>wrote:
> What is the plan for the device specific APIs that have existed in the
> platform JS files? For example, iOS has a more efficient api for watching
> the compass heading, watchHeadingFilter and clearWatchFilter. iOS also
> has apis for bringing up the native contact picker to display, select or
> edit a contact. Are we still going to provide those in the device
> specific js files? Will they become "general" plugins? Perhaps an optional
> "core" plugin? I don't think we should lose this functionality and it
> should somehow be available with 1.6.
>
> -becky
>
--
Gord Tanner
Senior Developer / Code Poet
tinyHippos Inc.
@tinyhippos