Re: StatusBar plugin for Android

[Shazron]

Core plugins exist in their own repo by themselves and are cross-platform
generally. Core plugins are also released weekly.
The StatusBar plugin has none of those attributes. cordova-plugins are
really "labs" kinda stuff.

In any case, you could always fork the repo and send a pull request, we can
continue discussion there (Github) regarding its applicability/suitability.


On Mon, Feb 24, 2014 at 11:02 PM, Joe Bowser  wrote:

> It's not in its own repo, that's the main difference.  The iOS Status
> Bar and its adjustable opacity is unique to iOS.  On Android, an app
> can either be Full Screen and block the notification bar, or non-full
> screen and have the notification bar appear.  A config.xml setting
> doesn't need a special plugin.
>
> On Mon, Feb 24, 2014 at 10:39 PM, Tommy-Carlos Williams
>  wrote:
> > Calling that not core seems a stretch (since it's in an apache cordova
> repo and all), but the maintainer is Shazron, as far as I know... if that
> helps.
> >
> >
> >
> >
> > On 25 Feb 2014, at 5:29 pm, Andrey Kurdumov 
> wrote:
> >
> >> I want to extend StatusBar plugin to support Android. And yesterday I
> file
> >> issue
> >> https://issues.apache.org/jira/browse/CB-6095. It was soon closed with
> >> suggestion contact plugin maintainer, because StatusBar is not core
> plugin.
> >> Maybe I file issue incorrectly, and specify wrong component/ something
> >> else, not sure about this.
> >> But I clearly see the StatusBar plugin in
> >> https://github.com/apache/cordova-plugins repository which is clone of
> >> git://git.apache.org/cordova-plugins.git
> >> Both seems to be belonging to Cordova project.
> >>
> >> I do have fix for this issue, and willing to contribute that back.
> >> What route should I take?
> >
>

Re: StatusBar plugin for Android

[Joe Bowser]

It's not in its own repo, that's the main difference.  The iOS Status
Bar and its adjustable opacity is unique to iOS.  On Android, an app
can either be Full Screen and block the notification bar, or non-full
screen and have the notification bar appear.  A config.xml setting
doesn't need a special plugin.

On Mon, Feb 24, 2014 at 10:39 PM, Tommy-Carlos Williams
 wrote:
> Calling that not core seems a stretch (since it's in an apache cordova repo 
> and all), but the maintainer is Shazron, as far as I know... if that helps.
>
>
>
>
> On 25 Feb 2014, at 5:29 pm, Andrey Kurdumov  wrote:
>
>> I want to extend StatusBar plugin to support Android. And yesterday I file
>> issue
>> https://issues.apache.org/jira/browse/CB-6095. It was soon closed with
>> suggestion contact plugin maintainer, because StatusBar is not core plugin.
>> Maybe I file issue incorrectly, and specify wrong component/ something
>> else, not sure about this.
>> But I clearly see the StatusBar plugin in
>> https://github.com/apache/cordova-plugins repository which is clone of
>> git://git.apache.org/cordova-plugins.git
>> Both seems to be belonging to Cordova project.
>>
>> I do have fix for this issue, and willing to contribute that back.
>> What route should I take?
>

Re: StatusBar plugin for Android

[Tommy-Carlos Williams]

Calling that not core seems a stretch (since it’s in an apache cordova repo and 
all), but the maintainer is Shazron, as far as I know… if that helps.




On 25 Feb 2014, at 5:29 pm, Andrey Kurdumov  wrote:

> I want to extend StatusBar plugin to support Android. And yesterday I file
> issue
> https://issues.apache.org/jira/browse/CB-6095. It was soon closed with
> suggestion contact plugin maintainer, because StatusBar is not core plugin.
> Maybe I file issue incorrectly, and specify wrong component/ something
> else, not sure about this.
> But I clearly see the StatusBar plugin in
> https://github.com/apache/cordova-plugins repository which is clone of
> git://git.apache.org/cordova-plugins.git
> Both seems to be belonging to Cordova project.
> 
> I do have fix for this issue, and willing to contribute that back.
> What route should I take?

StatusBar plugin for Android

[Andrey Kurdumov]

I want to extend StatusBar plugin to support Android. And yesterday I file
issue
https://issues.apache.org/jira/browse/CB-6095. It was soon closed with
suggestion contact plugin maintainer, because StatusBar is not core plugin.
Maybe I file issue incorrectly, and specify wrong component/ something
else, not sure about this.
But I clearly see the StatusBar plugin in
https://github.com/apache/cordova-plugins repository which is clone of
git://git.apache.org/cordova-plugins.git
Both seems to be belonging to Cordova project.

I do have fix for this issue, and willing to contribute that back.
What route should I take?

Re: Improved integration between Apache and GitHub

[Joseph Schaefer]

Temporary condition.  Spark just graduated and we ran our graduation scripts 
but this new stuff isn't coping properly yet with the changes.

Sent from my iPhone

> On Feb 25, 2014, at 1:01 AM, Joe Bowser  wrote:
> 
> Yes.  That being said, it looks like I'm going to have to add another
> filter.  I just got notifications from infrastructure-dev from
> incubator.
> 
>> On Mon, Feb 24, 2014 at 9:17 PM, Shazron  wrote:
>> https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
>> 
>> Do we want everything on that list? I can file the issue...

Re: Improved integration between Apache and GitHub

[Joe Bowser]

Yes.  That being said, it looks like I'm going to have to add another
filter.  I just got notifications from infrastructure-dev from
incubator.

On Mon, Feb 24, 2014 at 9:17 PM, Shazron  wrote:
> https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
>
> Do we want everything on that list? I can file the issue...

Improved integration between Apache and GitHub

[Shazron]

https://blogs.apache.org/infra/entry/improved_integration_between_apache_and

Do we want everything on that list? I can file the issue...

Re: Android: recreating plugins when loading url

[Joe Bowser]

I was going to say that you wrote this, but then I remembered that Git
does that thing with files you move around where it looks like you own
the code.  Can we go back to when this was added and ask whoever wrote
this what they were trying to do? I'm just guessing at this point.

On Mon, Feb 24, 2014 at 5:32 PM, Andrew Grieve  wrote:
> If that's the intention of the code, then I think we could probably change
> it since...
>
> When you navigate via HTML (e.g. click a link or set window.location), we
> don't reset the plugin manager, instead, this triggers the onReset() method
> on all plugins.
>
> pluginManager.init() is called *only* when you navigate via Java.
>
>
> On Mon, Feb 24, 2014 at 7:19 PM, Joe Bowser  wrote:
>
>> Right, this calls pause and destroy on all the existing plugins, and
>> clears the objects until they're called again.
>>
>> So, for example.  Let's say you had the Camera plugin, which is
>> probably our nastiest plugin w.r.t memory usage, and you took a
>> picture.  Then you wish to go back to what is basically a HTML app
>> that doesn't have any need for any plugins.  It doesn't make sense for
>> that Camera plugin to keep holding onto the memory if you're
>> navigating to another URI where that plugin isn't needed.  So, we
>> destroy the plugins that were instantiated and wait for that document
>> to make a call to another plugin.
>>
>> I think this behaviour does make sense, although I'm worried that we
>> may be missing a delete/destroy somewhere.
>>
>> On Mon, Feb 24, 2014 at 4:04 PM, Naik, Archana  wrote:
>> > Oh I see.
>> >
>> > Here, by recreating I meant calling pluginManager->init() method.
>> > loadUrl(string url) in CordovaWebView calls loadUrlIntoView(final String
>> > url, boolean recreatePlugins)
>> > With second argument as true. Which does this
>> >
>> > if (recreatePlugins) {
>> >   this.url = url;
>> >   this.pluginManager.init();
>> > }
>> >
>> >
>> > I am wondering why calling init() here every time we load a new url.
>> >
>> > Thanks
>> > Archana
>> >
>> >
>> > On 2/24/14 3:57 PM, "Joe Bowser"  wrote:
>> >
>> >>On Mon, Feb 24, 2014 at 3:45 PM, Naik, Archana  wrote:
>> >>> History stack reset? I thought loading url will add to the navigation
>> >>> history.
>> >>>
>> >>
>> >>Which history are we referring to?  We have some old legacy methods
>> >>from the bad old days when we maintained our own history, because we
>> >>thought the browser history was broken (Android 3.x, 4.0.x).
>> >>
>> >>> Yes, overload helps to by pass this recreation but default call is with
>> >>> this flag set to true so internally when you use loadUrl() it will
>> >>> recreate plugins.
>> >>
>> >>We should only create plugins when we invoke them unless we're setting
>> >>plugins to be instantiated onload.  There also could be some security
>> >>reasons to destroy and recreate the plugins, although none are coming
>> >>to mind now.
>> >>
>> >>
>> >>
>> >>>
>> >>> Archana
>> >>>
>> >>> On 2/24/14 11:13 AM, "Andrew Grieve"  wrote:
>> >>>
>> I think the history stack is reset when you use that API, so it
>> somewhat
>> does make sense to recreate the plugins. Not sure if there is a better
>> answer than that...
>> 
>> I added the overload to allow not resetting the plugins, because I
>> think
>> that is a useful thing to want to do as well.
>> 
>> 
>> On Fri, Feb 21, 2014 at 5:24 PM, Naik, Archana 
>> wrote:
>> 
>> > Hi, Devs,
>> >
>> > Why do we recreate plugin every time an url is loaded? I am referring
>> >to
>> > loadUrlIntoView(url,bool) method.
>> > Other override which take only string(url), has this recreatePlugins
>> > boolean as true.
>> >
>> > Thanks
>> > Archana
>> >
>> >>>
>> >
>>

Re: MessageQueue seems to stop sending messages to the webView

[James Rivett-Carnac]

Sorry, the only way I can get it to reproduce is by booting up while
attached to something that wants to launch the app as a USB accessory. (OK,
that is a convoluted sentence).

I can force it to respond by sending calling cordova.exec every 100
milliseconds in my Web app. Every time I call it it seems to go through the
message queue. I haven't tried stopping sending and seeing if it works. I
would assume not as none of my other calls to the java side made the
message work.
On 25 Feb 2014 03:23, "Andrew Grieve"  wrote:

> Don - would be great! Seems like a pretty bad bug, so I'd love to squash
> it!
>
>
> On Mon, Feb 24, 2014 at 2:19 PM, Don Coleman wrote:
>
>> Andrew,
>>
>> I'm seeing similar behavior for a plugin I'm working on. I might be able
>> to get you a sample if James doesn't have one.
>>
>> - Don
>>
>>
>> On Mon, Feb 24, 2014 at 2:14 PM, Andrew Grieve wrote:
>>
>>> On Mon, Feb 24, 2014 at 2:14 PM, Andrew Grieve 
>>> wrote:
>>>
>>> > James - have so far been unable to come up with a repro case for this.
>>> If
>>> > there's a chance you could create one, that would be really helpful.
>>> >
>>> >
>>> > On Tue, Feb 18, 2014 at 2:16 PM, Andrew Grieve >> >wrote:
>>> >
>>> >> Hmm, might be same problem as
>>> >> https://issues.apache.org/jira/browse/CB-6047. Let's move this
>>> >> conversation to that bug.
>>> >>
>>> >>
>>> >> On Tue, Feb 18, 2014 at 2:10 AM, James Rivett-Carnac <
>>> >> james.rivett.car...@gmail.com> wrote:
>>> >>
>>> >>> Hello,
>>> >>>
>>> >>> I'm uisng an embedded cordova webview and am seeing something where
>>> by
>>> >>> the
>>> >>> webview doesn't receive messages sent to it from my plugin.
>>> >>>
>>> >>> I've seen this with:
>>> >>>
>>> >>> android 4.3, 4.4.2, (Moto G, Nexus 7 2012)
>>> >>> cordova 3.3.0-rc1, 3.3.0-0.1.1, 3.3.1-0.4.2
>>> >>>
>>> >>> The application is receiveing informatiion from a USB device (the
>>> >>> phone/tablet runs in accessory mode), reading this information in
>>> its own
>>> >>> thread.  These call callbacks, and change the state in the webview
>>> >>> (lavaca
>>> >>> app).
>>> >>>
>>> >>> Generally this works without issues.  Sometimes, the screen doesn't
>>> >>> update.  If I profile the threads running, the webview is not
>>> showing any
>>> >>> activity (except maybe a call to uptime).  If I unplug and plug back
>>> in
>>> >>> the
>>> >>> USB, the screen goes through all the pending updates (quickly flashes
>>> >>> through them).  The app does *not* return to normal opperations at
>>> this
>>> >>> point: I have to unplug/plug back in for every message that is sent.
>>>  If
>>> >>> I
>>> >>> do this while monitoring the threads, I see calls to the android
>>> message
>>> >>> handler happening at this point.
>>> >>>
>>> >>> When it is working correctly, these calls happen when the event is
>>> >>> triggered.
>>> >>>
>>> >>> My questions - what could be causing this?  Is there a way to force
>>> the
>>> >>> message queue to trigger, other than unpluggin/pluggin back in?
>>> >>>
>>> >>> James
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>
>>
>

Re: Android: recreating plugins when loading url

[Andrew Grieve]

If that's the intention of the code, then I think we could probably change
it since...

When you navigate via HTML (e.g. click a link or set window.location), we
don't reset the plugin manager, instead, this triggers the onReset() method
on all plugins.

pluginManager.init() is called *only* when you navigate via Java.


On Mon, Feb 24, 2014 at 7:19 PM, Joe Bowser  wrote:

> Right, this calls pause and destroy on all the existing plugins, and
> clears the objects until they're called again.
>
> So, for example.  Let's say you had the Camera plugin, which is
> probably our nastiest plugin w.r.t memory usage, and you took a
> picture.  Then you wish to go back to what is basically a HTML app
> that doesn't have any need for any plugins.  It doesn't make sense for
> that Camera plugin to keep holding onto the memory if you're
> navigating to another URI where that plugin isn't needed.  So, we
> destroy the plugins that were instantiated and wait for that document
> to make a call to another plugin.
>
> I think this behaviour does make sense, although I'm worried that we
> may be missing a delete/destroy somewhere.
>
> On Mon, Feb 24, 2014 at 4:04 PM, Naik, Archana  wrote:
> > Oh I see.
> >
> > Here, by recreating I meant calling pluginManager->init() method.
> > loadUrl(string url) in CordovaWebView calls loadUrlIntoView(final String
> > url, boolean recreatePlugins)
> > With second argument as true. Which does this
> >
> > if (recreatePlugins) {
> >   this.url = url;
> >   this.pluginManager.init();
> > }
> >
> >
> > I am wondering why calling init() here every time we load a new url.
> >
> > Thanks
> > Archana
> >
> >
> > On 2/24/14 3:57 PM, "Joe Bowser"  wrote:
> >
> >>On Mon, Feb 24, 2014 at 3:45 PM, Naik, Archana  wrote:
> >>> History stack reset? I thought loading url will add to the navigation
> >>> history.
> >>>
> >>
> >>Which history are we referring to?  We have some old legacy methods
> >>from the bad old days when we maintained our own history, because we
> >>thought the browser history was broken (Android 3.x, 4.0.x).
> >>
> >>> Yes, overload helps to by pass this recreation but default call is with
> >>> this flag set to true so internally when you use loadUrl() it will
> >>> recreate plugins.
> >>
> >>We should only create plugins when we invoke them unless we're setting
> >>plugins to be instantiated onload.  There also could be some security
> >>reasons to destroy and recreate the plugins, although none are coming
> >>to mind now.
> >>
> >>
> >>
> >>>
> >>> Archana
> >>>
> >>> On 2/24/14 11:13 AM, "Andrew Grieve"  wrote:
> >>>
> I think the history stack is reset when you use that API, so it
> somewhat
> does make sense to recreate the plugins. Not sure if there is a better
> answer than that...
> 
> I added the overload to allow not resetting the plugins, because I
> think
> that is a useful thing to want to do as well.
> 
> 
> On Fri, Feb 21, 2014 at 5:24 PM, Naik, Archana 
> wrote:
> 
> > Hi, Devs,
> >
> > Why do we recreate plugin every time an url is loaded? I am referring
> >to
> > loadUrlIntoView(url,bool) method.
> > Other override which take only string(url), has this recreatePlugins
> > boolean as true.
> >
> > Thanks
> > Archana
> >
> >>>
> >
>

Re: bad https calls

[Shazron]

https://issues.apache.org/jira/browse/CB-4561
https://issues.apache.org/jira/browse/CB-5851


On Mon, Feb 24, 2014 at 5:00 PM, Brian LeRoux  wrote:

> looks like a bad deploy OR we need to use /// instead of hardcoding
> protocol (not in a position to check this atm)
>
> http://cordova.apache.org === all good
> https://cordova.apache.org === yikes
>

Re: 3.4 release documentation website -- no translations

[Steven Gill]

I have uploaded 3.4.0 docs for all of the languages except SL. SL doesn't
want to bin/generate on my machine.


On Fri, Feb 21, 2014 at 2:30 PM, Steven Gill  wrote:

> Hey Lisa,
>
> I can look into this. I haven't actually done a version release for
> translations before. Should I update all of the languages?
>
> The list of supported languages:
> * de
> * es
> * fr
> * it
> * ja
> * ko
> * ru
> * sl
> * zh
>
> If you (or anyone else) are interested in learning how to create new
> versions and update the website for docs, I will list the steps below.
>
> First off, make sure you follow the readme in cordova/docs and install the
> dependencies.
>
> ## Generating new version
> The command to create new versions is
>
> rake version[version, language]
>
> so rake version[3.4.0, de]
>
> A new version should be created under cordova-docs/docs/language/version.
>
> ## rendering public docs
> Now run ./bin/generate. This will render all of the docs in
> cordova-docs/docs to cordova-docs/public. This takes quite a while. Old
> versions need to get regenerated when we add new versions because the menu
> for old versions need to show the latest version available.
>
> ## add docs to cordova-site
> copy the rendered docs from `cordova-docs` to `cordova-website` by using
> the following command:
>
> rsync -av --exclude='.svn*' public/ ../cordova-website/public/docs
> svn add public/docs/my_lang/my_new_version
> svn commit -m "Added docs version XXX for language YYY"
>
> That should do it!
>
>
>
>
>
>
> On Fri, Feb 21, 2014 at 6:51 AM, Lisa Seacat DeLuca wrote:
>
>> Even though the English documentation appears to be updated, the other
>> languages haven't been updated on our site since the 3.1 release.
>> http://cordova.apache.org/docs/en/edge/index.html
>>
>>
>>
>> I know the documentation files have changed for the plugins and the
>> individual plugins themselves haven't been translated yet for 3.4 but the
>> core information (from cordova-docs) has been translated.  We're going to
>> have a lot of angry translators if their hard work doesn't get pulled into
>> the main website.  The files have been pushed to the master apache cordova
>> repo for docs.  Does someone mind helping me get this live?
>>
>> Thanks and Happy Friday!!
>>
>>
>> Lisa
>>
>> Lisa Seacat DeLuca
>> Mobile Engineer | t: +415.787.4589 | 
>> *ldel...@apache.org*| |
>> *ldel...@us.ibm.com*  | 
>> *lisaseacat.com*| [image:
>> follow @LisaSeacat on twitter] | [image:
>> follow Lisa Seacat DeLuca on linkedin]
>>
>>
>>
>

bad https calls

[Brian LeRoux]

looks like a bad deploy OR we need to use /// instead of hardcoding
protocol (not in a position to check this atm)

http://cordova.apache.org === all good
https://cordova.apache.org === yikes

Re: Android: recreating plugins when loading url

[Joe Bowser]

Right, this calls pause and destroy on all the existing plugins, and
clears the objects until they're called again.

So, for example.  Let's say you had the Camera plugin, which is
probably our nastiest plugin w.r.t memory usage, and you took a
picture.  Then you wish to go back to what is basically a HTML app
that doesn't have any need for any plugins.  It doesn't make sense for
that Camera plugin to keep holding onto the memory if you're
navigating to another URI where that plugin isn't needed.  So, we
destroy the plugins that were instantiated and wait for that document
to make a call to another plugin.

I think this behaviour does make sense, although I'm worried that we
may be missing a delete/destroy somewhere.

On Mon, Feb 24, 2014 at 4:04 PM, Naik, Archana  wrote:
> Oh I see.
>
> Here, by recreating I meant calling pluginManager->init() method.
> loadUrl(string url) in CordovaWebView calls loadUrlIntoView(final String
> url, boolean recreatePlugins)
> With second argument as true. Which does this
>
> if (recreatePlugins) {
>   this.url = url;
>   this.pluginManager.init();
> }
>
>
> I am wondering why calling init() here every time we load a new url.
>
> Thanks
> Archana
>
>
> On 2/24/14 3:57 PM, "Joe Bowser"  wrote:
>
>>On Mon, Feb 24, 2014 at 3:45 PM, Naik, Archana  wrote:
>>> History stack reset? I thought loading url will add to the navigation
>>> history.
>>>
>>
>>Which history are we referring to?  We have some old legacy methods
>>from the bad old days when we maintained our own history, because we
>>thought the browser history was broken (Android 3.x, 4.0.x).
>>
>>> Yes, overload helps to by pass this recreation but default call is with
>>> this flag set to true so internally when you use loadUrl() it will
>>> recreate plugins.
>>
>>We should only create plugins when we invoke them unless we're setting
>>plugins to be instantiated onload.  There also could be some security
>>reasons to destroy and recreate the plugins, although none are coming
>>to mind now.
>>
>>
>>
>>>
>>> Archana
>>>
>>> On 2/24/14 11:13 AM, "Andrew Grieve"  wrote:
>>>
I think the history stack is reset when you use that API, so it somewhat
does make sense to recreate the plugins. Not sure if there is a better
answer than that...

I added the overload to allow not resetting the plugins, because I think
that is a useful thing to want to do as well.


On Fri, Feb 21, 2014 at 5:24 PM, Naik, Archana  wrote:

> Hi, Devs,
>
> Why do we recreate plugin every time an url is loaded? I am referring
>to
> loadUrlIntoView(url,bool) method.
> Other override which take only string(url), has this recreatePlugins
> boolean as true.
>
> Thanks
> Archana
>
>>>
>

Re: Android: recreating plugins when loading url

[Naik, Archana]

Oh I see. 

Here, by recreating I meant calling pluginManager->init() method.
loadUrl(string url) in CordovaWebView calls loadUrlIntoView(final String
url, boolean recreatePlugins)
With second argument as true. Which does this

if (recreatePlugins) {
  this.url = url;
  this.pluginManager.init();
}


I am wondering why calling init() here every time we load a new url.

Thanks
Archana


On 2/24/14 3:57 PM, "Joe Bowser"  wrote:

>On Mon, Feb 24, 2014 at 3:45 PM, Naik, Archana  wrote:
>> History stack reset? I thought loading url will add to the navigation
>> history.
>>
>
>Which history are we referring to?  We have some old legacy methods
>from the bad old days when we maintained our own history, because we
>thought the browser history was broken (Android 3.x, 4.0.x).
>
>> Yes, overload helps to by pass this recreation but default call is with
>> this flag set to true so internally when you use loadUrl() it will
>> recreate plugins.
>
>We should only create plugins when we invoke them unless we're setting
>plugins to be instantiated onload.  There also could be some security
>reasons to destroy and recreate the plugins, although none are coming
>to mind now.
>
>
>
>>
>> Archana
>>
>> On 2/24/14 11:13 AM, "Andrew Grieve"  wrote:
>>
>>>I think the history stack is reset when you use that API, so it somewhat
>>>does make sense to recreate the plugins. Not sure if there is a better
>>>answer than that...
>>>
>>>I added the overload to allow not resetting the plugins, because I think
>>>that is a useful thing to want to do as well.
>>>
>>>
>>>On Fri, Feb 21, 2014 at 5:24 PM, Naik, Archana  wrote:
>>>
 Hi, Devs,

 Why do we recreate plugin every time an url is loaded? I am referring
to
 loadUrlIntoView(url,bool) method.
 Other override which take only string(url), has this recreatePlugins
 boolean as true.

 Thanks
 Archana

>>

Re: Android: recreating plugins when loading url

[Joe Bowser]

On Mon, Feb 24, 2014 at 3:45 PM, Naik, Archana  wrote:
> History stack reset? I thought loading url will add to the navigation
> history.
>

Which history are we referring to?  We have some old legacy methods
from the bad old days when we maintained our own history, because we
thought the browser history was broken (Android 3.x, 4.0.x).

> Yes, overload helps to by pass this recreation but default call is with
> this flag set to true so internally when you use loadUrl() it will
> recreate plugins.

We should only create plugins when we invoke them unless we're setting
plugins to be instantiated onload.  There also could be some security
reasons to destroy and recreate the plugins, although none are coming
to mind now.



>
> Archana
>
> On 2/24/14 11:13 AM, "Andrew Grieve"  wrote:
>
>>I think the history stack is reset when you use that API, so it somewhat
>>does make sense to recreate the plugins. Not sure if there is a better
>>answer than that...
>>
>>I added the overload to allow not resetting the plugins, because I think
>>that is a useful thing to want to do as well.
>>
>>
>>On Fri, Feb 21, 2014 at 5:24 PM, Naik, Archana  wrote:
>>
>>> Hi, Devs,
>>>
>>> Why do we recreate plugin every time an url is loaded? I am referring to
>>> loadUrlIntoView(url,bool) method.
>>> Other override which take only string(url), has this recreatePlugins
>>> boolean as true.
>>>
>>> Thanks
>>> Archana
>>>
>

Re: Android: recreating plugins when loading url

[Naik, Archana]

History stack reset? I thought loading url will add to the navigation
history.

Yes, overload helps to by pass this recreation but default call is with
this flag set to true so internally when you use loadUrl() it will
recreate plugins.

Archana

On 2/24/14 11:13 AM, "Andrew Grieve"  wrote:

>I think the history stack is reset when you use that API, so it somewhat
>does make sense to recreate the plugins. Not sure if there is a better
>answer than that...
>
>I added the overload to allow not resetting the plugins, because I think
>that is a useful thing to want to do as well.
>
>
>On Fri, Feb 21, 2014 at 5:24 PM, Naik, Archana  wrote:
>
>> Hi, Devs,
>>
>> Why do we recreate plugin every time an url is loaded? I am referring to
>> loadUrlIntoView(url,bool) method.
>> Other override which take only string(url), has this recreatePlugins
>> boolean as true.
>>
>> Thanks
>> Archana
>>

Re: Tools & Plugins release

[Naik, Archana]

Has mobile spec been updated to test these new file/file-transfer changes?

On 2/24/14 10:54 AM, "Ian Clelland"  wrote:

>I approve of this -- there have been a number of fixes in file and
>file-transfer for issues filed by the developer community.
>
>
>
>On Mon, Feb 24, 2014 at 1:42 PM, Andrew Grieve 
>wrote:
>
>> I'd like to do a release Wednesday. Just wanted to send the heads up,
>>and
>> see if there's any reason to delay / if there are things people are
>>trying
>> to get in.
>>

Re: [Input request] Rethinking Plugin docs

[Lisa Seacat DeLuca]

README.md merge +1

I understand the idea behind keeping the documentation outside of the 
README.md but given that the "how to contribute" and other info is 
generally the same across all of the plugins and is available on the wiki, 
etc. it's probably redundant to put it in each repo as well.  That being 
said it probably wouldn't hurt to have a link on the top of the 
README.md's pointing back to the main cordova project info.


Lisa Seacat DeLuca
Mobile Engineer | t: +415.787.4589 | ldel...@apache.org | | 
ldel...@us.ibm.com | lisaseacat.com | | 





From:   Steven Gill 
To: "dev@cordova.apache.org" 
Cc: Lisa Seacat DeLuca/San Francisco/IBM@IBMUS, Michael Brooks 

Date:   02/24/2014 03:08 PM
Subject:Re: [Input request] Rethinking Plugin docs



I personally think we should merge the two into README.md. Our readme 
files
in the plugins are useless right now. Might as well combine some of the
info that should be in the readme + index.md so we have all of the
important information shown prominently.


On Mon, Feb 24, 2014 at 11:53 AM, Andrew Grieve 
wrote:

> +Michael
>
> Might be helpful to write out expanded README.md files for our plugins.
> Right now, they just contain a title and a link to the docs:
> https://github.com/apache/cordova-plugin-file
>
> "What it is" is covered by the first paragraph of the docs already I 
think.
> "How to contribute" is pretty obvious for most github-hosted projects, 
but
> I don't think that would hurt as part of the documentation either.
>
>
> On Mon, Feb 24, 2014 at 2:37 PM, Brian LeRoux  wrote:
>
> > I think Mike's main consideration is that the README.md is a place for
> > general project info (what it is, how to contribute, etc) whereas
> > documentation, inc translations, should be in a dedicated space as
> standard
> > convention so we can tool it. (Something like this: 
`doc/[lang]/index.md
> > `.)
> >
> >
> > On Mon, Feb 24, 2014 at 11:26 AM, Andrew Grieve 
> > wrote:
> >
> > > That was basically the question in my head as I was typing... I'd be
> > happy
> > > with having just a README.md, and allowing it to link to relative 
.md
> > paths
> > > if it wanted to.
> > >
> > >
> > > On Mon, Feb 24, 2014 at 2:21 PM, Lisa Seacat DeLuca <
> ldel...@us.ibm.com
> > >wrote:
> > >
> > >> If README.md is the standard why not just call all of them README 
and
> > not
> > >> have an index.md file at all for the plugins.  What is the 
advantage
> of
> > >> having both?  Seems more confusing than anything.
> > >>
> > >> Lisa Seacat DeLuca
> > >> Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org*<
> > ldel...@apache.org>| |
> > >> *ldel...@us.ibm.com*  | *lisaseacat.com*<
> > http://www.lisaseacat.com/>| [image:
> > >> follow @LisaSeacat on twitter] |
> > [image:
> > >> follow Lisa Seacat DeLuca on linkedin]<
> > http://www.linkedin.com/in/lisaseacat>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> From:Andrew Grieve 
> > >> To:dev 
> > >> Date:02/24/2014 01:41 PM
> > >> Subject:Re: [Input request] Rethinking Plugin docs
> > >> Sent by:agri...@google.com
> > >> --
> > >>
> > >>
> > >>
> > >> On Mon, Feb 24, 2014 at 12:51 PM, Marcel Kinard 

> > >> wrote:
> > >>
> > >> >
> > >> > On Feb 24, 2014, at 12:32 PM, Andrew Grieve 

> > >> wrote:
> > >> >
> > >> > > - We may also want to include README.md files in the 
translations.
> > >> > > doc/fr/index.md
> > >> > > doc/fr/README.md
> > >> >
> > >> > What content do you forsee being in README.md other than a
> > >> > table-of-contents to the languages? Or in other words, would it 
be
> > >> > public-facing content that could be collapsed in to the rest of 
the
> > >> plugin
> > >> > docs?
> > >> >
> > >>
> > >> On npmjs.org and on github, README.md's are the files that are 
shown
> > most
> > >> prominently. So, I speculate that many plugins will not provide a 
doc/
> > >> index.md, and instead provide only a README.md.
> > >>
> > >>
> > >> >
> > >> > > - We don't need the version in the directory since we can use 
git
> > >> tags to
> > >> > > find old versions
> > >> >
> > >> > That makes sense.
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
>

Re: File Permissions

[Joe Bowser]

Hi

This list is to discuss the development of Cordova, not to ask for
assistance in how to develop for Cordova.  Please ask these questions
on the PhoneGap Google Group:
https://groups.google.com/forum/#!forum/phonegap

On Mon, Feb 24, 2014 at 12:16 PM, Jorge Torres
 wrote:
> Maybe have the file name start with .
>
> On Monday, February 24, 2014, Murty Navuduri 
> wrote:
>
>> Hi,
>>  I have been using Cordova in my Mobile development.
>>  I need to Hide my Files on the Device or I do not want to allow User to
>> delete the App files from the device.
>>  I checked the documentation and could not find any supporting API for the
>> above functionality.
>>
>>  Could you please provide me the Possibility factor on the above.
>>
>> Thanks and Regards,
>> Murty.
>>

Re: File Permissions

[Jorge Torres]

Maybe have the file name start with .

On Monday, February 24, 2014, Murty Navuduri 
wrote:

> Hi,
>  I have been using Cordova in my Mobile development.
>  I need to Hide my Files on the Device or I do not want to allow User to
> delete the App files from the device.
>  I checked the documentation and could not find any supporting API for the
> above functionality.
>
>  Could you please provide me the Possibility factor on the above.
>
> Thanks and Regards,
> Murty.
>

Re: [Input request] Rethinking Plugin docs

[Steven Gill]

I personally think we should merge the two into README.md. Our readme files
in the plugins are useless right now. Might as well combine some of the
info that should be in the readme + index.md so we have all of the
important information shown prominently.


On Mon, Feb 24, 2014 at 11:53 AM, Andrew Grieve wrote:

> +Michael
>
> Might be helpful to write out expanded README.md files for our plugins.
> Right now, they just contain a title and a link to the docs:
> https://github.com/apache/cordova-plugin-file
>
> "What it is" is covered by the first paragraph of the docs already I think.
> "How to contribute" is pretty obvious for most github-hosted projects, but
> I don't think that would hurt as part of the documentation either.
>
>
> On Mon, Feb 24, 2014 at 2:37 PM, Brian LeRoux  wrote:
>
> > I think Mike's main consideration is that the README.md is a place for
> > general project info (what it is, how to contribute, etc) whereas
> > documentation, inc translations, should be in a dedicated space as
> standard
> > convention so we can tool it. (Something like this: `doc/[lang]/index.md
> > `.)
> >
> >
> > On Mon, Feb 24, 2014 at 11:26 AM, Andrew Grieve 
> > wrote:
> >
> > > That was basically the question in my head as I was typing... I'd be
> > happy
> > > with having just a README.md, and allowing it to link to relative .md
> > paths
> > > if it wanted to.
> > >
> > >
> > > On Mon, Feb 24, 2014 at 2:21 PM, Lisa Seacat DeLuca <
> ldel...@us.ibm.com
> > >wrote:
> > >
> > >> If README.md is the standard why not just call all of them README and
> > not
> > >> have an index.md file at all for the plugins.  What is the advantage
> of
> > >> having both?  Seems more confusing than anything.
> > >>
> > >> Lisa Seacat DeLuca
> > >> Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org*<
> > ldel...@apache.org>| |
> > >> *ldel...@us.ibm.com*  | *lisaseacat.com*<
> > http://www.lisaseacat.com/>| [image:
> > >> follow @LisaSeacat on twitter] |
> > [image:
> > >> follow Lisa Seacat DeLuca on linkedin]<
> > http://www.linkedin.com/in/lisaseacat>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> From:Andrew Grieve 
> > >> To:dev 
> > >> Date:02/24/2014 01:41 PM
> > >> Subject:Re: [Input request] Rethinking Plugin docs
> > >> Sent by:agri...@google.com
> > >> --
> > >>
> > >>
> > >>
> > >> On Mon, Feb 24, 2014 at 12:51 PM, Marcel Kinard 
> > >> wrote:
> > >>
> > >> >
> > >> > On Feb 24, 2014, at 12:32 PM, Andrew Grieve 
> > >> wrote:
> > >> >
> > >> > > - We may also want to include README.md files in the translations.
> > >> > > doc/fr/index.md
> > >> > > doc/fr/README.md
> > >> >
> > >> > What content do you forsee being in README.md other than a
> > >> > table-of-contents to the languages? Or in other words, would it be
> > >> > public-facing content that could be collapsed in to the rest of the
> > >> plugin
> > >> > docs?
> > >> >
> > >>
> > >> On npmjs.org and on github, README.md's are the files that are shown
> > most
> > >> prominently. So, I speculate that many plugins will not provide a doc/
> > >> index.md, and instead provide only a README.md.
> > >>
> > >>
> > >> >
> > >> > > - We don't need the version in the directory since we can use git
> > >> tags to
> > >> > > find old versions
> > >> >
> > >> > That makes sense.
> > >> >
> > >> >
> > >>
> > >>
> > >
> >
>

Re: [Input request] Rethinking Plugin docs

[Andrew Grieve]

+Michael

Might be helpful to write out expanded README.md files for our plugins.
Right now, they just contain a title and a link to the docs:
https://github.com/apache/cordova-plugin-file

"What it is" is covered by the first paragraph of the docs already I think.
"How to contribute" is pretty obvious for most github-hosted projects, but
I don't think that would hurt as part of the documentation either.


On Mon, Feb 24, 2014 at 2:37 PM, Brian LeRoux  wrote:

> I think Mike's main consideration is that the README.md is a place for
> general project info (what it is, how to contribute, etc) whereas
> documentation, inc translations, should be in a dedicated space as standard
> convention so we can tool it. (Something like this: `doc/[lang]/index.md
> `.)
>
>
> On Mon, Feb 24, 2014 at 11:26 AM, Andrew Grieve 
> wrote:
>
> > That was basically the question in my head as I was typing... I'd be
> happy
> > with having just a README.md, and allowing it to link to relative .md
> paths
> > if it wanted to.
> >
> >
> > On Mon, Feb 24, 2014 at 2:21 PM, Lisa Seacat DeLuca  >wrote:
> >
> >> If README.md is the standard why not just call all of them README and
> not
> >> have an index.md file at all for the plugins.  What is the advantage of
> >> having both?  Seems more confusing than anything.
> >>
> >> Lisa Seacat DeLuca
> >> Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org*<
> ldel...@apache.org>| |
> >> *ldel...@us.ibm.com*  | *lisaseacat.com*<
> http://www.lisaseacat.com/>| [image:
> >> follow @LisaSeacat on twitter] |
> [image:
> >> follow Lisa Seacat DeLuca on linkedin]<
> http://www.linkedin.com/in/lisaseacat>
> >>
> >>
> >>
> >>
> >>
> >> From:Andrew Grieve 
> >> To:dev 
> >> Date:02/24/2014 01:41 PM
> >> Subject:Re: [Input request] Rethinking Plugin docs
> >> Sent by:agri...@google.com
> >> --
> >>
> >>
> >>
> >> On Mon, Feb 24, 2014 at 12:51 PM, Marcel Kinard 
> >> wrote:
> >>
> >> >
> >> > On Feb 24, 2014, at 12:32 PM, Andrew Grieve 
> >> wrote:
> >> >
> >> > > - We may also want to include README.md files in the translations.
> >> > > doc/fr/index.md
> >> > > doc/fr/README.md
> >> >
> >> > What content do you forsee being in README.md other than a
> >> > table-of-contents to the languages? Or in other words, would it be
> >> > public-facing content that could be collapsed in to the rest of the
> >> plugin
> >> > docs?
> >> >
> >>
> >> On npmjs.org and on github, README.md's are the files that are shown
> most
> >> prominently. So, I speculate that many plugins will not provide a doc/
> >> index.md, and instead provide only a README.md.
> >>
> >>
> >> >
> >> > > - We don't need the version in the directory since we can use git
> >> tags to
> >> > > find old versions
> >> >
> >> > That makes sense.
> >> >
> >> >
> >>
> >>
> >
>

File Permissions

[Murty Navuduri]

Hi,
 I have been using Cordova in my Mobile development.
 I need to Hide my Files on the Device or I do not want to allow User to
delete the App files from the device.
 I checked the documentation and could not find any supporting API for the
above functionality.

 Could you please provide me the Possibility factor on the above.

Thanks and Regards,
Murty.

Re: [Input request] Rethinking Plugin docs

[Brian LeRoux]

I think Mike's main consideration is that the README.md is a place for
general project info (what it is, how to contribute, etc) whereas
documentation, inc translations, should be in a dedicated space as standard
convention so we can tool it. (Something like this: `doc/[lang]/index.md`.)


On Mon, Feb 24, 2014 at 11:26 AM, Andrew Grieve  wrote:

> That was basically the question in my head as I was typing... I'd be happy
> with having just a README.md, and allowing it to link to relative .md paths
> if it wanted to.
>
>
> On Mon, Feb 24, 2014 at 2:21 PM, Lisa Seacat DeLuca wrote:
>
>> If README.md is the standard why not just call all of them README and not
>> have an index.md file at all for the plugins.  What is the advantage of
>> having both?  Seems more confusing than anything.
>>
>> Lisa Seacat DeLuca
>> Mobile Engineer | t: +415.787.4589 | 
>> *ldel...@apache.org*| |
>> *ldel...@us.ibm.com*  | 
>> *lisaseacat.com*| [image:
>> follow @LisaSeacat on twitter] | [image:
>> follow Lisa Seacat DeLuca on linkedin]
>>
>>
>>
>>
>>
>> From:Andrew Grieve 
>> To:dev 
>> Date:02/24/2014 01:41 PM
>> Subject:Re: [Input request] Rethinking Plugin docs
>> Sent by:agri...@google.com
>> --
>>
>>
>>
>> On Mon, Feb 24, 2014 at 12:51 PM, Marcel Kinard 
>> wrote:
>>
>> >
>> > On Feb 24, 2014, at 12:32 PM, Andrew Grieve 
>> wrote:
>> >
>> > > - We may also want to include README.md files in the translations.
>> > > doc/fr/index.md
>> > > doc/fr/README.md
>> >
>> > What content do you forsee being in README.md other than a
>> > table-of-contents to the languages? Or in other words, would it be
>> > public-facing content that could be collapsed in to the rest of the
>> plugin
>> > docs?
>> >
>>
>> On npmjs.org and on github, README.md's are the files that are shown most
>> prominently. So, I speculate that many plugins will not provide a doc/
>> index.md, and instead provide only a README.md.
>>
>>
>> >
>> > > - We don't need the version in the directory since we can use git
>> tags to
>> > > find old versions
>> >
>> > That makes sense.
>> >
>> >
>>
>>
>

Re: [Input request] Rethinking Plugin docs

[Brian LeRoux]

I think Mike Brooks has extensive thinking wrt to this. Wait for his reply!


On Mon, Feb 24, 2014 at 11:21 AM, Lisa Seacat DeLuca wrote:

> If README.md is the standard why not just call all of them README and not
> have an index.md file at all for the plugins.  What is the advantage of
> having both?  Seems more confusing than anything.
>
> Lisa Seacat DeLuca
> Mobile Engineer | t: +415.787.4589 | 
> *ldel...@apache.org*| |
> *ldel...@us.ibm.com*  | 
> *lisaseacat.com*| [image:
> follow @LisaSeacat on twitter] | [image:
> follow Lisa Seacat DeLuca on linkedin]
>
>
>
>
>
> From:Andrew Grieve 
> To:dev 
> Date:02/24/2014 01:41 PM
> Subject:Re: [Input request] Rethinking Plugin docs
> Sent by:agri...@google.com
> --
>
>
>
> On Mon, Feb 24, 2014 at 12:51 PM, Marcel Kinard 
> wrote:
>
> >
> > On Feb 24, 2014, at 12:32 PM, Andrew Grieve 
> wrote:
> >
> > > - We may also want to include README.md files in the translations.
> > > doc/fr/index.md
> > > doc/fr/README.md
> >
> > What content do you forsee being in README.md other than a
> > table-of-contents to the languages? Or in other words, would it be
> > public-facing content that could be collapsed in to the rest of the
> plugin
> > docs?
> >
>
> On npmjs.org and on github, README.md's are the files that are shown most
> prominently. So, I speculate that many plugins will not provide a doc/
> index.md, and instead provide only a README.md.
>
>
> >
> > > - We don't need the version in the directory since we can use git tags
> to
> > > find old versions
> >
> > That makes sense.
> >
> >
>
>

Re: [Input request] Rethinking Plugin docs

[Andrew Grieve]

That was basically the question in my head as I was typing... I'd be happy
with having just a README.md, and allowing it to link to relative .md paths
if it wanted to.


On Mon, Feb 24, 2014 at 2:21 PM, Lisa Seacat DeLuca wrote:

> If README.md is the standard why not just call all of them README and not
> have an index.md file at all for the plugins.  What is the advantage of
> having both?  Seems more confusing than anything.
>
> Lisa Seacat DeLuca
> Mobile Engineer | t: +415.787.4589 | 
> *ldel...@apache.org*| |
> *ldel...@us.ibm.com*  | 
> *lisaseacat.com*| [image:
> follow @LisaSeacat on twitter] | [image:
> follow Lisa Seacat DeLuca on linkedin]
>
>
>
>
>
> From:Andrew Grieve 
> To:dev 
> Date:02/24/2014 01:41 PM
> Subject:Re: [Input request] Rethinking Plugin docs
> Sent by:agri...@google.com
> --
>
>
>
> On Mon, Feb 24, 2014 at 12:51 PM, Marcel Kinard 
> wrote:
>
> >
> > On Feb 24, 2014, at 12:32 PM, Andrew Grieve 
> wrote:
> >
> > > - We may also want to include README.md files in the translations.
> > > doc/fr/index.md
> > > doc/fr/README.md
> >
> > What content do you forsee being in README.md other than a
> > table-of-contents to the languages? Or in other words, would it be
> > public-facing content that could be collapsed in to the rest of the
> plugin
> > docs?
> >
>
> On npmjs.org and on github, README.md's are the files that are shown most
> prominently. So, I speculate that many plugins will not provide a doc/
> index.md, and instead provide only a README.md.
>
>
> >
> > > - We don't need the version in the directory since we can use git tags
> to
> > > find old versions
> >
> > That makes sense.
> >
> >
>
>

Re: MessageQueue seems to stop sending messages to the webView

[Andrew Grieve]

Don - would be great! Seems like a pretty bad bug, so I'd love to squash it!


On Mon, Feb 24, 2014 at 2:19 PM, Don Coleman  wrote:

> Andrew,
>
> I'm seeing similar behavior for a plugin I'm working on. I might be able
> to get you a sample if James doesn't have one.
>
> - Don
>
>
> On Mon, Feb 24, 2014 at 2:14 PM, Andrew Grieve wrote:
>
>> On Mon, Feb 24, 2014 at 2:14 PM, Andrew Grieve 
>> wrote:
>>
>> > James - have so far been unable to come up with a repro case for this.
>> If
>> > there's a chance you could create one, that would be really helpful.
>> >
>> >
>> > On Tue, Feb 18, 2014 at 2:16 PM, Andrew Grieve > >wrote:
>> >
>> >> Hmm, might be same problem as
>> >> https://issues.apache.org/jira/browse/CB-6047. Let's move this
>> >> conversation to that bug.
>> >>
>> >>
>> >> On Tue, Feb 18, 2014 at 2:10 AM, James Rivett-Carnac <
>> >> james.rivett.car...@gmail.com> wrote:
>> >>
>> >>> Hello,
>> >>>
>> >>> I'm uisng an embedded cordova webview and am seeing something where by
>> >>> the
>> >>> webview doesn't receive messages sent to it from my plugin.
>> >>>
>> >>> I've seen this with:
>> >>>
>> >>> android 4.3, 4.4.2, (Moto G, Nexus 7 2012)
>> >>> cordova 3.3.0-rc1, 3.3.0-0.1.1, 3.3.1-0.4.2
>> >>>
>> >>> The application is receiveing informatiion from a USB device (the
>> >>> phone/tablet runs in accessory mode), reading this information in its
>> own
>> >>> thread.  These call callbacks, and change the state in the webview
>> >>> (lavaca
>> >>> app).
>> >>>
>> >>> Generally this works without issues.  Sometimes, the screen doesn't
>> >>> update.  If I profile the threads running, the webview is not showing
>> any
>> >>> activity (except maybe a call to uptime).  If I unplug and plug back
>> in
>> >>> the
>> >>> USB, the screen goes through all the pending updates (quickly flashes
>> >>> through them).  The app does *not* return to normal opperations at
>> this
>> >>> point: I have to unplug/plug back in for every message that is sent.
>>  If
>> >>> I
>> >>> do this while monitoring the threads, I see calls to the android
>> message
>> >>> handler happening at this point.
>> >>>
>> >>> When it is working correctly, these calls happen when the event is
>> >>> triggered.
>> >>>
>> >>> My questions - what could be causing this?  Is there a way to force
>> the
>> >>> message queue to trigger, other than unpluggin/pluggin back in?
>> >>>
>> >>> James
>> >>>
>> >>
>> >>
>> >
>>
>
>

Re: [Input request] Rethinking Plugin docs

[Lisa Seacat DeLuca]

If README.md is the standard why not just call all of them README and not 
have an index.md file at all for the plugins.  What is the advantage of 
having both?  Seems more confusing than anything.

Lisa Seacat DeLuca
Mobile Engineer | t: +415.787.4589 | ldel...@apache.org | | 
ldel...@us.ibm.com | lisaseacat.com | | 





From:   Andrew Grieve 
To: dev 
Date:   02/24/2014 01:41 PM
Subject:Re: [Input request] Rethinking Plugin docs
Sent by:agri...@google.com



On Mon, Feb 24, 2014 at 12:51 PM, Marcel Kinard  
wrote:

>
> On Feb 24, 2014, at 12:32 PM, Andrew Grieve  
wrote:
>
> > - We may also want to include README.md files in the translations.
> > doc/fr/index.md
> > doc/fr/README.md
>
> What content do you forsee being in README.md other than a
> table-of-contents to the languages? Or in other words, would it be
> public-facing content that could be collapsed in to the rest of the 
plugin
> docs?
>

On npmjs.org and on github, README.md's are the files that are shown most
prominently. So, I speculate that many plugins will not provide a doc/
index.md, and instead provide only a README.md.


>
> > - We don't need the version in the directory since we can use git tags 
to
> > find old versions
>
> That makes sense.
>
>

Re: MessageQueue seems to stop sending messages to the webView

[Don Coleman]

Andrew,

I'm seeing similar behavior for a plugin I'm working on. I might be able to
get you a sample if James doesn't have one.

- Don


On Mon, Feb 24, 2014 at 2:14 PM, Andrew Grieve  wrote:

> On Mon, Feb 24, 2014 at 2:14 PM, Andrew Grieve 
> wrote:
>
> > James - have so far been unable to come up with a repro case for this. If
> > there's a chance you could create one, that would be really helpful.
> >
> >
> > On Tue, Feb 18, 2014 at 2:16 PM, Andrew Grieve  >wrote:
> >
> >> Hmm, might be same problem as
> >> https://issues.apache.org/jira/browse/CB-6047. Let's move this
> >> conversation to that bug.
> >>
> >>
> >> On Tue, Feb 18, 2014 at 2:10 AM, James Rivett-Carnac <
> >> james.rivett.car...@gmail.com> wrote:
> >>
> >>> Hello,
> >>>
> >>> I'm uisng an embedded cordova webview and am seeing something where by
> >>> the
> >>> webview doesn't receive messages sent to it from my plugin.
> >>>
> >>> I've seen this with:
> >>>
> >>> android 4.3, 4.4.2, (Moto G, Nexus 7 2012)
> >>> cordova 3.3.0-rc1, 3.3.0-0.1.1, 3.3.1-0.4.2
> >>>
> >>> The application is receiveing informatiion from a USB device (the
> >>> phone/tablet runs in accessory mode), reading this information in its
> own
> >>> thread.  These call callbacks, and change the state in the webview
> >>> (lavaca
> >>> app).
> >>>
> >>> Generally this works without issues.  Sometimes, the screen doesn't
> >>> update.  If I profile the threads running, the webview is not showing
> any
> >>> activity (except maybe a call to uptime).  If I unplug and plug back in
> >>> the
> >>> USB, the screen goes through all the pending updates (quickly flashes
> >>> through them).  The app does *not* return to normal opperations at this
> >>> point: I have to unplug/plug back in for every message that is sent.
>  If
> >>> I
> >>> do this while monitoring the threads, I see calls to the android
> message
> >>> handler happening at this point.
> >>>
> >>> When it is working correctly, these calls happen when the event is
> >>> triggered.
> >>>
> >>> My questions - what could be causing this?  Is there a way to force the
> >>> message queue to trigger, other than unpluggin/pluggin back in?
> >>>
> >>> James
> >>>
> >>
> >>
> >
>

Re: MessageQueue seems to stop sending messages to the webView

[Andrew Grieve]

On Mon, Feb 24, 2014 at 2:14 PM, Andrew Grieve  wrote:

> James - have so far been unable to come up with a repro case for this. If
> there's a chance you could create one, that would be really helpful.
>
>
> On Tue, Feb 18, 2014 at 2:16 PM, Andrew Grieve wrote:
>
>> Hmm, might be same problem as
>> https://issues.apache.org/jira/browse/CB-6047. Let's move this
>> conversation to that bug.
>>
>>
>> On Tue, Feb 18, 2014 at 2:10 AM, James Rivett-Carnac <
>> james.rivett.car...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm uisng an embedded cordova webview and am seeing something where by
>>> the
>>> webview doesn't receive messages sent to it from my plugin.
>>>
>>> I've seen this with:
>>>
>>> android 4.3, 4.4.2, (Moto G, Nexus 7 2012)
>>> cordova 3.3.0-rc1, 3.3.0-0.1.1, 3.3.1-0.4.2
>>>
>>> The application is receiveing informatiion from a USB device (the
>>> phone/tablet runs in accessory mode), reading this information in its own
>>> thread.  These call callbacks, and change the state in the webview
>>> (lavaca
>>> app).
>>>
>>> Generally this works without issues.  Sometimes, the screen doesn't
>>> update.  If I profile the threads running, the webview is not showing any
>>> activity (except maybe a call to uptime).  If I unplug and plug back in
>>> the
>>> USB, the screen goes through all the pending updates (quickly flashes
>>> through them).  The app does *not* return to normal opperations at this
>>> point: I have to unplug/plug back in for every message that is sent.  If
>>> I
>>> do this while monitoring the threads, I see calls to the android message
>>> handler happening at this point.
>>>
>>> When it is working correctly, these calls happen when the event is
>>> triggered.
>>>
>>> My questions - what could be causing this?  Is there a way to force the
>>> message queue to trigger, other than unpluggin/pluggin back in?
>>>
>>> James
>>>
>>
>>
>

Re: MessageQueue seems to stop sending messages to the webView

[Andrew Grieve]

James - have so far been unable to come up with a repro case for this. If
there's a chance you could create one, that would be really helpful.


On Tue, Feb 18, 2014 at 2:16 PM, Andrew Grieve  wrote:

> Hmm, might be same problem as
> https://issues.apache.org/jira/browse/CB-6047. Let's move this
> conversation to that bug.
>
>
> On Tue, Feb 18, 2014 at 2:10 AM, James Rivett-Carnac <
> james.rivett.car...@gmail.com> wrote:
>
>> Hello,
>>
>> I'm uisng an embedded cordova webview and am seeing something where by the
>> webview doesn't receive messages sent to it from my plugin.
>>
>> I've seen this with:
>>
>> android 4.3, 4.4.2, (Moto G, Nexus 7 2012)
>> cordova 3.3.0-rc1, 3.3.0-0.1.1, 3.3.1-0.4.2
>>
>> The application is receiveing informatiion from a USB device (the
>> phone/tablet runs in accessory mode), reading this information in its own
>> thread.  These call callbacks, and change the state in the webview (lavaca
>> app).
>>
>> Generally this works without issues.  Sometimes, the screen doesn't
>> update.  If I profile the threads running, the webview is not showing any
>> activity (except maybe a call to uptime).  If I unplug and plug back in
>> the
>> USB, the screen goes through all the pending updates (quickly flashes
>> through them).  The app does *not* return to normal opperations at this
>> point: I have to unplug/plug back in for every message that is sent.  If I
>> do this while monitoring the threads, I see calls to the android message
>> handler happening at this point.
>>
>> When it is working correctly, these calls happen when the event is
>> triggered.
>>
>> My questions - what could be causing this?  Is there a way to force the
>> message queue to trigger, other than unpluggin/pluggin back in?
>>
>> James
>>
>
>

Re: Android: recreating plugins when loading url

[Andrew Grieve]

I think the history stack is reset when you use that API, so it somewhat
does make sense to recreate the plugins. Not sure if there is a better
answer than that...

I added the overload to allow not resetting the plugins, because I think
that is a useful thing to want to do as well.


On Fri, Feb 21, 2014 at 5:24 PM, Naik, Archana  wrote:

> Hi, Devs,
>
> Why do we recreate plugin every time an url is loaded? I am referring to
> loadUrlIntoView(url,bool) method.
> Other override which take only string(url), has this recreatePlugins
> boolean as true.
>
> Thanks
> Archana
>

Re: Tools & Plugins release

[Ian Clelland]

I approve of this -- there have been a number of fixes in file and
file-transfer for issues filed by the developer community.



On Mon, Feb 24, 2014 at 1:42 PM, Andrew Grieve  wrote:

> I'd like to do a release Wednesday. Just wanted to send the heads up, and
> see if there's any reason to delay / if there are things people are trying
> to get in.
>

Re: Tools & Plugins release

[Steven Gill]

+1 to release Wednesday!


On Mon, Feb 24, 2014 at 10:42 AM, Andrew Grieve wrote:

> I'd like to do a release Wednesday. Just wanted to send the heads up, and
> see if there's any reason to delay / if there are things people are trying
> to get in.
>

Re: [Input request] Rethinking Plugin docs

[Andrew Grieve]

On Mon, Feb 24, 2014 at 12:51 PM, Marcel Kinard  wrote:

>
> On Feb 24, 2014, at 12:32 PM, Andrew Grieve  wrote:
>
> > - We may also want to include README.md files in the translations.
> > doc/fr/index.md
> > doc/fr/README.md
>
> What content do you forsee being in README.md other than a
> table-of-contents to the languages? Or in other words, would it be
> public-facing content that could be collapsed in to the rest of the plugin
> docs?
>

On npmjs.org and on github, README.md's are the files that are shown most
prominently. So, I speculate that many plugins will not provide a doc/
index.md, and instead provide only a README.md.


>
> > - We don't need the version in the directory since we can use git tags to
> > find old versions
>
> That makes sense.
>
>

Tools & Plugins release

[Andrew Grieve]

I'd like to do a release Wednesday. Just wanted to send the heads up, and
see if there's any reason to delay / if there are things people are trying
to get in.

Re: CB-4846

[Shazron]

Hi Erik,
The gist of it is here:
http://cordova.apache.org/docs/en/3.4.0/guide_platforms_ios_plugin.md.html#iOS%20Plugins

Basically, you have to modify your js interface to take in a success and
failure callback. Then, in native code you create a PluginResult and set it
to a specific command status (CDVCommandStatus_*), then send it back
through the commandDelegate - it will figure out how to route it properly.
There are examples in the link above.


On Sun, Feb 23, 2014 at 11:38 PM, Erik Jan de Wit  wrote:

>
> On 22 Feb,2014, at 0:01 , Shazron  wrote:
>
> > Joe - this calls a background fetch handler for your app at an interval,
> it
> > doesn't really run in the background.
> >
> > Erik - just a quick code review:
> > 1. The method swizzling stuff is great but what I have planned (sometime
> in
> > the future, in progress) is this:
> > https://issues.apache.org/jira/browse/CB-5601
>
> Ahh cool, I'll keep an eye on that one.
>
> > 2. The way you are using callbacks is not quite correct
>
> Could you elaborate on that, I'll be more then happy to fix it
>
> >
> > Agree on it being a user space plugin -- but I was thinking it could be
> in
> > cordova-plugins maybe when the time comes
>
> I would love for it to be a cordova core plugin
>
> >
> >
> > On Fri, Feb 21, 2014 at 1:47 PM, Joe Bowser  wrote:
> >
> >> Is this actually running a service?  I thought this just runs a
> >> Cordova App in the background, which Android already has a setting
> >> for.
> >>
> >> On Fri, Feb 21, 2014 at 1:44 PM, Brian LeRoux  wrote:
> >>> I think its cool as a user space plugin for now though. Have you
> >> published
> >>> it to http://plugins.cordova.io ? (Its just like npm / you can read up
> >> on
> >>> how here: https://github.com/apache/cordova-plugman)
> >>>
> >>> I really like the idea of us looking at background processing.
> >>>
> >>> Android services: how would that work? Does Firefox OS have the concept
> >> of
> >>> background services? I know Chrome Mobile Apps guys have been doing
> some
> >>> thinking here too.
> >>>
> >>>
> >>> On Fri, Feb 21, 2014 at 2:53 AM, Erik Jan de Wit 
> >> wrote:
> >>>
>  Hi,
> 
>  I've created an initial version for
>  https://issues.apache.org/jira/browse/CB-4846 the plugin is located
> at
>  https://github.com/edewit/cordova-background-plugin
> 
>  Cheers,
> Erik Jan
> >>
>
>

Re: [Input request] Rethinking Plugin docs

[Marcel Kinard]

On Feb 24, 2014, at 12:32 PM, Andrew Grieve  wrote:

> - We may also want to include README.md files in the translations.
> doc/fr/index.md
> doc/fr/README.md

What content do you forsee being in README.md other than a table-of-contents to 
the languages? Or in other words, would it be public-facing content that could 
be collapsed in to the rest of the plugin docs?

> - We don't need the version in the directory since we can use git tags to
> find old versions

That makes sense.

Re: [Input request] Rethinking Plugin docs

[Shazron]

I agree with Andrew's points in #1. We have to update the 3.4.0 docs
nonetheless, since the URLs do not point to a specific tagged version.


On Mon, Feb 24, 2014 at 9:32 AM, Andrew Grieve  wrote:

> My thoughts here:
>
> 1.
> - We may also want to include README.md files in the translations.
> - I like not having a subdir for en/ so as to differentiate it as the one
> the others are based off of
> - We don't need the version in the directory since we can use git tags to
> find old versions
>
> maybe:
> doc/index.md
> doc/fr/index.md
> doc/fr/README.md
> doc/es/index.md
> doc/es/README.md
>
> 2.
> The plan is to render these on plugins.cordova.io, so we can certainly add
> logic there to maintain language pref.
>
>
>
>
> On Mon, Feb 24, 2014 at 11:13 AM, Lisa Seacat DeLuca  >wrote:
>
> > I noticed for the 3.4 release that the documentation for each of the
> > plugins redirects to the github repository for each plugin and a document
> > under doc/index.md
> >
> >
> >
> http://cordova.apache.org/docs/en/3.4.0/cordova_plugins_pluginapis.md.html#Plugin%20APIs
> >
> > If we want to have translations for each of the plugins then we're going
> > to need to rethink this a little.  Here are two options:
> >
> > 1. similar to the cordova-docs dir, we could have a language directory as
> > the parent.
> > ex. doc/en/index.md
> > and while we're at it we probably need the version as well
> > ex. doc/en/3.4.0/index.md
> >
> > If we do this then at least we can have the documentation for each
> > language.  But that doesn't solve the problem of the user being always
> > redirected to the english version of the documentation and not their
> > specific language.
> >
> > 2. Is it hard to do a build of the index.md for each plugin similar to
> > how we build the cordova-doc md files into html files?  If it were
> seamless
> > and part of the other documentation it would make my life
> > *coughTranslationcough* so much easier.  Plus it won't be as confusing on
> > end users having to choose their language more than one time.
> >
> > It'd be nice to get some input from everyone before I start writing a
> > complicated automated script for the plugin translations.
> >
> >
> > Lisa
> >
> > Lisa Seacat DeLuca
> > Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org*<
> ldel...@apache.org>| |
> > *ldel...@us.ibm.com*  | *lisaseacat.com*<
> http://www.lisaseacat.com/>| [image:
> > follow @LisaSeacat on twitter] |
> [image:
> > follow Lisa Seacat DeLuca on linkedin]<
> http://www.linkedin.com/in/lisaseacat>
> >
> >
>

Re: [Input request] Rethinking Plugin docs

[Andrew Grieve]

My thoughts here:

1.
- We may also want to include README.md files in the translations.
- I like not having a subdir for en/ so as to differentiate it as the one
the others are based off of
- We don't need the version in the directory since we can use git tags to
find old versions

maybe:
doc/index.md
doc/fr/index.md
doc/fr/README.md
doc/es/index.md
doc/es/README.md

2.
The plan is to render these on plugins.cordova.io, so we can certainly add
logic there to maintain language pref.




On Mon, Feb 24, 2014 at 11:13 AM, Lisa Seacat DeLuca wrote:

> I noticed for the 3.4 release that the documentation for each of the
> plugins redirects to the github repository for each plugin and a document
> under doc/index.md
>
>
> http://cordova.apache.org/docs/en/3.4.0/cordova_plugins_pluginapis.md.html#Plugin%20APIs
>
> If we want to have translations for each of the plugins then we're going
> to need to rethink this a little.  Here are two options:
>
> 1. similar to the cordova-docs dir, we could have a language directory as
> the parent.
> ex. doc/en/index.md
> and while we're at it we probably need the version as well
> ex. doc/en/3.4.0/index.md
>
> If we do this then at least we can have the documentation for each
> language.  But that doesn't solve the problem of the user being always
> redirected to the english version of the documentation and not their
> specific language.
>
> 2. Is it hard to do a build of the index.md for each plugin similar to
> how we build the cordova-doc md files into html files?  If it were seamless
> and part of the other documentation it would make my life
> *coughTranslationcough* so much easier.  Plus it won't be as confusing on
> end users having to choose their language more than one time.
>
> It'd be nice to get some input from everyone before I start writing a
> complicated automated script for the plugin translations.
>
>
> Lisa
>
> Lisa Seacat DeLuca
> Mobile Engineer | t: +415.787.4589 | 
> *ldel...@apache.org*| |
> *ldel...@us.ibm.com*  | 
> *lisaseacat.com*| [image:
> follow @LisaSeacat on twitter] | [image:
> follow Lisa Seacat DeLuca on linkedin]
>
>

Re: Introduction

[Andrew Grieve]

Great! Thanks for helping out, and look forward to working with you :)


On Mon, Feb 24, 2014 at 10:51 AM, Sebastien Blanc wrote:

> Hi,
>
> Just a short email to introduce myself :
> I'm Sébastien, working for the AeroGear project (aerogear.org) and have a
> lot of interest in Cordova.
>
> I hope I will be able to contribute from time to time. I already did a
> really small PR :
> https://github.com/apache/cordova-plugin-contacts/pull/22
>
> related to
>
> https://issues.apache.org/jira/browse/CB-6086
>

Re: iOS plugin add on Windows

[Andrew Grieve]

Sounds like a great bug to fix. And yes, please create a JIRA issue for it.

Likely the code is using path.join() where it should be using explicit '/'
+ foo + '/' + bar syntax.

The problem will either be in the cordova-plugman repo, or in the
node-xcode dependency (found in node_modules/xcode. repo lives:
https://github.com/alunny/node-xcode).




On Mon, Feb 24, 2014 at 10:41 AM, Andrey Kurdumov
wrote:

> My project have iOS and Android, but I develop on Windows most of the time
> and use Mac only for testing.
>
> Usually I add plugin from Mac, but this time I add plugin on Windows using
> 'cordova plugin add' command. Project for iOS was updated, but it has
> invalid directory separators in paths in project file. I do search for
> similar issues on JIRA, but don't found any.
> Anyone aware about such issue, and I overlook it on JIRA, or I have to
> create new issue for that.
>
> I would like to fix that. Maybe somebody has suggestions how to implement
> that properly?
>

Re: Engine confusion

[Andrew Grieve]

I think it makes the most sense to have:

name="..." <-- this is the only thing that specifies the thing whose
version you care about
platform="..." <-- this specifies that you care about the version only on a
subset of platforms.

So, for an android platform:



So, for an android engine, I'd like:





On Fri, Feb 21, 2014 at 9:54 AM, Marcel Kinard  wrote:

> I prefer the former. I'd rather do a match for a simple attribute value
> (which is easy to write an XSD for), than have to parse/unparse a value
> convention with a bunch of hyphens or some custom syntax.
>
> On Feb 21, 2014, at 9:36 AM, Jonathan Bond-Caron 
> wrote:
>
> >  runtime="chromeview" />
> >
> > Vs.
> >  ?
> >
>
>

[Input request] Rethinking Plugin docs

[Lisa Seacat DeLuca]

I noticed for the 3.4 release that the documentation for each of the 
plugins redirects to the github repository for each plugin and a document 
under doc/index.md

http://cordova.apache.org/docs/en/3.4.0/cordova_plugins_pluginapis.md.html#Plugin%20APIs

If we want to have translations for each of the plugins then we're going 
to need to rethink this a little.  Here are two options:

1. similar to the cordova-docs dir, we could have a language directory as 
the parent.
ex. doc/en/index.md
and while we're at it we probably need the version as well
ex. doc/en/3.4.0/index.md

If we do this then at least we can have the documentation for each 
language.  But that doesn't solve the problem of the user being always 
redirected to the english version of the documentation and not their 
specific language. 

2. Is it hard to do a build of the index.md for each plugin similar to how 
we build the cordova-doc md files into html files?  If it were seamless 
and part of the other documentation it would make my life 
*coughTranslationcough* so much easier.  Plus it won't be as confusing on 
end users having to choose their language more than one time.

It'd be nice to get some input from everyone before I start writing a 
complicated automated script for the plugin translations.


Lisa

Lisa Seacat DeLuca
Mobile Engineer | t: +415.787.4589 | ldel...@apache.org | | 
ldel...@us.ibm.com | lisaseacat.com | | 

Introduction

[Sebastien Blanc]

Hi,

Just a short email to introduce myself :
I'm Sébastien, working for the AeroGear project (aerogear.org) and have a
lot of interest in Cordova.

I hope I will be able to contribute from time to time. I already did a
really small PR :
https://github.com/apache/cordova-plugin-contacts/pull/22

related to

https://issues.apache.org/jira/browse/CB-6086

iOS plugin add on Windows

[Andrey Kurdumov]

My project have iOS and Android, but I develop on Windows most of the time
and use Mac only for testing.

Usually I add plugin from Mac, but this time I add plugin on Windows using
'cordova plugin add' command. Project for iOS was updated, but it has
invalid directory separators in paths in project file. I do search for
similar issues on JIRA, but don't found any.
Anyone aware about such issue, and I overlook it on JIRA, or I have to
create new issue for that.

I would like to fix that. Maybe somebody has suggestions how to implement
that properly?

Re: Introduction

[Andrey Kurdumov]

I do sign CLA and read Wiki, so I am aware about rules.

Initially I willing to contribute StatusBar plugin for Android. At least
basic implementation which show/hide it.
Still I think this is useful enough to add it.


2014-02-24 19:11 GMT+06:00 David Kemp :

> Welcome aboard!
> Please share the good and the bad.
>
> If you haven't already, check out the Wiki for workflow, and background.
>
> Also remember that if you submit patches you need to sign the CLA.
>
> Thanks!
>
>
>
>
> On Mon, Feb 24, 2014 at 8:02 AM, Andrey Kurdumov  >wrote:
>
> > Hello Cordova Devs,
> >
> > I currently working on  application, which will work on Android and iOS,
> > and willing to share solutions which I will found on my way.
> >
> > Also I work on Windows, and could help to test with issues which arise on
> > that platform.
> > I'm interested mostly in improvements in plugin development and tooling
> > processes for Cordova for now. My customer is very picky about native
> look
> > and feel, so I maybe hit some corner cases.
> >
> > Best regards
> > Andrey Kurdyumov
> >
>

Re: mobile-spec and releases: How do we test?

[Michal Mocny]

Hi,

Right now, the work live in the cordova-labs repo under the CDVTest branch (
https://github.com/apache/cordova-labs/tree/cdvtest).  Specifically, there
is a test plugin and test harness app.  Its still a work in progress, and
while several of the API tests from mobile-spec were moved to CDVTest
branches of the core plugin, the mobile-spec app is currently still the
canonical source for tests.

Sorry I dropped the ball on filing JIRA issues, but David and I have been
working on the test harness for our downstream cordova distribution (for
cca).  I'll be pushing all the applicable bits back up within the coming
weeks and then will document clearly what needs to happen to migrate
mobile-spec to see if we all agree on direction.  I guess: stay tuned.

-Michal


On Sun, Feb 23, 2014 at 11:05 PM, 罗琦  wrote:

> Hi all,
> How's the progress? Where's JIRA I could follow?
>
> We're building a Cordova-based framework and working closely to
> Cordova daily bits. We're still keeping tests in each plugin repo, and
> manually sync with Cordova-Mobile-Spec, that's even more painful after most
> of tests got removed from plugin repos.
> We added a little script to cli (a new command actually) to integrate
> tests of all currently installed plugins into to target app, that's way how
> we perform testing for now.
>
> Need some advice, thanks.
>
>
> -- Original --
> From:  "Michal Mocny";
> Date:  Thu, Oct 31, 2013 11:35 PM
> To:  "dev";
>
> Subject:  Re: mobile-spec and releases: How do we test?
>
>
> This is awesome progress, guys, thanks for the help.
>
> I'm going to put all the bits together and compile a list of tasks left and
> write-up instructions for those who have yet to take a look.  If everyone
> on the lists is still happy with the direction, I'll move those to JIRA.
>
>
> On Thu, Oct 31, 2013 at 11:08 AM, David Kemp  wrote:
>
> > I converted the couchdb reporter to the 2.0 style and added it to the
> repo.
> > It works(hard coded config), but still needs the configuration components
> > completed and some final adjustments to the data.
> >
> >
> >
> >
> > On Thu, Oct 31, 2013 at 11:05 AM, Anis KADRI 
> wrote:
> >
> > > I ported the contacts plugin [1] to the new style and I found the
> > > process to be more or less straightforward. I also kept the eval in
> > > there but there might be a better way ?
> > >
> > > [1] http://goo.gl/uhnwtz
> > >
> > > On Wed, Oct 30, 2013 at 3:42 PM, Michal Mocny 
> > wrote:
> > > > Sadly, we are approaching an in-between time of moving the
> mobile-spec
> > > > tests out of the app and into plugins.  We are still investigating
> the
> > > best
> > > > way to do this without disruption.
> > > >
> > > > For what its worth: several plugins now have a 'cdvtest' branch which
> > > > supplies new-style tests ripped out of mobile-spec.  If you are
> having
> > > > issues cleaning up the old style tests, take a look at the new ones
> (or
> > > try
> > > > porting yourself).
> > > >
> > > > I'm going to write up a doc with the summary of the state of testing
> > > within
> > > > a day or so given the results of this week to make it easier for you
> > (and
> > > > others) to pick up.
> > > >
> > > > -Michal
> > > >
> > > >
> > > > On Wed, Oct 30, 2013 at 1:54 PM, Naik, Archana 
> > wrote:
> > > >
> > > >>  Thanks Michal. You answered my questions.
> > > >>
> > > >>  More to elaborate on my question: I am testing amazon-fireos
> > > >> port(platform) with all plug-ins using mobile-spec. I am seeing some
> > > >> failures in 3.1.0 version because of test cases timing out. I am
> > pretty
> > > new
> > > >> to cordova and still in learning phase. :) I am trying to understand
> > > these
> > > >> failures. Interestingly they pass on 3.0.x version.
> > > >>
> > > >>  Archana
> > > >>
> > > >>
> > > >>   From: Michal Mocny 
> > > >> Date: Wednesday, October 30, 2013 10:27 AM
> > > >> To: "Naik, Archana" 
> > > >> Cc: "dev@cordova.apache.org" , Michal
> Mocny <
> > > >> mmo...@chromium.org>
> > > >>
> > > >> Subject: Re: mobile-spec and releases: How do we test?
> > > >>
> > > >>   May you clarify?
> > > >>
> > > >>  Right now, there is no formal way to test plugins, we are trying to
> > > >> invent that way now.  Check out cordova-labs repo's cdvtest branch
> > for a
> > > >> sample app & plugin to track progress.
> > > >>
> > > >>  Jasmine is hosted in that sample app, but plugins will not directly
> > > >> know/care.  Any testing framework which is api-compatible should
> work.
> > >  In
> > > >> practice, I'm not sure how compatible they all are, so it may very
> > well
> > > be
> > > >> limited to jasmine -- but it does mean you can make local
> > modifications
> > > >> such as our CI is doing to create a custom test reporter.
> > > >>
> > > >>  -Michal
> > > >>
> > > >>
> > > >> On Wed, Oct 30, 2013 at 12:57 PM, Naik, Archana 
> > > wrote:
> > > >>
> > > >>> Hi, Guys
> > > >>>
> > > >>> While on this topic, I have a question: how do I te

Re: Introduction

[David Kemp]

Welcome aboard!
Please share the good and the bad.

If you haven't already, check out the Wiki for workflow, and background.

Also remember that if you submit patches you need to sign the CLA.

Thanks!




On Mon, Feb 24, 2014 at 8:02 AM, Andrey Kurdumov wrote:

> Hello Cordova Devs,
>
> I currently working on  application, which will work on Android and iOS,
> and willing to share solutions which I will found on my way.
>
> Also I work on Windows, and could help to test with issues which arise on
> that platform.
> I'm interested mostly in improvements in plugin development and tooling
> processes for Cordova for now. My customer is very picky about native look
> and feel, so I maybe hit some corner cases.
>
> Best regards
> Andrey Kurdyumov
>

Introduction

[Andrey Kurdumov]

Hello Cordova Devs,

I currently working on  application, which will work on Android and iOS,
and willing to share solutions which I will found on my way.

Also I work on Windows, and could help to test with issues which arise on
that platform.
I'm interested mostly in improvements in plugin development and tooling
processes for Cordova for now. My customer is very picky about native look
and feel, so I maybe hit some corner cases.

Best regards
Andrey Kurdyumov