RE: Cordova and Crosswalk

[Hu, Ningxin]

> -Original Message-
> From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
> Grieve
> Sent: Wednesday, December 04, 2013 10:39 AM
> To: Andrew Grieve
> Cc: dev
> Subject: Re: Cordova and Crosswalk
> 
> On Tue, Dec 3, 2013 at 9:08 PM, Andrew Grieve  wrote:
> 
> > Wow, super impressive stuff!
> >
> > A couple things that weren't clear to me from your website:
> > - Is the idea that users will need to install XWalkRuntimeLib.apk in
> > addition to their app's .apk?
> > - Is it x86-only at the moment?
> >
> Also - What version of Android is required to use it? 4.0?

Android 4.0+.

Thanks,
-ningxin

> 
> 
> >
> > It seems as though Xwalk is made to match the Android Webview API
> > quite closely. I'm hesitant to make a separate repo for
> > cordova-crosswalk for this reason. I think we'd benefit a lot more by
> > having a single code base that could work with either webview. E.g.
> > add a level of abstraction so that cordova-android and Android plugins could
> use either webview impl.
> >
> > Does that make sense? WDYT?
> >
> > Andrew
> >
> >
> >
> > On Tue, Dec 3, 2013 at 5:02 PM, Brian LeRoux  wrote:
> >
> >> Crosswalk is cool. Very aligned with the Cordova approach and our
> >> desktop (and even mobile runtime) story right now is somewhat
> >> scattered. A unified cross platform approach would be a welcome
> >> option for our community to be sure.
> >>
> >> So, are you guys saying you guys want to donate the source to Apache
> >> as a subproject of Cordova (Eg. as cordova-crosswalk)?
> >>
> >>
> >> On Wed, Dec 4, 2013 at 12:40 AM, Hu, Ningxin 
> >> wrote:
> >>
> >> > Hi Cordova Developers,
> >> >
> >> > Crosswalk [1] is a web application runtime based on Blink and Chromium.
> >> It
> >> > supports Android 4.0+. By integrating Cordova with Crosswalk, it
> >> > brings remote debugging capability, better HTML5 support and higher
> >> performance to
> >> > Cordova apps.
> >> >
> >> > In Crosswalk projects, there is a crosswalk-cordova-android project
> >> > [2]
> >> to
> >> > prove the idea. It is derived from Cordova Android [3] and embeds
> >> Crosswalk
> >> > as the HTML5 runtime instead of WebView. Currently It is based on
> >> Cordova
> >> > 3.0.0 and supports 16 Cordova APIs. Please check the wiki [4] for
> >> > more details.
> >> >
> >> > Your thoughts about the integration?
> >> > Is it possible to support Crosswalk runtime as a platform in
> >> > Cordova upstream?
> >> >
> >> > Thanks,
> >> > -ningxin
> >> >
> >> > [1]: https://crosswalk-project.org/
> >> > [2]: https://github.com/crosswalk-project/crosswalk-cordova-android
> >> > [3]: https://github.com/apache/cordova-android
> >> > [4]: https://crosswalk-project.org/#wiki/crosswalk-cordova-android
> >> >
> >>
> >
> >

RE: Cordova and Crosswalk

[Hu, Ningxin]

> -Original Message-
> From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew
> Grieve
> Sent: Wednesday, December 04, 2013 10:08 AM
> To: dev
> Subject: Re: Cordova and Crosswalk
> 
> Wow, super impressive stuff!
> 
> A couple things that weren't clear to me from your website:
> - Is the idea that users will need to install XWalkRuntimeLib.apk in addition 
> to
> their app's .apk?
No. Crosswalk is embedded into your Cordova app.apk. No dependent APK will be 
needed to install your app with Crosswalk.

Please refer to our wiki 
https://crosswalk-project.org/#wiki/crosswalk-cordova-android for details.

> - Is it x86-only at the moment?
No. it supports both ARM and x86.

> It seems as though Xwalk is made to match the Android Webview API quite
> closely. I'm hesitant to make a separate repo for cordova-crosswalk for this
> reason. I think we'd benefit a lot more by having a single code base that 
> could
> work with either webview. E.g. add a level of abstraction so that 
> cordova-android
> and Android plugins could use either webview impl.
> 
> Does that make sense? WDYT?
> 
It is a good idea. We track this feature as 
https://crosswalk-project.org/jira/browse/XWALK-515. If people vote for this, 
we would like to implement it.

Thanks,
-ningxin

> Andrew
> 
> 
> 
> On Tue, Dec 3, 2013 at 5:02 PM, Brian LeRoux  wrote:
> 
> > Crosswalk is cool. Very aligned with the Cordova approach and our
> > desktop (and even mobile runtime) story right now is somewhat
> > scattered. A unified cross platform approach would be a welcome option
> > for our community to be sure.
> >
> > So, are you guys saying you guys want to donate the source to Apache
> > as a subproject of Cordova (Eg. as cordova-crosswalk)?
> >
> >
> > On Wed, Dec 4, 2013 at 12:40 AM, Hu, Ningxin  wrote:
> >
> > > Hi Cordova Developers,
> > >
> > > Crosswalk [1] is a web application runtime based on Blink and Chromium.
> > It
> > > supports Android 4.0+. By integrating Cordova with Crosswalk, it
> > > brings remote debugging capability, better HTML5 support and higher
> > > performance
> > to
> > > Cordova apps.
> > >
> > > In Crosswalk projects, there is a crosswalk-cordova-android project
> > > [2]
> > to
> > > prove the idea. It is derived from Cordova Android [3] and embeds
> > Crosswalk
> > > as the HTML5 runtime instead of WebView. Currently It is based on
> > > Cordova
> > > 3.0.0 and supports 16 Cordova APIs. Please check the wiki [4] for
> > > more details.
> > >
> > > Your thoughts about the integration?
> > > Is it possible to support Crosswalk runtime as a platform in Cordova
> > > upstream?
> > >
> > > Thanks,
> > > -ningxin
> > >
> > > [1]: https://crosswalk-project.org/
> > > [2]: https://github.com/crosswalk-project/crosswalk-cordova-android
> > > [3]: https://github.com/apache/cordova-android
> > > [4]: https://crosswalk-project.org/#wiki/crosswalk-cordova-android
> > >
> >

Re: Cordova and Crosswalk

[Andrew Grieve]

On Tue, Dec 3, 2013 at 9:08 PM, Andrew Grieve  wrote:

> Wow, super impressive stuff!
>
> A couple things that weren't clear to me from your website:
> - Is the idea that users will need to install XWalkRuntimeLib.apk in
> addition to their app's .apk?
> - Is it x86-only at the moment?
>
Also - What version of Android is required to use it? 4.0?


>
> It seems as though Xwalk is made to match the Android Webview API quite
> closely. I'm hesitant to make a separate repo for cordova-crosswalk for
> this reason. I think we'd benefit a lot more by having a single code base
> that could work with either webview. E.g. add a level of abstraction so
> that cordova-android and Android plugins could use either webview impl.
>
> Does that make sense? WDYT?
>
> Andrew
>
>
>
> On Tue, Dec 3, 2013 at 5:02 PM, Brian LeRoux  wrote:
>
>> Crosswalk is cool. Very aligned with the Cordova approach and our desktop
>> (and even mobile runtime) story right now is somewhat scattered. A unified
>> cross platform approach would be a welcome option for our community to be
>> sure.
>>
>> So, are you guys saying you guys want to donate the source to Apache as a
>> subproject of Cordova (Eg. as cordova-crosswalk)?
>>
>>
>> On Wed, Dec 4, 2013 at 12:40 AM, Hu, Ningxin 
>> wrote:
>>
>> > Hi Cordova Developers,
>> >
>> > Crosswalk [1] is a web application runtime based on Blink and Chromium.
>> It
>> > supports Android 4.0+. By integrating Cordova with Crosswalk, it brings
>> > remote debugging capability, better HTML5 support and higher
>> performance to
>> > Cordova apps.
>> >
>> > In Crosswalk projects, there is a crosswalk-cordova-android project [2]
>> to
>> > prove the idea. It is derived from Cordova Android [3] and embeds
>> Crosswalk
>> > as the HTML5 runtime instead of WebView. Currently It is based on
>> Cordova
>> > 3.0.0 and supports 16 Cordova APIs. Please check the wiki [4] for more
>> > details.
>> >
>> > Your thoughts about the integration?
>> > Is it possible to support Crosswalk runtime as a platform in Cordova
>> > upstream?
>> >
>> > Thanks,
>> > -ningxin
>> >
>> > [1]: https://crosswalk-project.org/
>> > [2]: https://github.com/crosswalk-project/crosswalk-cordova-android
>> > [3]: https://github.com/apache/cordova-android
>> > [4]: https://crosswalk-project.org/#wiki/crosswalk-cordova-android
>> >
>>
>
>

Re: [android] How to remove the automatic default of

[Andrew Grieve]

Michal - I'm not s


On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams wrote:

> Absolutely agree.
>
> +1 for * as default, but just as importantly, +1 for never having to hax
> inside ./platforms/**/* for this stuff.
>
> We are already forced to use hooks to enforce ./platforms as a build
> artefact. Any progress towards the great goal of being able to safely
> .gitignore the platforms make me feel warm and fuzzy. ;)
>
>
>
> On 4 Dec 2013, at 7:09 am, Michal Mocny  wrote:
>
> > Tommy, absolutely the default should remain *, as I said.
> >
> > But I hope we can agree that it should also be possible to override the
> > default without requiring hacks.  iOS already supports this, so its a
> > matter of feature parity.
> >
> > -Michal
> >
> >
> > On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams 
> wrote:
> >
> >> Please don't go back to when every new dev had to struggle with the
> Google
> >> group or irc to find out why their ajax requests didn't work.
> >>
> >> There was a hge discussion at the time that we chose to default to *
> >> On 04/12/2013 6:03 am, "Michal Mocny"  wrote:
> >>
> >>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson <
> bra...@chromium.org
>  wrote:
> >>>
>  There are two different files here: one is defaults.xml, which the CLI
>  takes as the basis for its platform config.xml. The other is the
> >>> config.xml
>  that you get after running bin/create. In the CLI world, that second
> >> file
>  is immediately overwritten by one created from defaults.xml, the
> >>> top-level
>  app config.xml, etc.
> 
> >>>
> >>> Okay, thats what I thought we were doing, but I cannot find where/how
> the
> >>> defaults.xml is created in the first place.  I see now that it does
> exist
> >>> in my CLI projects, but seems not to exist inside our platforms nor
> CLI,
> >>> nor can I find the code that generates it.
> >>>
> >>>
> 
>  I support the second point of removing the  from
> >> the
>  CLI's hello world template app; it should be turned into a comment.
> 
> >>>
> >>> Seems this is redundant anyway given that the platforms provide this
> as a
> >>> default.  Regarding leaving it in as a comment: should we embed the
> full
> >>> spec as a comment?  If not, I would just leave a general description
> and
> >>> link to the spec docs online.
> >>>
> >>>
>  I don't think we should be including  by default
>  anywhere, unless we really do want to disable the whitelist on that
>  platform. And if we do want to disable it, why not in the native code
>  instead of allowing everything by default?
> 
> >>>
> >>> I remember about a year ago we had a bunch of talks regarding the
> default
> >>> whitelist, and decided that almost every developer doesn't want to use
> a
> >>> whitelist and wants every request to be allowed by default.  For those
> >> few
> >>> devs that want this (false?) sense of security they can learn how to
> >>> opt-in, instead of having the same question on the user lists over and
> >> over
> >>> about how to opt-out.
> >>>
> >>> Changing the platforms to allow * by default is an interesting idea,
> but
> >> I
> >>> would rather see a solution that doesn't need that change.  Plus its a
> >> bit
> >>> less semantic/declarative aka more magical/surprising.
> >>>
> >>>
> 
>  Braden
> 
> 
>  On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny 
> >> wrote:
> 
> > On ios, the default config.xml file (aka the platform defaults) is
>  bundled
> > as part of the ios project template, and the project template is easy
> >>> to
> > override using flags to create script / CLI config options.  Easy,
> >>> great.
> >
> > For android, the default config.xml file is bundled with the platform
> > framework itself and not as part of the project template.  I assume
> >>> this
>  is
> > not easy to fix, otherwise we would have made the change already?
> >
> > Since the  tag is additive (i.e. cannot just override it by
> > appending), there is no way to remove that default without reaching
> >> in
>  and
> > editing cordova-android/framework/res/xml/config.xml file directly
>  (either
> > with a custom post-platform-add hook to run sed, or by forking
> > cordova-android to change the default, both shitty options imho).
> >
> > Any suggestions on how to fix this?
> >
> > I was hoping to propose that we move the tag out of all the platform
> > templates and instead add it to the hello-world app template -- but I
>  think
> > that won't work well with the platform-scripts workflow since that
> >> flow
> > doesn't use an application level config.xml at all right now.
>

I like your suggestion here actually.
- Take  out of defaults.xml, and leave it in CLI's config.xml
template
- Leave  in template's config.xml

That will mean:
- for non-CLI projects, it will be there by default, and users can edit it
directly
- for CLI projects, it 

Re: Cordova and Crosswalk

[Andrew Grieve]

Wow, super impressive stuff!

A couple things that weren't clear to me from your website:
- Is the idea that users will need to install XWalkRuntimeLib.apk in
addition to their app's .apk?
- Is it x86-only at the moment?

It seems as though Xwalk is made to match the Android Webview API quite
closely. I'm hesitant to make a separate repo for cordova-crosswalk for
this reason. I think we'd benefit a lot more by having a single code base
that could work with either webview. E.g. add a level of abstraction so
that cordova-android and Android plugins could use either webview impl.

Does that make sense? WDYT?

Andrew



On Tue, Dec 3, 2013 at 5:02 PM, Brian LeRoux  wrote:

> Crosswalk is cool. Very aligned with the Cordova approach and our desktop
> (and even mobile runtime) story right now is somewhat scattered. A unified
> cross platform approach would be a welcome option for our community to be
> sure.
>
> So, are you guys saying you guys want to donate the source to Apache as a
> subproject of Cordova (Eg. as cordova-crosswalk)?
>
>
> On Wed, Dec 4, 2013 at 12:40 AM, Hu, Ningxin  wrote:
>
> > Hi Cordova Developers,
> >
> > Crosswalk [1] is a web application runtime based on Blink and Chromium.
> It
> > supports Android 4.0+. By integrating Cordova with Crosswalk, it brings
> > remote debugging capability, better HTML5 support and higher performance
> to
> > Cordova apps.
> >
> > In Crosswalk projects, there is a crosswalk-cordova-android project [2]
> to
> > prove the idea. It is derived from Cordova Android [3] and embeds
> Crosswalk
> > as the HTML5 runtime instead of WebView. Currently It is based on Cordova
> > 3.0.0 and supports 16 Cordova APIs. Please check the wiki [4] for more
> > details.
> >
> > Your thoughts about the integration?
> > Is it possible to support Crosswalk runtime as a platform in Cordova
> > upstream?
> >
> > Thanks,
> > -ningxin
> >
> > [1]: https://crosswalk-project.org/
> > [2]: https://github.com/crosswalk-project/crosswalk-cordova-android
> > [3]: https://github.com/apache/cordova-android
> > [4]: https://crosswalk-project.org/#wiki/crosswalk-cordova-android
> >
>

Re: [Android] InAppBrowser UI changes and Resources

[Brian LeRoux]

src/platform seems simplest to me
On Dec 4, 2013 7:09 AM, "Steven Gill"  wrote:

> I think it looks good!
>
> I noticed that you created a top level res folder in the plugin to store
> your resources. This rises the question about where should resources live
> within a plugin.
>
> Two options I see are:
> 1) Create the res folder with platform folders within to store resources.
> (this is what joe is doing in the repo above)
> 2) Keep resources in src/platform (I believe iOS bundles resources in
> .bundle which is stored in src/ios for certain plugins)
>
> Thoughts on which one makes the sense?
>
>
> On Tue, Dec 3, 2013 at 10:57 AM, Joe Bowser  wrote:
>
> > Oh crap, here's my GitHub fork of what I did:
> > https://github.com/infil00p/cordova-plugin-inappbrowser/tree/drawables
> >
> >
> >
> > On Tue, Dec 3, 2013 at 10:57 AM, Joe Bowser  wrote:
> > > Hey
> > >
> > > I just did some hacking on the InAppBrowser UI, and I've added the
> > > ability to add drawables.  I've used the Android drawables, which I
> > > believe to have an acceptable licence and now we have something
> > > resembling a real Android UI.  I think there will probably need to be
> > > some more tweaking to get the icons to look right, but I think this
> > > looks a LOT better than what we had previously.
> > >
> > > I also wanted to discuss using the source tag to transport assets in
> > > plugins.  It seems to work fine, but I'm wondering if anyone had any
> > > strong opinions about what I did here before I push this fix up to the
> > > InAppBrowser.
> > >
> > > Joe
> >
>

Re: Cordova for Ubuntu

[Maxim Ermilov]

> When I run npm test on cordova cli, I get one failing test.
https://github.com/apache/cordova-cli/pull/103

> Plugins have been merged and pushed to Dev.
awesome! thank you.

> No geolocation plugin support, any specific reason why?
ups. I forget about it:( I will publish patches for it later today.

> Most of the plugins don't have feature tags for ubuntu. Was this done for
a reason?
yes.
cordova-ubuntu uses feature tags to specify additional required permissions
& shared libraries.
most plugins does not need them.

> I noticed the ones that did have feature tags had the name set to Camera.
> I figured this was a copy paste error and I fixed it up where applicable.
It was a copy paste error.

> Hopefully the CLI + Plugman are ready for primetime for the 3.3.0 release
coming up.
is there any blocking issue?

__
Cheers,
-Maxim

Re: PluginEntry.java crash in getClassByName

[Joe Bowser]

Cool.  Feel free to close your pull request. We can't close it on our end. :(

On Tue, Dec 3, 2013 at 2:52 PM, Axel Nennker  wrote:
> Pull request is here: https://github.com/apache/cordova-android/pull/87
> I took the easier path to check for the empty string in PluginEntry.java
> instead of trying to find out what other effects a change in
> PluginManager.java from "" to null might have.
>
> Axel
>
>
> 2013/12/3 Axel Nennker 
>>
>> done:
>> https://issues.apache.org/jira/browse/CB-5537
>>
>>
>>
>> 2013/12/3 Joe Bowser 
>>>
>>> Can you please create an issue so that this is tracked?
>>>
>>> On Tue, Dec 3, 2013 at 11:02 AM,   wrote:
>>> > Hi,
>>> >
>>> > I don't know why or since when but getClassByName is called with an
>>> > argument
>>> > of "" (not null).
>>> >
>>> > The method getClassByName checks for null but not for "" and so it
>>> > crashes.
>>> >
>>> > This happens for the service http://api.phonegap.com/1.0/device
>>> >
>>> > I am using cordova-3.1.0-0.2.0
>>> >
>>> > A screenshot of the debugging window is attached.
>>> >
>>> > A simple fix seems to be to never set this.pluginClass in
>>> > PluginEntry.java
>>> > to "" but to null. PluginManager.java contains the assignment:
>>> > pluginClass =
>>> > ""
>>> >
>>> >
>>> >
>>> > -Axel
>>> >
>>> >
>>
>>
>

Re: 3.3.0?

[Steven Gill]

Issue created https://issues.apache.org/jira/browse/CB-5538


On Tue, Dec 3, 2013 at 11:42 AM, Steven Gill  wrote:

> I will look at tagging cordova-js, mobile-spec and hello world this
> afternoon if we don't have any objections.
>
>
> On Tue, Dec 3, 2013 at 11:02 AM, Sergey Grebnov (Akvelon) <
> v-seg...@microsoft.com> wrote:
>
>> Hey Jesse, please add me to the review/merge queue. I'm working on WP8/W8
>> api fixes as per mobile spec tests, already sent the following pull
>> requests; will have more fixes tomorrow
>>
>> https://issues.apache.org/jira/browse/CB-5525
>> https://github.com/apache/cordova-plugin-contacts/pull/14
>>
>> https://issues.apache.org/jira/browse/CB-5531
>> https://github.com/apache/cordova-plugin-file/pull/14
>>
>> https://issues.apache.org/jira/browse/CB-5532
>> https://github.com/apache/cordova-plugin-file/pull/15
>>
>> Thx!
>> Sergey
>> -Original Message-
>> From: Jesse [mailto:purplecabb...@gmail.com]
>> Sent: Tuesday, December 3, 2013 10:57 PM
>> To: dev@cordova.apache.org
>> Subject: Re: 3.3.0?
>>
>> Yes, Dick, I'll get your pull request in today.
>> I need to today ( or at least a couple hours ) to sort out any other
>> additions/changes I might need to cordova-js.
>> Anyone else?
>>
>> Cheers,
>>   Jesse
>>
>>
>> @purplecabbage
>> risingj.com
>>
>>
>> On Tue, Dec 3, 2013 at 10:11 AM, Dick Van den Brink <
>> d_vandenbr...@outlook.com> wrote:
>>
>> > Would be nice to see  a release so a +1.
>> >
>> > Any change my pull request (on github) for pre_package hook on windows
>> > 8 can be merged before this release? (Or at least gets some feedback
>> > so I can
>> > improve?)
>> >
>> >
>> >
>> >
>> >
>> > Verzonden met Windows Mail
>> >
>> >
>> >
>> >
>> >
>> > Van: Joe Bowser
>> > Verzonden: dinsdag 3 december 2013 19:11
>> > Aan: dev@cordova.apache.org
>> >
>> >
>> >
>> >
>> >
>> > OK, it'd be good if more people chimed in on this thread before we tag
>> > the JS.
>> >
>> > On Mon, Dec 2, 2013 at 3:50 PM, Naik, Archana  wrote:
>> > > Yes.. +1 for obvious reasons!!:))
>> > >
>> > > On 12/2/13 3:44 PM, "Jesse"  wrote:
>> > >
>> > >>Yes, +1!
>> > >>I believe many of us are trying to wrap for the holidays by the 13th.
>> > >>Let's aim for an RC later this week.
>> > >>
>> > >>
>> > >>@purplecabbage
>> > >>risingj.com
>> > >>
>> > >>
>> > >>On Mon, Dec 2, 2013 at 3:33 PM, Steven Gill 
>> > >>wrote:
>> > >>
>> > >>> Sounds good. We could aim to make that the first release of ubuntu
>> > >>>+ fireos  as well!
>> > >>>
>> > >>> I leave for vacation Dec 13, so I would LOVE if we could test, tag
>> > >>>the RC,  test and release final before then!
>> > >>>
>> > >>>
>> > >>> On Mon, Dec 2, 2013 at 3:22 PM, Jesse 
>> wrote:
>> > >>>
>> > >>> > I would like to see a 3.3.0 before the holiday break as well.
>> > >>> >
>> > >>> >
>> > >>> >
>> > >>> > @purplecabbage
>> > >>> > risingj.com
>> > >>> >
>> > >>> >
>> > >>> > On Mon, Dec 2, 2013 at 3:06 PM, Brian LeRoux  wrote:
>> > >>> >
>> > >>> > > Yes pls. Even if its just a ceremonial tag on other platforms.
>> > >>> > > On Dec 3, 2013 9:56 AM, "Joe Bowser"  wrote:
>> > >>> > >
>> > >>> > > > Hey
>> > >>> > > >
>> > >>> > > > Does anyone think we can do a 3.3.0 release sometime before
>> > >>> > > > Dec
>> > >>>13th?
>> > >>> > > > I'd like to have one more release before the end of the year
>> > >>> > > > that supports the new KitKat phones and adds the Chrome
>> > >>> > > > Remote
>> > >>>Debugging.
>> > >>> > > >
>> > >>> > > > How do other people feel about this?
>> > >>> > > >
>> > >>> > > > Joe
>> > >>> > > >
>> > >>> > >
>> > >>> >
>> > >>>
>> > >
>> >
>>
>
>

Re: PluginEntry.java crash in getClassByName

[Axel Nennker]

Pull request is here: https://github.com/apache/cordova-android/pull/87
I took the easier path to check for the empty string in PluginEntry.java
instead of trying to find out what other effects a change in
PluginManager.java from "" to null might have.

Axel


2013/12/3 Axel Nennker 

> done:
> https://issues.apache.org/jira/browse/CB-5537
>
>
>
> 2013/12/3 Joe Bowser 
>
>> Can you please create an issue so that this is tracked?
>>
>> On Tue, Dec 3, 2013 at 11:02 AM,   wrote:
>> > Hi,
>> >
>> > I don't know why or since when but getClassByName is called with an
>> argument
>> > of "" (not null).
>> >
>> > The method getClassByName checks for null but not for "" and so it
>> crashes.
>> >
>> > This happens for the service http://api.phonegap.com/1.0/device
>> >
>> > I am using cordova-3.1.0-0.2.0
>> >
>> > A screenshot of the debugging window is attached.
>> >
>> > A simple fix seems to be to never set this.pluginClass in
>> PluginEntry.java
>> > to "" but to null. PluginManager.java contains the assignment:
>> pluginClass =
>> > ""
>> >
>> >
>> >
>> > -Axel
>> >
>> >
>>
>
>

Re: PluginEntry.java crash in getClassByName

[Axel Nennker]

done:
https://issues.apache.org/jira/browse/CB-5537



2013/12/3 Joe Bowser 

> Can you please create an issue so that this is tracked?
>
> On Tue, Dec 3, 2013 at 11:02 AM,   wrote:
> > Hi,
> >
> > I don't know why or since when but getClassByName is called with an
> argument
> > of "" (not null).
> >
> > The method getClassByName checks for null but not for "" and so it
> crashes.
> >
> > This happens for the service http://api.phonegap.com/1.0/device
> >
> > I am using cordova-3.1.0-0.2.0
> >
> > A screenshot of the debugging window is attached.
> >
> > A simple fix seems to be to never set this.pluginClass in
> PluginEntry.java
> > to "" but to null. PluginManager.java contains the assignment:
> pluginClass =
> > ""
> >
> >
> >
> > -Axel
> >
> >
>

Re: Cordova and Crosswalk

[Brian LeRoux]

Crosswalk is cool. Very aligned with the Cordova approach and our desktop
(and even mobile runtime) story right now is somewhat scattered. A unified
cross platform approach would be a welcome option for our community to be
sure.

So, are you guys saying you guys want to donate the source to Apache as a
subproject of Cordova (Eg. as cordova-crosswalk)?


On Wed, Dec 4, 2013 at 12:40 AM, Hu, Ningxin  wrote:

> Hi Cordova Developers,
>
> Crosswalk [1] is a web application runtime based on Blink and Chromium. It
> supports Android 4.0+. By integrating Cordova with Crosswalk, it brings
> remote debugging capability, better HTML5 support and higher performance to
> Cordova apps.
>
> In Crosswalk projects, there is a crosswalk-cordova-android project [2] to
> prove the idea. It is derived from Cordova Android [3] and embeds Crosswalk
> as the HTML5 runtime instead of WebView. Currently It is based on Cordova
> 3.0.0 and supports 16 Cordova APIs. Please check the wiki [4] for more
> details.
>
> Your thoughts about the integration?
> Is it possible to support Crosswalk runtime as a platform in Cordova
> upstream?
>
> Thanks,
> -ningxin
>
> [1]: https://crosswalk-project.org/
> [2]: https://github.com/crosswalk-project/crosswalk-cordova-android
> [3]: https://github.com/apache/cordova-android
> [4]: https://crosswalk-project.org/#wiki/crosswalk-cordova-android
>

Re: Camera targetWidth & targetHeight

[Shazron]

Thanks for doing this John.

I think the immediate win is to do this:
"If the group doesn't want to support only providing one of the properties,
then I would expect that the onError callback is called when only one is
provided rather than simply ignoring them as is the case with iOS and
Windows Phone."

... since this should be done anyway regardless of what is decided.


On Tue, Dec 3, 2013 at 8:34 AM, James Jong  wrote:

> For targetWidth = 2048 , targetHeight=768, does it make sense to have the
> result picture with width=768,height=1024?  That seems odd to me.
>
> -James Jong
>
> On Dec 3, 2013, at 7:34 AM, John M. Wargo  wrote:
>
> > It occurred to me this morning that I didn't test a scenario where an
> application deliberately didn't maintain an appropriate aspect ratio with
> targetWidth & targetHeight.
> >
> > I added a button to my app that set targetWidth to 2048 and targetHeight
> to 768.
> >
> > On Android I got the following:
> >
> > Portrait: 768x1024
> > Landscape: 1024x768
> >
> > On iOS I got the following:
> >
> > Portrait: 576x768
> > Landscape: 1024x768
> >
> > Not what I expected. So apparently the API grabs the smaller property
> and applies a set aspect ratio to the resulting photo rather than try to do
> something weird. Notice again that on iOS the API applies the restriction
> weirdly in portrait.
> >
> > On 12/2/2013 10:18 PM, Simon MacDonald wrote:
> >> IIRC on Android if you only specify the width or height it will
> determine
> >> what the other value should be by using the same aspect ration as the
> >> original image.
> >>
> >>
> >> Simon Mac Donald
> >> http://hi.im/simonmacdonald
> >>
> >>
> >> On Mon, Dec 2, 2013 at 10:15 PM, John M. Wargo 
> wrote:
> >>
> >>> A while back I posted a question regarding Camera targetWidth &
> >>> targetHeight properties and how they worked. After some discussion, the
> >>> conclusion I reached was that the documentation couldn't be correct
> about
> >>> how it worked since there was no way to determine the camera's
> resolution
> >>> with the current API but the docs said I had to provide both
> parameters.  I
> >>> said I'd do some testing and I have finally gotten around to
> completing it.
> >>> Here's what I discovered:
> >>>
> >>> I created an application that allowed me to pass in different values
> for
> >>> targetWidth & targetHeight when taking a picture. I tested at the
> following
> >>> image sizes: 640x480, 800x600, 1024x768 as well as setting only the
> >>> targetWidth to 1024 or only the targetHeight to 768.
> >>>
> >>> Here's the results:
> >>>
> >>> Android
> >>> PortraitLandscape
> >>> 480x640 640x480
> >>> 600x800 800x600
> >>> 768x10241024x768
> >>> 768x10241024x768
> >>> 768x10241024x768
> >>>
> >>>
> >>>
> >>> iOS
> >>> PortraitLandscape
> >>> 360x480 640x480
> >>> 450x600 800x600
> >>> 576x768 1024x768
> >>> 2448x3264   3264x2448
> >>> 2448x3264   3264x2448
> >>>
> >>>
> >>>
> >>> Windows Phone 8
> >>> PortraitLandscape
> >>> 1836x3264   3264x1836
> >>> 1836x3264   3264x1836
> >>> 1836x3264   3264x1836
> >>> 1836x3264   3264x1836
> >>> 1836x3264   3264x1836
> >>>
> >>>
> >>> As you can see, Android properly implements the targetWidth &
> targetHeight
> >>> properties. On iOS, it supports setting both properties, but not
> instances
> >>> where only one is specified. Windows Phone 8 ignores the parameters
> >>> completely.  On iOS, when you turn the device on its side, the Camera
> API
> >>> applies the target width or height to the wrong axis (Android does this
> >>> well however).
> >>>
> >>> I'm trying to test this on a BlackBerry device, but my development
> >>> environment is giving me fits right now. I'll work on it in the
> morning and
> >>> publish my results when I get them.
> >>>
> >>> I would suggest that the android implementation is as expected and that
> >>> the other platforms need their implementations of targetWidth &
> >>> targetHeight adjusted so it works correctly. The documentation should
> be
> >>> updated as well as it's incorrect today specifying that both properties
> >>> must be provided.
> >>>
> >>> If the group doesn't want to support only providing one of the
> properties,
> >>> then I would expect that the onError callback is called when only one
> is
> >>> provided rather than simply ignoring them as is the case with iOS and
> >>> Windows Phone.
> >>>
> >>> I posted my sample application and a spreadsheet with my results to
> >>> https://github.com/johnwargo/camera_res_test
> >>>
> >>> --
> >>> John M. Wargo
> >>> @johnwargo 
> >>> www.johnwargo.com 
> >>> 
> >>> 
> >>> 
> >>> 
> >>

Re: Plugins Release today

[Steven Gill]

On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland  wrote:

> On Tue, Dec 3, 2013 at 3:00 PM, Steven Gill 
> wrote:
>
> > Thanks for filling me in on the state!
> >
> > Is it just File that isn't ready? File-transfer is good?
> >
>
> I'll see if I can run a test on iOS with the dev branch of file-transfer,
> and the master branch of file -- if that still passes, I'll OK releasing
> file-transfer. (If not, I'll fix it until it does :) )
>
> Sounds good!

>
> > I don't think it is worth it to rip out the code from dev, especially if
> it
> > is almost ready. I will hold off releasing file with this plugins
> release.
> > We can aim to get a new version of file out next week after it has been
> > tested (especially with plugins that depend on it). Of course, if you
> > strongly feel some of those other commits on file should get out asap,
> then
> > lets move forward with ripping out so it can be released.
> >
> > In the future we should all try to work off branches and push code onto
> dev
> > that is ready to be pushed to master. We should use dev as master since
> our
> > master branch is just for releasing.
>
>
> Dev becomes a staging branch, essentially; and all actual dev work happens
> on branches. That sounds like a more sane way to do it. The only reason I
> had it on dev in the first place was to be able to test with buildbot --
> I'd love to have a way to run those branches through the CI server before
> merging them into dev/staging/master.


Good point. Maybe we standardize a third branch (ducks for cover) that the
CI server also tests and can be used for breaking dev work. This way dev is
used for staging and only has code that can be released. I'm afraid that
this just adds more complexity to plugins though and I am not a fan of
adding more complexity.


>
 Ian
>
>
>
> > Still confusing at times. It will be
> > nice once we can get away from this dev-master setup we have. I'm sure
> many
> > of us have pushed code to dev that isn't in a sate to be released. Maybe
> > this point/process should get added to our wiki? Not sure where the best
> > place for it would be.
> >
> >
> >
> >
> > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland 
> > wrote:
> >
> > > Hey Steven,
> > >
> > > File is close to being ready, but I haven't merged in my Android code
> > yet,
> > > and I want to add some more tests, given how critical the plugin is.
> I'm
> > > not comfortable with it going to master yet. If you want, I can pull it
> > out
> > > of dev and put it on another branch. (There have been some other
> commits,
> > > so we could also create a new branch without those commits, and merge
> > > *that* into master instead)
> > >
> > > Let me know how you want to handle it, I'll help out any way I can.
> > >
> > > Ian
> > >
> > >
> > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill 
> > > wrote:
> > >
> > > > Any plugin issues I should know about before releasing today?
> > > >
> > > > Last I heard file and file-transfer dev branches aren't ready to be
> > > merged
> > > > into master. Has this changed? Ian?
> > > >
> > > > Plugin issues that are still being reviewed/worked on:
> > > > https://issues.apache.org/jira/browse/CB-5525
> > > > https://issues.apache.org/jira/browse/CB-5531
> > > > https://issues.apache.org/jira/browse/CB-5532
> > > > https://issues.apache.org/jira/browse/CB-5430
> > > > https://issues.apache.org/jira/browse/CB-5504
> > > > https://issues.apache.org/jira/browse/CB-5505
> > > >
> > > > I can wait until later in the day to release if some of these are
> > getting
> > > > resolve today. I know Jesse is looking at the windows ones.
> > > >
> > > > We can also just do another plugin release next week (or post
> holidays)
> > > > once some of these land.
> > > >
> > >
> >
>

Re: Plugins Release today

[Ian Clelland]

On Tue, Dec 3, 2013 at 3:00 PM, Steven Gill  wrote:

> Thanks for filling me in on the state!
>
> Is it just File that isn't ready? File-transfer is good?
>

I'll see if I can run a test on iOS with the dev branch of file-transfer,
and the master branch of file -- if that still passes, I'll OK releasing
file-transfer. (If not, I'll fix it until it does :) )


> I don't think it is worth it to rip out the code from dev, especially if it
> is almost ready. I will hold off releasing file with this plugins release.
> We can aim to get a new version of file out next week after it has been
> tested (especially with plugins that depend on it). Of course, if you
> strongly feel some of those other commits on file should get out asap, then
> lets move forward with ripping out so it can be released.
>
> In the future we should all try to work off branches and push code onto dev
> that is ready to be pushed to master. We should use dev as master since our
> master branch is just for releasing.


Dev becomes a staging branch, essentially; and all actual dev work happens
on branches. That sounds like a more sane way to do it. The only reason I
had it on dev in the first place was to be able to test with buildbot --
I'd love to have a way to run those branches through the CI server before
merging them into dev/staging/master.


Ian



> Still confusing at times. It will be
> nice once we can get away from this dev-master setup we have. I'm sure many
> of us have pushed code to dev that isn't in a sate to be released. Maybe
> this point/process should get added to our wiki? Not sure where the best
> place for it would be.
>
>
>
>
> On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland 
> wrote:
>
> > Hey Steven,
> >
> > File is close to being ready, but I haven't merged in my Android code
> yet,
> > and I want to add some more tests, given how critical the plugin is. I'm
> > not comfortable with it going to master yet. If you want, I can pull it
> out
> > of dev and put it on another branch. (There have been some other commits,
> > so we could also create a new branch without those commits, and merge
> > *that* into master instead)
> >
> > Let me know how you want to handle it, I'll help out any way I can.
> >
> > Ian
> >
> >
> > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill 
> > wrote:
> >
> > > Any plugin issues I should know about before releasing today?
> > >
> > > Last I heard file and file-transfer dev branches aren't ready to be
> > merged
> > > into master. Has this changed? Ian?
> > >
> > > Plugin issues that are still being reviewed/worked on:
> > > https://issues.apache.org/jira/browse/CB-5525
> > > https://issues.apache.org/jira/browse/CB-5531
> > > https://issues.apache.org/jira/browse/CB-5532
> > > https://issues.apache.org/jira/browse/CB-5430
> > > https://issues.apache.org/jira/browse/CB-5504
> > > https://issues.apache.org/jira/browse/CB-5505
> > >
> > > I can wait until later in the day to release if some of these are
> getting
> > > resolve today. I know Jesse is looking at the windows ones.
> > >
> > > We can also just do another plugin release next week (or post holidays)
> > > once some of these land.
> > >
> >
>

Re: [android] How to remove the automatic default of

[Tommy-Carlos Williams]

Absolutely agree.

+1 for * as default, but just as importantly, +1 for never having to hax inside 
./platforms/**/* for this stuff.

We are already forced to use hooks to enforce ./platforms as a build artefact. 
Any progress towards the great goal of being able to safely .gitignore the 
platforms make me feel warm and fuzzy. ;)



On 4 Dec 2013, at 7:09 am, Michal Mocny  wrote:

> Tommy, absolutely the default should remain *, as I said.
> 
> But I hope we can agree that it should also be possible to override the
> default without requiring hacks.  iOS already supports this, so its a
> matter of feature parity.
> 
> -Michal
> 
> 
> On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams  wrote:
> 
>> Please don't go back to when every new dev had to struggle with the Google
>> group or irc to find out why their ajax requests didn't work.
>> 
>> There was a hge discussion at the time that we chose to default to *
>> On 04/12/2013 6:03 am, "Michal Mocny"  wrote:
>> 
>>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson >>> wrote:
>>> 
 There are two different files here: one is defaults.xml, which the CLI
 takes as the basis for its platform config.xml. The other is the
>>> config.xml
 that you get after running bin/create. In the CLI world, that second
>> file
 is immediately overwritten by one created from defaults.xml, the
>>> top-level
 app config.xml, etc.
 
>>> 
>>> Okay, thats what I thought we were doing, but I cannot find where/how the
>>> defaults.xml is created in the first place.  I see now that it does exist
>>> in my CLI projects, but seems not to exist inside our platforms nor CLI,
>>> nor can I find the code that generates it.
>>> 
>>> 
 
 I support the second point of removing the  from
>> the
 CLI's hello world template app; it should be turned into a comment.
 
>>> 
>>> Seems this is redundant anyway given that the platforms provide this as a
>>> default.  Regarding leaving it in as a comment: should we embed the full
>>> spec as a comment?  If not, I would just leave a general description and
>>> link to the spec docs online.
>>> 
>>> 
 I don't think we should be including  by default
 anywhere, unless we really do want to disable the whitelist on that
 platform. And if we do want to disable it, why not in the native code
 instead of allowing everything by default?
 
>>> 
>>> I remember about a year ago we had a bunch of talks regarding the default
>>> whitelist, and decided that almost every developer doesn't want to use a
>>> whitelist and wants every request to be allowed by default.  For those
>> few
>>> devs that want this (false?) sense of security they can learn how to
>>> opt-in, instead of having the same question on the user lists over and
>> over
>>> about how to opt-out.
>>> 
>>> Changing the platforms to allow * by default is an interesting idea, but
>> I
>>> would rather see a solution that doesn't need that change.  Plus its a
>> bit
>>> less semantic/declarative aka more magical/surprising.
>>> 
>>> 
 
 Braden
 
 
 On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny 
>> wrote:
 
> On ios, the default config.xml file (aka the platform defaults) is
 bundled
> as part of the ios project template, and the project template is easy
>>> to
> override using flags to create script / CLI config options.  Easy,
>>> great.
> 
> For android, the default config.xml file is bundled with the platform
> framework itself and not as part of the project template.  I assume
>>> this
 is
> not easy to fix, otherwise we would have made the change already?
> 
> Since the  tag is additive (i.e. cannot just override it by
> appending), there is no way to remove that default without reaching
>> in
 and
> editing cordova-android/framework/res/xml/config.xml file directly
 (either
> with a custom post-platform-add hook to run sed, or by forking
> cordova-android to change the default, both shitty options imho).
> 
> Any suggestions on how to fix this?
> 
> I was hoping to propose that we move the tag out of all the platform
> templates and instead add it to the hello-world app template -- but I
 think
> that won't work well with the platform-scripts workflow since that
>> flow
> doesn't use an application level config.xml at all right now.
> 
> 
> Second, related issue: cordova-cli bundles a default application
 config.xml
> file, which also includes .  I think this is just
> unnecessary and should be removed.
> 
> 
> -Michal
> 
> p.s. as an aside, I thought we were moving the default platform
 config.xml
> out into a file called "defaults.xml"?  It seems only the good folks
>> at
> blackberry have done that so far..
> 
 
>>> 
>> 

Re: [android] How to remove the automatic default of

[Michal Mocny]

Tommy, absolutely the default should remain *, as I said.

But I hope we can agree that it should also be possible to override the
default without requiring hacks.  iOS already supports this, so its a
matter of feature parity.

-Michal


On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams  wrote:

> Please don't go back to when every new dev had to struggle with the Google
> group or irc to find out why their ajax requests didn't work.
>
> There was a hge discussion at the time that we chose to default to *
> On 04/12/2013 6:03 am, "Michal Mocny"  wrote:
>
> > On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson  > >wrote:
> >
> > > There are two different files here: one is defaults.xml, which the CLI
> > > takes as the basis for its platform config.xml. The other is the
> > config.xml
> > > that you get after running bin/create. In the CLI world, that second
> file
> > > is immediately overwritten by one created from defaults.xml, the
> > top-level
> > > app config.xml, etc.
> > >
> >
> > Okay, thats what I thought we were doing, but I cannot find where/how the
> > defaults.xml is created in the first place.  I see now that it does exist
> > in my CLI projects, but seems not to exist inside our platforms nor CLI,
> > nor can I find the code that generates it.
> >
> >
> > >
> > > I support the second point of removing the  from
> the
> > > CLI's hello world template app; it should be turned into a comment.
> > >
> >
> > Seems this is redundant anyway given that the platforms provide this as a
> > default.  Regarding leaving it in as a comment: should we embed the full
> > spec as a comment?  If not, I would just leave a general description and
> > link to the spec docs online.
> >
> >
> > > I don't think we should be including  by default
> > > anywhere, unless we really do want to disable the whitelist on that
> > > platform. And if we do want to disable it, why not in the native code
> > > instead of allowing everything by default?
> > >
> >
> > I remember about a year ago we had a bunch of talks regarding the default
> > whitelist, and decided that almost every developer doesn't want to use a
> > whitelist and wants every request to be allowed by default.  For those
> few
> > devs that want this (false?) sense of security they can learn how to
> > opt-in, instead of having the same question on the user lists over and
> over
> > about how to opt-out.
> >
> > Changing the platforms to allow * by default is an interesting idea, but
> I
> > would rather see a solution that doesn't need that change.  Plus its a
> bit
> > less semantic/declarative aka more magical/surprising.
> >
> >
> > >
> > > Braden
> > >
> > >
> > > On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny 
> wrote:
> > >
> > > > On ios, the default config.xml file (aka the platform defaults) is
> > > bundled
> > > > as part of the ios project template, and the project template is easy
> > to
> > > > override using flags to create script / CLI config options.  Easy,
> > great.
> > > >
> > > > For android, the default config.xml file is bundled with the platform
> > > > framework itself and not as part of the project template.  I assume
> > this
> > > is
> > > > not easy to fix, otherwise we would have made the change already?
> > > >
> > > > Since the  tag is additive (i.e. cannot just override it by
> > > > appending), there is no way to remove that default without reaching
> in
> > > and
> > > > editing cordova-android/framework/res/xml/config.xml file directly
> > > (either
> > > > with a custom post-platform-add hook to run sed, or by forking
> > > > cordova-android to change the default, both shitty options imho).
> > > >
> > > > Any suggestions on how to fix this?
> > > >
> > > > I was hoping to propose that we move the tag out of all the platform
> > > > templates and instead add it to the hello-world app template -- but I
> > > think
> > > > that won't work well with the platform-scripts workflow since that
> flow
> > > > doesn't use an application level config.xml at all right now.
> > > >
> > > >
> > > > Second, related issue: cordova-cli bundles a default application
> > > config.xml
> > > > file, which also includes .  I think this is just
> > > > unnecessary and should be removed.
> > > >
> > > >
> > > > -Michal
> > > >
> > > > p.s. as an aside, I thought we were moving the default platform
> > > config.xml
> > > > out into a file called "defaults.xml"?  It seems only the good folks
> at
> > > > blackberry have done that so far..
> > > >
> > >
> >
>

Re: Plugins Release today

[Steven Gill]

Thanks for filling me in on the state!

Is it just File that isn't ready? File-transfer is good?

I don't think it is worth it to rip out the code from dev, especially if it
is almost ready. I will hold off releasing file with this plugins release.
We can aim to get a new version of file out next week after it has been
tested (especially with plugins that depend on it). Of course, if you
strongly feel some of those other commits on file should get out asap, then
lets move forward with ripping out so it can be released.

In the future we should all try to work off branches and push code onto dev
that is ready to be pushed to master. We should use dev as master since our
master branch is just for releasing. Still confusing at times. It will be
nice once we can get away from this dev-master setup we have. I'm sure many
of us have pushed code to dev that isn't in a sate to be released. Maybe
this point/process should get added to our wiki? Not sure where the best
place for it would be.




On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland  wrote:

> Hey Steven,
>
> File is close to being ready, but I haven't merged in my Android code yet,
> and I want to add some more tests, given how critical the plugin is. I'm
> not comfortable with it going to master yet. If you want, I can pull it out
> of dev and put it on another branch. (There have been some other commits,
> so we could also create a new branch without those commits, and merge
> *that* into master instead)
>
> Let me know how you want to handle it, I'll help out any way I can.
>
> Ian
>
>
> On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill 
> wrote:
>
> > Any plugin issues I should know about before releasing today?
> >
> > Last I heard file and file-transfer dev branches aren't ready to be
> merged
> > into master. Has this changed? Ian?
> >
> > Plugin issues that are still being reviewed/worked on:
> > https://issues.apache.org/jira/browse/CB-5525
> > https://issues.apache.org/jira/browse/CB-5531
> > https://issues.apache.org/jira/browse/CB-5532
> > https://issues.apache.org/jira/browse/CB-5430
> > https://issues.apache.org/jira/browse/CB-5504
> > https://issues.apache.org/jira/browse/CB-5505
> >
> > I can wait until later in the day to release if some of these are getting
> > resolve today. I know Jesse is looking at the windows ones.
> >
> > We can also just do another plugin release next week (or post holidays)
> > once some of these land.
> >
>

Re: [Android] InAppBrowser UI changes and Resources

[Shazron]

Moving it out of src is no problem for iOS, if we need to be consistent for
all the platforms.

e.g.
https://github.com/apache/cordova-plugin-media-capture/tree/master/src/ios/CDVCapture.bundle


On Tue, Dec 3, 2013 at 11:42 AM, Steven Gill  wrote:

> I think it looks good!
>
> I noticed that you created a top level res folder in the plugin to store
> your resources. This rises the question about where should resources live
> within a plugin.
>
> Two options I see are:
> 1) Create the res folder with platform folders within to store resources.
> (this is what joe is doing in the repo above)
> 2) Keep resources in src/platform (I believe iOS bundles resources in
> .bundle which is stored in src/ios for certain plugins)
>
> Thoughts on which one makes the sense?
>
>
> On Tue, Dec 3, 2013 at 10:57 AM, Joe Bowser  wrote:
>
> > Oh crap, here's my GitHub fork of what I did:
> > https://github.com/infil00p/cordova-plugin-inappbrowser/tree/drawables
> >
> >
> >
> > On Tue, Dec 3, 2013 at 10:57 AM, Joe Bowser  wrote:
> > > Hey
> > >
> > > I just did some hacking on the InAppBrowser UI, and I've added the
> > > ability to add drawables.  I've used the Android drawables, which I
> > > believe to have an acceptable licence and now we have something
> > > resembling a real Android UI.  I think there will probably need to be
> > > some more tweaking to get the icons to look right, but I think this
> > > looks a LOT better than what we had previously.
> > >
> > > I also wanted to discuss using the source tag to transport assets in
> > > plugins.  It seems to work fine, but I'm wondering if anyone had any
> > > strong opinions about what I did here before I push this fix up to the
> > > InAppBrowser.
> > >
> > > Joe
> >
>

Re: [android] How to remove the automatic default of

[Tommy Williams]

Please don't go back to when every new dev had to struggle with the Google
group or irc to find out why their ajax requests didn't work.

There was a hge discussion at the time that we chose to default to *
On 04/12/2013 6:03 am, "Michal Mocny"  wrote:

> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson  >wrote:
>
> > There are two different files here: one is defaults.xml, which the CLI
> > takes as the basis for its platform config.xml. The other is the
> config.xml
> > that you get after running bin/create. In the CLI world, that second file
> > is immediately overwritten by one created from defaults.xml, the
> top-level
> > app config.xml, etc.
> >
>
> Okay, thats what I thought we were doing, but I cannot find where/how the
> defaults.xml is created in the first place.  I see now that it does exist
> in my CLI projects, but seems not to exist inside our platforms nor CLI,
> nor can I find the code that generates it.
>
>
> >
> > I support the second point of removing the  from the
> > CLI's hello world template app; it should be turned into a comment.
> >
>
> Seems this is redundant anyway given that the platforms provide this as a
> default.  Regarding leaving it in as a comment: should we embed the full
> spec as a comment?  If not, I would just leave a general description and
> link to the spec docs online.
>
>
> > I don't think we should be including  by default
> > anywhere, unless we really do want to disable the whitelist on that
> > platform. And if we do want to disable it, why not in the native code
> > instead of allowing everything by default?
> >
>
> I remember about a year ago we had a bunch of talks regarding the default
> whitelist, and decided that almost every developer doesn't want to use a
> whitelist and wants every request to be allowed by default.  For those few
> devs that want this (false?) sense of security they can learn how to
> opt-in, instead of having the same question on the user lists over and over
> about how to opt-out.
>
> Changing the platforms to allow * by default is an interesting idea, but I
> would rather see a solution that doesn't need that change.  Plus its a bit
> less semantic/declarative aka more magical/surprising.
>
>
> >
> > Braden
> >
> >
> > On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny  wrote:
> >
> > > On ios, the default config.xml file (aka the platform defaults) is
> > bundled
> > > as part of the ios project template, and the project template is easy
> to
> > > override using flags to create script / CLI config options.  Easy,
> great.
> > >
> > > For android, the default config.xml file is bundled with the platform
> > > framework itself and not as part of the project template.  I assume
> this
> > is
> > > not easy to fix, otherwise we would have made the change already?
> > >
> > > Since the  tag is additive (i.e. cannot just override it by
> > > appending), there is no way to remove that default without reaching in
> > and
> > > editing cordova-android/framework/res/xml/config.xml file directly
> > (either
> > > with a custom post-platform-add hook to run sed, or by forking
> > > cordova-android to change the default, both shitty options imho).
> > >
> > > Any suggestions on how to fix this?
> > >
> > > I was hoping to propose that we move the tag out of all the platform
> > > templates and instead add it to the hello-world app template -- but I
> > think
> > > that won't work well with the platform-scripts workflow since that flow
> > > doesn't use an application level config.xml at all right now.
> > >
> > >
> > > Second, related issue: cordova-cli bundles a default application
> > config.xml
> > > file, which also includes .  I think this is just
> > > unnecessary and should be removed.
> > >
> > >
> > > -Michal
> > >
> > > p.s. as an aside, I thought we were moving the default platform
> > config.xml
> > > out into a file called "defaults.xml"?  It seems only the good folks at
> > > blackberry have done that so far..
> > >
> >
>

Re: country differences in device OS usage

[Steven Gill]

Thanks for sharing. What are people in india using?


On Tue, Dec 3, 2013 at 10:20 AM, Michal Mocny  wrote:

> Hey these are very interesting stats, thanks for summarizing them Marcel.
>
>
> On Tue, Dec 3, 2013 at 11:54 AM, Marcel Kinard  wrote:
>
> > I stumbled into gs.statcounter.com, and poked at the mobile os data
> > there. It really hit me how there is tremendous variation of device OS
> > market share from country to country.
> >
> > Here are some samples.
> >
> > Range extremes:
> > • iOS: 68% in Denmark, 1% in India
> > • Android: 91% in South Korea, 6% in Somalia
> > • Blackberry: 39% in St Martin, 1% in Thailand
> > • Windows Phone: 23% in Finland, 1% in India
> > • Series 40: 60% in Liberia, 1% in Austria
> > • Symbian: 36% in Oman, 1% in Columbia
> >
> > Basically no iOS or Android:
> > • South Africa: Blackberry and Series 40 (Nokia) lead with a
> > combined 60%, iOS has 3%
> >
> > Two western European countries where Android and iOS distribution is
> > flip-flopped:
> > • Spain: 70% Android, 25% iOS
> > • Sweden: 62% iOS, 35% Android
> >
> > Not the usual presence from a North American perspective:
> > • Pakistan: 39% Series 40, 17% Symbian
> >
> > FYI.
> >
> >
>

Re: 3.3.0?

[Steven Gill]

I will look at tagging cordova-js, mobile-spec and hello world this
afternoon if we don't have any objections.


On Tue, Dec 3, 2013 at 11:02 AM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> Hey Jesse, please add me to the review/merge queue. I'm working on WP8/W8
> api fixes as per mobile spec tests, already sent the following pull
> requests; will have more fixes tomorrow
>
> https://issues.apache.org/jira/browse/CB-5525
> https://github.com/apache/cordova-plugin-contacts/pull/14
>
> https://issues.apache.org/jira/browse/CB-5531
> https://github.com/apache/cordova-plugin-file/pull/14
>
> https://issues.apache.org/jira/browse/CB-5532
> https://github.com/apache/cordova-plugin-file/pull/15
>
> Thx!
> Sergey
> -Original Message-
> From: Jesse [mailto:purplecabb...@gmail.com]
> Sent: Tuesday, December 3, 2013 10:57 PM
> To: dev@cordova.apache.org
> Subject: Re: 3.3.0?
>
> Yes, Dick, I'll get your pull request in today.
> I need to today ( or at least a couple hours ) to sort out any other
> additions/changes I might need to cordova-js.
> Anyone else?
>
> Cheers,
>   Jesse
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Dec 3, 2013 at 10:11 AM, Dick Van den Brink <
> d_vandenbr...@outlook.com> wrote:
>
> > Would be nice to see  a release so a +1.
> >
> > Any change my pull request (on github) for pre_package hook on windows
> > 8 can be merged before this release? (Or at least gets some feedback
> > so I can
> > improve?)
> >
> >
> >
> >
> >
> > Verzonden met Windows Mail
> >
> >
> >
> >
> >
> > Van: Joe Bowser
> > Verzonden: dinsdag 3 december 2013 19:11
> > Aan: dev@cordova.apache.org
> >
> >
> >
> >
> >
> > OK, it'd be good if more people chimed in on this thread before we tag
> > the JS.
> >
> > On Mon, Dec 2, 2013 at 3:50 PM, Naik, Archana  wrote:
> > > Yes.. +1 for obvious reasons!!:))
> > >
> > > On 12/2/13 3:44 PM, "Jesse"  wrote:
> > >
> > >>Yes, +1!
> > >>I believe many of us are trying to wrap for the holidays by the 13th.
> > >>Let's aim for an RC later this week.
> > >>
> > >>
> > >>@purplecabbage
> > >>risingj.com
> > >>
> > >>
> > >>On Mon, Dec 2, 2013 at 3:33 PM, Steven Gill 
> > >>wrote:
> > >>
> > >>> Sounds good. We could aim to make that the first release of ubuntu
> > >>>+ fireos  as well!
> > >>>
> > >>> I leave for vacation Dec 13, so I would LOVE if we could test, tag
> > >>>the RC,  test and release final before then!
> > >>>
> > >>>
> > >>> On Mon, Dec 2, 2013 at 3:22 PM, Jesse 
> wrote:
> > >>>
> > >>> > I would like to see a 3.3.0 before the holiday break as well.
> > >>> >
> > >>> >
> > >>> >
> > >>> > @purplecabbage
> > >>> > risingj.com
> > >>> >
> > >>> >
> > >>> > On Mon, Dec 2, 2013 at 3:06 PM, Brian LeRoux  wrote:
> > >>> >
> > >>> > > Yes pls. Even if its just a ceremonial tag on other platforms.
> > >>> > > On Dec 3, 2013 9:56 AM, "Joe Bowser"  wrote:
> > >>> > >
> > >>> > > > Hey
> > >>> > > >
> > >>> > > > Does anyone think we can do a 3.3.0 release sometime before
> > >>> > > > Dec
> > >>>13th?
> > >>> > > > I'd like to have one more release before the end of the year
> > >>> > > > that supports the new KitKat phones and adds the Chrome
> > >>> > > > Remote
> > >>>Debugging.
> > >>> > > >
> > >>> > > > How do other people feel about this?
> > >>> > > >
> > >>> > > > Joe
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> > >
> >
>

Re: [Android] InAppBrowser UI changes and Resources

[Steven Gill]

I think it looks good!

I noticed that you created a top level res folder in the plugin to store
your resources. This rises the question about where should resources live
within a plugin.

Two options I see are:
1) Create the res folder with platform folders within to store resources.
(this is what joe is doing in the repo above)
2) Keep resources in src/platform (I believe iOS bundles resources in
.bundle which is stored in src/ios for certain plugins)

Thoughts on which one makes the sense?


On Tue, Dec 3, 2013 at 10:57 AM, Joe Bowser  wrote:

> Oh crap, here's my GitHub fork of what I did:
> https://github.com/infil00p/cordova-plugin-inappbrowser/tree/drawables
>
>
>
> On Tue, Dec 3, 2013 at 10:57 AM, Joe Bowser  wrote:
> > Hey
> >
> > I just did some hacking on the InAppBrowser UI, and I've added the
> > ability to add drawables.  I've used the Android drawables, which I
> > believe to have an acceptable licence and now we have something
> > resembling a real Android UI.  I think there will probably need to be
> > some more tweaking to get the icons to look right, but I think this
> > looks a LOT better than what we had previously.
> >
> > I also wanted to discuss using the source tag to transport assets in
> > plugins.  It seems to work fine, but I'm wondering if anyone had any
> > strong opinions about what I did here before I push this fix up to the
> > InAppBrowser.
> >
> > Joe
>

Re: Plugins Release today

[Ian Clelland]

Hey Steven,

File is close to being ready, but I haven't merged in my Android code yet,
and I want to add some more tests, given how critical the plugin is. I'm
not comfortable with it going to master yet. If you want, I can pull it out
of dev and put it on another branch. (There have been some other commits,
so we could also create a new branch without those commits, and merge
*that* into master instead)

Let me know how you want to handle it, I'll help out any way I can.

Ian


On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill  wrote:

> Any plugin issues I should know about before releasing today?
>
> Last I heard file and file-transfer dev branches aren't ready to be merged
> into master. Has this changed? Ian?
>
> Plugin issues that are still being reviewed/worked on:
> https://issues.apache.org/jira/browse/CB-5525
> https://issues.apache.org/jira/browse/CB-5531
> https://issues.apache.org/jira/browse/CB-5532
> https://issues.apache.org/jira/browse/CB-5430
> https://issues.apache.org/jira/browse/CB-5504
> https://issues.apache.org/jira/browse/CB-5505
>
> I can wait until later in the day to release if some of these are getting
> resolve today. I know Jesse is looking at the windows ones.
>
> We can also just do another plugin release next week (or post holidays)
> once some of these land.
>

Plugins Release today

[Steven Gill]

Any plugin issues I should know about before releasing today?

Last I heard file and file-transfer dev branches aren't ready to be merged
into master. Has this changed? Ian?

Plugin issues that are still being reviewed/worked on:
https://issues.apache.org/jira/browse/CB-5525
https://issues.apache.org/jira/browse/CB-5531
https://issues.apache.org/jira/browse/CB-5532
https://issues.apache.org/jira/browse/CB-5430
https://issues.apache.org/jira/browse/CB-5504
https://issues.apache.org/jira/browse/CB-5505

I can wait until later in the day to release if some of these are getting
resolve today. I know Jesse is looking at the windows ones.

We can also just do another plugin release next week (or post holidays)
once some of these land.

Re: PluginEntry.java crash in getClassByName

[Joe Bowser]

Can you please create an issue so that this is tracked?

On Tue, Dec 3, 2013 at 11:02 AM,   wrote:
> Hi,
>
> I don't know why or since when but getClassByName is called with an argument
> of "" (not null).
>
> The method getClassByName checks for null but not for "" and so it crashes.
>
> This happens for the service http://api.phonegap.com/1.0/device
>
> I am using cordova-3.1.0-0.2.0
>
> A screenshot of the debugging window is attached.
>
> A simple fix seems to be to never set this.pluginClass in PluginEntry.java
> to "" but to null. PluginManager.java contains the assignment: pluginClass =
> ""
>
>
>
> -Axel
>
>

PluginEntry.java crash in getClassByName

[Axel.Nennker]

Hi,
I don't know why or since when but getClassByName is called with an argument of 
"" (not null).
The method getClassByName checks for null but not for "" and so it crashes.
This happens for the service http://api.phonegap.com/1.0/device
I am using cordova-3.1.0-0.2.0
A screenshot of the debugging window is attached.
A simple fix seems to be to never set this.pluginClass in PluginEntry.java to 
"" but to null. PluginManager.java contains the assignment: pluginClass = ""

-Axel

Re: [android] How to remove the automatic default of

[Michal Mocny]

On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson wrote:

> There are two different files here: one is defaults.xml, which the CLI
> takes as the basis for its platform config.xml. The other is the config.xml
> that you get after running bin/create. In the CLI world, that second file
> is immediately overwritten by one created from defaults.xml, the top-level
> app config.xml, etc.
>

Okay, thats what I thought we were doing, but I cannot find where/how the
defaults.xml is created in the first place.  I see now that it does exist
in my CLI projects, but seems not to exist inside our platforms nor CLI,
nor can I find the code that generates it.


>
> I support the second point of removing the  from the
> CLI's hello world template app; it should be turned into a comment.
>

Seems this is redundant anyway given that the platforms provide this as a
default.  Regarding leaving it in as a comment: should we embed the full
spec as a comment?  If not, I would just leave a general description and
link to the spec docs online.


> I don't think we should be including  by default
> anywhere, unless we really do want to disable the whitelist on that
> platform. And if we do want to disable it, why not in the native code
> instead of allowing everything by default?
>

I remember about a year ago we had a bunch of talks regarding the default
whitelist, and decided that almost every developer doesn't want to use a
whitelist and wants every request to be allowed by default.  For those few
devs that want this (false?) sense of security they can learn how to
opt-in, instead of having the same question on the user lists over and over
about how to opt-out.

Changing the platforms to allow * by default is an interesting idea, but I
would rather see a solution that doesn't need that change.  Plus its a bit
less semantic/declarative aka more magical/surprising.


>
> Braden
>
>
> On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny  wrote:
>
> > On ios, the default config.xml file (aka the platform defaults) is
> bundled
> > as part of the ios project template, and the project template is easy to
> > override using flags to create script / CLI config options.  Easy, great.
> >
> > For android, the default config.xml file is bundled with the platform
> > framework itself and not as part of the project template.  I assume this
> is
> > not easy to fix, otherwise we would have made the change already?
> >
> > Since the  tag is additive (i.e. cannot just override it by
> > appending), there is no way to remove that default without reaching in
> and
> > editing cordova-android/framework/res/xml/config.xml file directly
> (either
> > with a custom post-platform-add hook to run sed, or by forking
> > cordova-android to change the default, both shitty options imho).
> >
> > Any suggestions on how to fix this?
> >
> > I was hoping to propose that we move the tag out of all the platform
> > templates and instead add it to the hello-world app template -- but I
> think
> > that won't work well with the platform-scripts workflow since that flow
> > doesn't use an application level config.xml at all right now.
> >
> >
> > Second, related issue: cordova-cli bundles a default application
> config.xml
> > file, which also includes .  I think this is just
> > unnecessary and should be removed.
> >
> >
> > -Michal
> >
> > p.s. as an aside, I thought we were moving the default platform
> config.xml
> > out into a file called "defaults.xml"?  It seems only the good folks at
> > blackberry have done that so far..
> >
>

RE: 3.3.0?

[Sergey Grebnov (Akvelon)]

Hey Jesse, please add me to the review/merge queue. I'm working on WP8/W8 api 
fixes as per mobile spec tests, already sent the following pull requests; will 
have more fixes tomorrow

https://issues.apache.org/jira/browse/CB-5525
https://github.com/apache/cordova-plugin-contacts/pull/14

https://issues.apache.org/jira/browse/CB-5531
https://github.com/apache/cordova-plugin-file/pull/14

https://issues.apache.org/jira/browse/CB-5532
https://github.com/apache/cordova-plugin-file/pull/15

Thx!
Sergey
-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com] 
Sent: Tuesday, December 3, 2013 10:57 PM
To: dev@cordova.apache.org
Subject: Re: 3.3.0?

Yes, Dick, I'll get your pull request in today.
I need to today ( or at least a couple hours ) to sort out any other 
additions/changes I might need to cordova-js.
Anyone else?

Cheers,
  Jesse


@purplecabbage
risingj.com


On Tue, Dec 3, 2013 at 10:11 AM, Dick Van den Brink < 
d_vandenbr...@outlook.com> wrote:

> Would be nice to see  a release so a +1.
>
> Any change my pull request (on github) for pre_package hook on windows 
> 8 can be merged before this release? (Or at least gets some feedback 
> so I can
> improve?)
>
>
>
>
>
> Verzonden met Windows Mail
>
>
>
>
>
> Van: Joe Bowser
> Verzonden: dinsdag 3 december 2013 19:11
> Aan: dev@cordova.apache.org
>
>
>
>
>
> OK, it'd be good if more people chimed in on this thread before we tag 
> the JS.
>
> On Mon, Dec 2, 2013 at 3:50 PM, Naik, Archana  wrote:
> > Yes.. +1 for obvious reasons!!:))
> >
> > On 12/2/13 3:44 PM, "Jesse"  wrote:
> >
> >>Yes, +1!
> >>I believe many of us are trying to wrap for the holidays by the 13th.
> >>Let's aim for an RC later this week.
> >>
> >>
> >>@purplecabbage
> >>risingj.com
> >>
> >>
> >>On Mon, Dec 2, 2013 at 3:33 PM, Steven Gill 
> >>wrote:
> >>
> >>> Sounds good. We could aim to make that the first release of ubuntu 
> >>>+ fireos  as well!
> >>>
> >>> I leave for vacation Dec 13, so I would LOVE if we could test, tag 
> >>>the RC,  test and release final before then!
> >>>
> >>>
> >>> On Mon, Dec 2, 2013 at 3:22 PM, Jesse  wrote:
> >>>
> >>> > I would like to see a 3.3.0 before the holiday break as well.
> >>> >
> >>> >
> >>> >
> >>> > @purplecabbage
> >>> > risingj.com
> >>> >
> >>> >
> >>> > On Mon, Dec 2, 2013 at 3:06 PM, Brian LeRoux  wrote:
> >>> >
> >>> > > Yes pls. Even if its just a ceremonial tag on other platforms.
> >>> > > On Dec 3, 2013 9:56 AM, "Joe Bowser"  wrote:
> >>> > >
> >>> > > > Hey
> >>> > > >
> >>> > > > Does anyone think we can do a 3.3.0 release sometime before 
> >>> > > > Dec
> >>>13th?
> >>> > > > I'd like to have one more release before the end of the year 
> >>> > > > that supports the new KitKat phones and adds the Chrome 
> >>> > > > Remote
> >>>Debugging.
> >>> > > >
> >>> > > > How do other people feel about this?
> >>> > > >
> >>> > > > Joe
> >>> > > >
> >>> > >
> >>> >
> >>>
> >
>

Re: 3.3.0?

[Joe Bowser]

I'm fine with Cordova-JS.  None of my changes affect the JS API.

On Tue, Dec 3, 2013 at 10:56 AM, Jesse  wrote:
> Yes, Dick, I'll get your pull request in today.
> I need to today ( or at least a couple hours ) to sort out any other
> additions/changes I might need to cordova-js.
> Anyone else?
>
> Cheers,
>   Jesse
>
>
> @purplecabbage
> risingj.com
>
>
> On Tue, Dec 3, 2013 at 10:11 AM, Dick Van den Brink <
> d_vandenbr...@outlook.com> wrote:
>
>> Would be nice to see  a release so a +1.
>>
>> Any change my pull request (on github) for pre_package hook on windows 8
>> can be merged before this release? (Or at least gets some feedback so I can
>> improve?)
>>
>>
>>
>>
>>
>> Verzonden met Windows Mail
>>
>>
>>
>>
>>
>> Van: Joe Bowser
>> Verzonden: dinsdag 3 december 2013 19:11
>> Aan: dev@cordova.apache.org
>>
>>
>>
>>
>>
>> OK, it'd be good if more people chimed in on this thread before we tag the
>> JS.
>>
>> On Mon, Dec 2, 2013 at 3:50 PM, Naik, Archana  wrote:
>> > Yes.. +1 for obvious reasons!!:))
>> >
>> > On 12/2/13 3:44 PM, "Jesse"  wrote:
>> >
>> >>Yes, +1!
>> >>I believe many of us are trying to wrap for the holidays by the 13th.
>> >>Let's aim for an RC later this week.
>> >>
>> >>
>> >>@purplecabbage
>> >>risingj.com
>> >>
>> >>
>> >>On Mon, Dec 2, 2013 at 3:33 PM, Steven Gill 
>> >>wrote:
>> >>
>> >>> Sounds good. We could aim to make that the first release of ubuntu +
>> >>>fireos
>> >>> as well!
>> >>>
>> >>> I leave for vacation Dec 13, so I would LOVE if we could test, tag the
>> >>>RC,
>> >>> test and release final before then!
>> >>>
>> >>>
>> >>> On Mon, Dec 2, 2013 at 3:22 PM, Jesse  wrote:
>> >>>
>> >>> > I would like to see a 3.3.0 before the holiday break as well.
>> >>> >
>> >>> >
>> >>> >
>> >>> > @purplecabbage
>> >>> > risingj.com
>> >>> >
>> >>> >
>> >>> > On Mon, Dec 2, 2013 at 3:06 PM, Brian LeRoux  wrote:
>> >>> >
>> >>> > > Yes pls. Even if its just a ceremonial tag on other platforms.
>> >>> > > On Dec 3, 2013 9:56 AM, "Joe Bowser"  wrote:
>> >>> > >
>> >>> > > > Hey
>> >>> > > >
>> >>> > > > Does anyone think we can do a 3.3.0 release sometime before Dec
>> >>>13th?
>> >>> > > > I'd like to have one more release before the end of the year that
>> >>> > > > supports the new KitKat phones and adds the Chrome Remote
>> >>>Debugging.
>> >>> > > >
>> >>> > > > How do other people feel about this?
>> >>> > > >
>> >>> > > > Joe
>> >>> > > >
>> >>> > >
>> >>> >
>> >>>
>> >
>>

Re: [Android] InAppBrowser UI changes and Resources

[Joe Bowser]

Oh crap, here's my GitHub fork of what I did:
https://github.com/infil00p/cordova-plugin-inappbrowser/tree/drawables



On Tue, Dec 3, 2013 at 10:57 AM, Joe Bowser  wrote:
> Hey
>
> I just did some hacking on the InAppBrowser UI, and I've added the
> ability to add drawables.  I've used the Android drawables, which I
> believe to have an acceptable licence and now we have something
> resembling a real Android UI.  I think there will probably need to be
> some more tweaking to get the icons to look right, but I think this
> looks a LOT better than what we had previously.
>
> I also wanted to discuss using the source tag to transport assets in
> plugins.  It seems to work fine, but I'm wondering if anyone had any
> strong opinions about what I did here before I push this fix up to the
> InAppBrowser.
>
> Joe

[Android] InAppBrowser UI changes and Resources

[Joe Bowser]

Hey

I just did some hacking on the InAppBrowser UI, and I've added the
ability to add drawables.  I've used the Android drawables, which I
believe to have an acceptable licence and now we have something
resembling a real Android UI.  I think there will probably need to be
some more tweaking to get the icons to look right, but I think this
looks a LOT better than what we had previously.

I also wanted to discuss using the source tag to transport assets in
plugins.  It seems to work fine, but I'm wondering if anyone had any
strong opinions about what I did here before I push this fix up to the
InAppBrowser.

Joe

Re: 3.3.0?

[Jesse]

Yes, Dick, I'll get your pull request in today.
I need to today ( or at least a couple hours ) to sort out any other
additions/changes I might need to cordova-js.
Anyone else?

Cheers,
  Jesse


@purplecabbage
risingj.com


On Tue, Dec 3, 2013 at 10:11 AM, Dick Van den Brink <
d_vandenbr...@outlook.com> wrote:

> Would be nice to see  a release so a +1.
>
> Any change my pull request (on github) for pre_package hook on windows 8
> can be merged before this release? (Or at least gets some feedback so I can
> improve?)
>
>
>
>
>
> Verzonden met Windows Mail
>
>
>
>
>
> Van: Joe Bowser
> Verzonden: dinsdag 3 december 2013 19:11
> Aan: dev@cordova.apache.org
>
>
>
>
>
> OK, it'd be good if more people chimed in on this thread before we tag the
> JS.
>
> On Mon, Dec 2, 2013 at 3:50 PM, Naik, Archana  wrote:
> > Yes.. +1 for obvious reasons!!:))
> >
> > On 12/2/13 3:44 PM, "Jesse"  wrote:
> >
> >>Yes, +1!
> >>I believe many of us are trying to wrap for the holidays by the 13th.
> >>Let's aim for an RC later this week.
> >>
> >>
> >>@purplecabbage
> >>risingj.com
> >>
> >>
> >>On Mon, Dec 2, 2013 at 3:33 PM, Steven Gill 
> >>wrote:
> >>
> >>> Sounds good. We could aim to make that the first release of ubuntu +
> >>>fireos
> >>> as well!
> >>>
> >>> I leave for vacation Dec 13, so I would LOVE if we could test, tag the
> >>>RC,
> >>> test and release final before then!
> >>>
> >>>
> >>> On Mon, Dec 2, 2013 at 3:22 PM, Jesse  wrote:
> >>>
> >>> > I would like to see a 3.3.0 before the holiday break as well.
> >>> >
> >>> >
> >>> >
> >>> > @purplecabbage
> >>> > risingj.com
> >>> >
> >>> >
> >>> > On Mon, Dec 2, 2013 at 3:06 PM, Brian LeRoux  wrote:
> >>> >
> >>> > > Yes pls. Even if its just a ceremonial tag on other platforms.
> >>> > > On Dec 3, 2013 9:56 AM, "Joe Bowser"  wrote:
> >>> > >
> >>> > > > Hey
> >>> > > >
> >>> > > > Does anyone think we can do a 3.3.0 release sometime before Dec
> >>>13th?
> >>> > > > I'd like to have one more release before the end of the year that
> >>> > > > supports the new KitKat phones and adds the Chrome Remote
> >>>Debugging.
> >>> > > >
> >>> > > > How do other people feel about this?
> >>> > > >
> >>> > > > Joe
> >>> > > >
> >>> > >
> >>> >
> >>>
> >
>

Re: [android] How to remove the automatic default of

[Braden Shepherdson]

There are two different files here: one is defaults.xml, which the CLI
takes as the basis for its platform config.xml. The other is the config.xml
that you get after running bin/create. In the CLI world, that second file
is immediately overwritten by one created from defaults.xml, the top-level
app config.xml, etc.

I support the second point of removing the  from the
CLI's hello world template app; it should be turned into a comment.

I don't think we should be including  by default
anywhere, unless we really do want to disable the whitelist on that
platform. And if we do want to disable it, why not in the native code
instead of allowing everything by default?

Braden


On Tue, Dec 3, 2013 at 8:04 AM, Michal Mocny  wrote:

> On ios, the default config.xml file (aka the platform defaults) is bundled
> as part of the ios project template, and the project template is easy to
> override using flags to create script / CLI config options.  Easy, great.
>
> For android, the default config.xml file is bundled with the platform
> framework itself and not as part of the project template.  I assume this is
> not easy to fix, otherwise we would have made the change already?
>
> Since the  tag is additive (i.e. cannot just override it by
> appending), there is no way to remove that default without reaching in and
> editing cordova-android/framework/res/xml/config.xml file directly (either
> with a custom post-platform-add hook to run sed, or by forking
> cordova-android to change the default, both shitty options imho).
>
> Any suggestions on how to fix this?
>
> I was hoping to propose that we move the tag out of all the platform
> templates and instead add it to the hello-world app template -- but I think
> that won't work well with the platform-scripts workflow since that flow
> doesn't use an application level config.xml at all right now.
>
>
> Second, related issue: cordova-cli bundles a default application config.xml
> file, which also includes .  I think this is just
> unnecessary and should be removed.
>
>
> -Michal
>
> p.s. as an aside, I thought we were moving the default platform config.xml
> out into a file called "defaults.xml"?  It seems only the good folks at
> blackberry have done that so far..
>

Re: country differences in device OS usage

[Michal Mocny]

Hey these are very interesting stats, thanks for summarizing them Marcel.


On Tue, Dec 3, 2013 at 11:54 AM, Marcel Kinard  wrote:

> I stumbled into gs.statcounter.com, and poked at the mobile os data
> there. It really hit me how there is tremendous variation of device OS
> market share from country to country.
>
> Here are some samples.
>
> Range extremes:
> • iOS: 68% in Denmark, 1% in India
> • Android: 91% in South Korea, 6% in Somalia
> • Blackberry: 39% in St Martin, 1% in Thailand
> • Windows Phone: 23% in Finland, 1% in India
> • Series 40: 60% in Liberia, 1% in Austria
> • Symbian: 36% in Oman, 1% in Columbia
>
> Basically no iOS or Android:
> • South Africa: Blackberry and Series 40 (Nokia) lead with a
> combined 60%, iOS has 3%
>
> Two western European countries where Android and iOS distribution is
> flip-flopped:
> • Spain: 70% Android, 25% iOS
> • Sweden: 62% iOS, 35% Android
>
> Not the usual presence from a North American perspective:
> • Pakistan: 39% Series 40, 17% Symbian
>
> FYI.
>
>

Re: 3.3.0?

[Dick Van den Brink]

Would be nice to see  a release so a +1.

Any change my pull request (on github) for pre_package hook on windows 8 can be 
merged before this release? (Or at least gets some feedback so I can improve?)





Verzonden met Windows Mail





Van: Joe Bowser
Verzonden: ‎dinsdag‎ ‎3‎ ‎december‎ ‎2013 ‎19‎:‎11
Aan: dev@cordova.apache.org





OK, it'd be good if more people chimed in on this thread before we tag the JS.

On Mon, Dec 2, 2013 at 3:50 PM, Naik, Archana  wrote:
> Yes.. +1 for obvious reasons!!:))
>
> On 12/2/13 3:44 PM, "Jesse"  wrote:
>
>>Yes, +1!
>>I believe many of us are trying to wrap for the holidays by the 13th.
>>Let's aim for an RC later this week.
>>
>>
>>@purplecabbage
>>risingj.com
>>
>>
>>On Mon, Dec 2, 2013 at 3:33 PM, Steven Gill 
>>wrote:
>>
>>> Sounds good. We could aim to make that the first release of ubuntu +
>>>fireos
>>> as well!
>>>
>>> I leave for vacation Dec 13, so I would LOVE if we could test, tag the
>>>RC,
>>> test and release final before then!
>>>
>>>
>>> On Mon, Dec 2, 2013 at 3:22 PM, Jesse  wrote:
>>>
>>> > I would like to see a 3.3.0 before the holiday break as well.
>>> >
>>> >
>>> >
>>> > @purplecabbage
>>> > risingj.com
>>> >
>>> >
>>> > On Mon, Dec 2, 2013 at 3:06 PM, Brian LeRoux  wrote:
>>> >
>>> > > Yes pls. Even if its just a ceremonial tag on other platforms.
>>> > > On Dec 3, 2013 9:56 AM, "Joe Bowser"  wrote:
>>> > >
>>> > > > Hey
>>> > > >
>>> > > > Does anyone think we can do a 3.3.0 release sometime before Dec
>>>13th?
>>> > > > I'd like to have one more release before the end of the year that
>>> > > > supports the new KitKat phones and adds the Chrome Remote
>>>Debugging.
>>> > > >
>>> > > > How do other people feel about this?
>>> > > >
>>> > > > Joe
>>> > > >
>>> > >
>>> >
>>>
>

country differences in device OS usage

[Marcel Kinard]

I stumbled into gs.statcounter.com, and poked at the mobile os data there. It 
really hit me how there is tremendous variation of device OS market share from 
country to country.

Here are some samples.

Range extremes:
• iOS: 68% in Denmark, 1% in India
• Android: 91% in South Korea, 6% in Somalia
• Blackberry: 39% in St Martin, 1% in Thailand
• Windows Phone: 23% in Finland, 1% in India
• Series 40: 60% in Liberia, 1% in Austria
• Symbian: 36% in Oman, 1% in Columbia

Basically no iOS or Android:
• South Africa: Blackberry and Series 40 (Nokia) lead with a combined 
60%, iOS has 3%

Two western European countries where Android and iOS distribution is 
flip-flopped:
• Spain: 70% Android, 25% iOS
• Sweden: 62% iOS, 35% Android

Not the usual presence from a North American perspective:
• Pakistan: 39% Series 40, 17% Symbian
 
FYI.

Re: JAVA_HOME

[Marcel Kinard]

Yeah. It's really cool what works in Cordova, but it's also embarrasing what 
gets broken. Running real end-to-end (in the generic sense) tests like a real 
consumer in a real app-dev workflow should help us catch the bad parts. I don't 
think we are exercising end-to-end without automated CI.

On Dec 3, 2013, at 1:36 AM, Brian LeRoux  wrote:

> This is really a symptom of how badly we need to get CI running again. The
> hello world workflow being broken is completely unacceptable.

Re: 3.3.0?

[Joe Bowser]

OK, it'd be good if more people chimed in on this thread before we tag the JS.

On Mon, Dec 2, 2013 at 3:50 PM, Naik, Archana  wrote:
> Yes.. +1 for obvious reasons!!:))
>
> On 12/2/13 3:44 PM, "Jesse"  wrote:
>
>>Yes, +1!
>>I believe many of us are trying to wrap for the holidays by the 13th.
>>Let's aim for an RC later this week.
>>
>>
>>@purplecabbage
>>risingj.com
>>
>>
>>On Mon, Dec 2, 2013 at 3:33 PM, Steven Gill 
>>wrote:
>>
>>> Sounds good. We could aim to make that the first release of ubuntu +
>>>fireos
>>> as well!
>>>
>>> I leave for vacation Dec 13, so I would LOVE if we could test, tag the
>>>RC,
>>> test and release final before then!
>>>
>>>
>>> On Mon, Dec 2, 2013 at 3:22 PM, Jesse  wrote:
>>>
>>> > I would like to see a 3.3.0 before the holiday break as well.
>>> >
>>> >
>>> >
>>> > @purplecabbage
>>> > risingj.com
>>> >
>>> >
>>> > On Mon, Dec 2, 2013 at 3:06 PM, Brian LeRoux  wrote:
>>> >
>>> > > Yes pls. Even if its just a ceremonial tag on other platforms.
>>> > > On Dec 3, 2013 9:56 AM, "Joe Bowser"  wrote:
>>> > >
>>> > > > Hey
>>> > > >
>>> > > > Does anyone think we can do a 3.3.0 release sometime before Dec
>>>13th?
>>> > > > I'd like to have one more release before the end of the year that
>>> > > > supports the new KitKat phones and adds the Chrome Remote
>>>Debugging.
>>> > > >
>>> > > > How do other people feel about this?
>>> > > >
>>> > > > Joe
>>> > > >
>>> > >
>>> >
>>>
>

Re: FYI: yo dude, a generator of generators for cordova Apps

[Michael Brooks]

Yo dude, that's rad bro!


On Mon, Dec 2, 2013 at 9:54 PM, Steven Gill  wrote:

> Looks rad Carlos!
>
>
> On Mon, Dec 2, 2013 at 6:01 PM, Tommy Williams  wrote:
>
> > Sad times.. He he.
> >
> > Still sounds awesome.
> > On 03/12/2013 12:59 pm, "Carlos Santana"  wrote:
> >
> > > nice Tommy, name was taken so was 'dude' or 'bro'
> > >
> > >
> > >
> > > On Mon, Dec 2, 2013 at 6:32 PM, Tommy-Carlos Williams <
> > to...@devgeeks.org
> > > >wrote:
> > >
> > > > totally should be `yo dawg`[1]
> > > >
> > > > [1]:
> > > >
> > https://dl.dropboxusercontent.com/u/1456226/photos/yo-dawg-generator.png
> > > >
> > > > On 3 Dec 2013, at 7:07 am, Carlos Santana 
> > wrote:
> > > >
> > > > > Just in case you know someone that might benefit
> > > > >
> > > > > yo dude [1] first it prompts to select a Web App Generator (dapp,
> > > > > mobile(topcoat, foundation,bootstrap), angular, polymer, backbone,
> > > > webapp,
> > > > > etc..).
> > > > >
> > > > > Then runs the the generator-cordovacli prompts for name, id,
> > platforms,
> > > > and
> > > > > plugins for cordova.
> > > > >
> > > > > End result you get a cordova app built with your favorite web
> > > framework.
> > > > >
> > > > > It might be more useful for demos and learning purposes for Apache
> > > > Cordova.
> > > > >
> > > > > [1]: https://npmjs.org/package/generator-dude
> > > > >
> > > > > --
> > > > > Carlos Santana
> > > > > 
> > > >
> > > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > 
> > >
> >
>

Re: Camera targetWidth & targetHeight

[James Jong]

For targetWidth = 2048 , targetHeight=768, does it make sense to have the 
result picture with width=768,height=1024?  That seems odd to me.

-James Jong

On Dec 3, 2013, at 7:34 AM, John M. Wargo  wrote:

> It occurred to me this morning that I didn't test a scenario where an 
> application deliberately didn't maintain an appropriate aspect ratio with 
> targetWidth & targetHeight.
> 
> I added a button to my app that set targetWidth to 2048 and targetHeight to 
> 768.
> 
> On Android I got the following:
> 
> Portrait: 768x1024
> Landscape: 1024x768
> 
> On iOS I got the following:
> 
> Portrait: 576x768
> Landscape: 1024x768
> 
> Not what I expected. So apparently the API grabs the smaller property and 
> applies a set aspect ratio to the resulting photo rather than try to do 
> something weird. Notice again that on iOS the API applies the restriction 
> weirdly in portrait.
> 
> On 12/2/2013 10:18 PM, Simon MacDonald wrote:
>> IIRC on Android if you only specify the width or height it will determine
>> what the other value should be by using the same aspect ration as the
>> original image.
>> 
>> 
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>> 
>> 
>> On Mon, Dec 2, 2013 at 10:15 PM, John M. Wargo  wrote:
>> 
>>> A while back I posted a question regarding Camera targetWidth &
>>> targetHeight properties and how they worked. After some discussion, the
>>> conclusion I reached was that the documentation couldn't be correct about
>>> how it worked since there was no way to determine the camera's resolution
>>> with the current API but the docs said I had to provide both parameters.  I
>>> said I'd do some testing and I have finally gotten around to completing it.
>>> Here's what I discovered:
>>> 
>>> I created an application that allowed me to pass in different values for
>>> targetWidth & targetHeight when taking a picture. I tested at the following
>>> image sizes: 640x480, 800x600, 1024x768 as well as setting only the
>>> targetWidth to 1024 or only the targetHeight to 768.
>>> 
>>> Here's the results:
>>> 
>>> Android
>>> PortraitLandscape
>>> 480x640 640x480
>>> 600x800 800x600
>>> 768x10241024x768
>>> 768x10241024x768
>>> 768x10241024x768
>>> 
>>> 
>>> 
>>> iOS
>>> PortraitLandscape
>>> 360x480 640x480
>>> 450x600 800x600
>>> 576x768 1024x768
>>> 2448x3264   3264x2448
>>> 2448x3264   3264x2448
>>> 
>>> 
>>> 
>>> Windows Phone 8
>>> PortraitLandscape
>>> 1836x3264   3264x1836
>>> 1836x3264   3264x1836
>>> 1836x3264   3264x1836
>>> 1836x3264   3264x1836
>>> 1836x3264   3264x1836
>>> 
>>> 
>>> As you can see, Android properly implements the targetWidth & targetHeight
>>> properties. On iOS, it supports setting both properties, but not instances
>>> where only one is specified. Windows Phone 8 ignores the parameters
>>> completely.  On iOS, when you turn the device on its side, the Camera API
>>> applies the target width or height to the wrong axis (Android does this
>>> well however).
>>> 
>>> I'm trying to test this on a BlackBerry device, but my development
>>> environment is giving me fits right now. I'll work on it in the morning and
>>> publish my results when I get them.
>>> 
>>> I would suggest that the android implementation is as expected and that
>>> the other platforms need their implementations of targetWidth &
>>> targetHeight adjusted so it works correctly. The documentation should be
>>> updated as well as it's incorrect today specifying that both properties
>>> must be provided.
>>> 
>>> If the group doesn't want to support only providing one of the properties,
>>> then I would expect that the onError callback is called when only one is
>>> provided rather than simply ignoring them as is the case with iOS and
>>> Windows Phone.
>>> 
>>> I posted my sample application and a spreadsheet with my results to
>>> https://github.com/johnwargo/camera_res_test
>>> 
>>> --
>>> John M. Wargo
>>> @johnwargo 
>>> www.johnwargo.com 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ---

[android] How to remove the automatic default of

[Michal Mocny]

On ios, the default config.xml file (aka the platform defaults) is bundled
as part of the ios project template, and the project template is easy to
override using flags to create script / CLI config options.  Easy, great.

For android, the default config.xml file is bundled with the platform
framework itself and not as part of the project template.  I assume this is
not easy to fix, otherwise we would have made the change already?

Since the  tag is additive (i.e. cannot just override it by
appending), there is no way to remove that default without reaching in and
editing cordova-android/framework/res/xml/config.xml file directly (either
with a custom post-platform-add hook to run sed, or by forking
cordova-android to change the default, both shitty options imho).

Any suggestions on how to fix this?

I was hoping to propose that we move the tag out of all the platform
templates and instead add it to the hello-world app template -- but I think
that won't work well with the platform-scripts workflow since that flow
doesn't use an application level config.xml at all right now.


Second, related issue: cordova-cli bundles a default application config.xml
file, which also includes .  I think this is just
unnecessary and should be removed.


-Michal

p.s. as an aside, I thought we were moving the default platform config.xml
out into a file called "defaults.xml"?  It seems only the good folks at
blackberry have done that so far..

PluginEntry.java crash in getClassByName

[Axel Nennker]

Hi,

I don't know why or since when but getClassByName is called with an
argument of "" (not null).
The method getClassByName checks for null but not for "" and so it crashes.
This happens for the service http://api.phonegap.com/1.0/device

I am using cordova-3.1.0-0.2.0
A screenshot of the debugging window is attached.

A simple fix seems to be to never set this.pluginClass in PluginEntry.java
to "" but to null. PluginManager.java contains the assignment: pluginClass
= ""

-Axel

Cordova and Crosswalk

[Hu, Ningxin]

Hi Cordova Developers,

Crosswalk [1] is a web application runtime based on Blink and Chromium. It 
supports Android 4.0+. By integrating Cordova with Crosswalk, it brings remote 
debugging capability, better HTML5 support and higher performance to Cordova 
apps.

In Crosswalk projects, there is a crosswalk-cordova-android project [2] to 
prove the idea. It is derived from Cordova Android [3] and embeds Crosswalk as 
the HTML5 runtime instead of WebView. Currently It is based on Cordova 3.0.0 
and supports 16 Cordova APIs. Please check the wiki [4] for more details.

Your thoughts about the integration?
Is it possible to support Crosswalk runtime as a platform in Cordova upstream?

Thanks,
-ningxin

[1]: https://crosswalk-project.org/
[2]: https://github.com/crosswalk-project/crosswalk-cordova-android
[3]: https://github.com/apache/cordova-android
[4]: https://crosswalk-project.org/#wiki/crosswalk-cordova-android

Re: [jira] [Resolved] (INFRA-6422) request linux virtual machine for Apache Cordova project

[David Kemp]

Given that I still do not have an internal machine designated for
buildmaster( maybe soon...) , is there any interest in putting a shared
buildbot master on this too?




On Tue, Dec 3, 2013 at 8:22 AM, Mike Billau  wrote:

> Awesome, looks like JIRA has given us a VM to use to collect all of the CI
> data.
>
> Reply if you want/need access and I can email INFRA with all of our names
> at once.
>
> I can also work on setting up the db this week if nobody else wants to.
>
>
>
> -- Forwarded message --
> From: jan iversen (JIRA) 
> Date: Wed, Nov 27, 2013 at 12:20 PM
> Subject: [jira] [Resolved] (INFRA-6422) request linux virtual machine for
> Apache Cordova project
> To: mike.bil...@gmail.com
>
>
>
>  [
>
> https://issues.apache.org/jira/browse/INFRA-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> ]
>
> jan iversen resolved INFRA-6422.
> 
>
> Resolution: Fixed
>
> Vm is created and secured (ldap puppet etc).
>
> dns: cordova-vm.a.o
>
> At the moment root@ and I have access. Please catch a root@ person on
> #asfnfra, or mail root@a.o o with apacheid to get access.
>
> The project is expected to maintain the vm and keep it updated with
> patches. If needed infra can help with this task.
>
> In case of questions/problems do not hesitate to contact us.
>
> Have fun
> rgds
> jan I.
>
> > request linux virtual machine for Apache Cordova project
> > 
> >
> > Key: INFRA-6422
> > URL: https://issues.apache.org/jira/browse/INFRA-6422
> > Project: Infrastructure
> >  Issue Type: Task
> >  Security Level: public(Regular issues)
> >  Components: VMWare
> >Reporter: Mike Billau
> >Assignee: jan iversen
> >
> > Hello, the Apache Cordova project would like to use a VM running Linux to
> set up an instance of Apache CouchDB. This CouchDB will collect the results
> of our continuous automated testing framework, Medic. We may end up using
> the VM to host other infrastructure related tools in the future, like our
> NPM registry.
> > I do not really have any requirements for the VM, so any suggestions or
> recommendations for a Linux VM with CouchDB are welcome and appreciated.
> I've read that some distributions of Linux come prebuilt with CouchDB, so
> maybe if we could get one of those that would make things easier. For the
> VM specs, I'd think 1GB RAM and 50GB disk space should be enough.
> > Thanks!
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.1#6144)
>

Fwd: [jira] [Resolved] (INFRA-6422) request linux virtual machine for Apache Cordova project

[Mike Billau]

Awesome, looks like JIRA has given us a VM to use to collect all of the CI
data.

Reply if you want/need access and I can email INFRA with all of our names
at once.

I can also work on setting up the db this week if nobody else wants to.



-- Forwarded message --
From: jan iversen (JIRA) 
Date: Wed, Nov 27, 2013 at 12:20 PM
Subject: [jira] [Resolved] (INFRA-6422) request linux virtual machine for
Apache Cordova project
To: mike.bil...@gmail.com



 [
https://issues.apache.org/jira/browse/INFRA-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]

jan iversen resolved INFRA-6422.


Resolution: Fixed

Vm is created and secured (ldap puppet etc).

dns: cordova-vm.a.o

At the moment root@ and I have access. Please catch a root@ person on
#asfnfra, or mail root@a.o o with apacheid to get access.

The project is expected to maintain the vm and keep it updated with
patches. If needed infra can help with this task.

In case of questions/problems do not hesitate to contact us.

Have fun
rgds
jan I.

> request linux virtual machine for Apache Cordova project
> 
>
> Key: INFRA-6422
> URL: https://issues.apache.org/jira/browse/INFRA-6422
> Project: Infrastructure
>  Issue Type: Task
>  Security Level: public(Regular issues)
>  Components: VMWare
>Reporter: Mike Billau
>Assignee: jan iversen
>
> Hello, the Apache Cordova project would like to use a VM running Linux to
set up an instance of Apache CouchDB. This CouchDB will collect the results
of our continuous automated testing framework, Medic. We may end up using
the VM to host other infrastructure related tools in the future, like our
NPM registry.
> I do not really have any requirements for the VM, so any suggestions or
recommendations for a Linux VM with CouchDB are welcome and appreciated.
I've read that some distributions of Linux come prebuilt with CouchDB, so
maybe if we could get one of those that would make things easier. For the
VM specs, I'd think 1GB RAM and 50GB disk space should be enough.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Re: Camera targetWidth & targetHeight

[John M. Wargo]

It occurred to me this morning that I didn't test a scenario where an application 
deliberately didn't maintain an appropriate aspect ratio with targetWidth & 
targetHeight.

I added a button to my app that set targetWidth to 2048 and targetHeight to 768.

On Android I got the following:

Portrait: 768x1024
Landscape: 1024x768

On iOS I got the following:

Portrait: 576x768
Landscape: 1024x768

Not what I expected. So apparently the API grabs the smaller property and 
applies a set aspect ratio to the resulting photo rather than try to do 
something weird. Notice again that on iOS the API applies the restriction 
weirdly in portrait.

On 12/2/2013 10:18 PM, Simon MacDonald wrote:

IIRC on Android if you only specify the width or height it will determine
what the other value should be by using the same aspect ration as the
original image.


Simon Mac Donald
http://hi.im/simonmacdonald


On Mon, Dec 2, 2013 at 10:15 PM, John M. Wargo  wrote:


A while back I posted a question regarding Camera targetWidth &
targetHeight properties and how they worked. After some discussion, the
conclusion I reached was that the documentation couldn't be correct about
how it worked since there was no way to determine the camera's resolution
with the current API but the docs said I had to provide both parameters.  I
said I'd do some testing and I have finally gotten around to completing it.
Here's what I discovered:

I created an application that allowed me to pass in different values for
targetWidth & targetHeight when taking a picture. I tested at the following
image sizes: 640x480, 800x600, 1024x768 as well as setting only the
targetWidth to 1024 or only the targetHeight to 768.

Here's the results:

Android
PortraitLandscape
480x640 640x480
600x800 800x600
768x10241024x768
768x10241024x768
768x10241024x768



iOS
PortraitLandscape
360x480 640x480
450x600 800x600
576x768 1024x768
2448x3264   3264x2448
2448x3264   3264x2448



Windows Phone 8
PortraitLandscape
1836x3264   3264x1836
1836x3264   3264x1836
1836x3264   3264x1836
1836x3264   3264x1836
1836x3264   3264x1836


As you can see, Android properly implements the targetWidth & targetHeight
properties. On iOS, it supports setting both properties, but not instances
where only one is specified. Windows Phone 8 ignores the parameters
completely.  On iOS, when you turn the device on its side, the Camera API
applies the target width or height to the wrong axis (Android does this
well however).

I'm trying to test this on a BlackBerry device, but my development
environment is giving me fits right now. I'll work on it in the morning and
publish my results when I get them.

I would suggest that the android implementation is as expected and that
the other platforms need their implementations of targetWidth &
targetHeight adjusted so it works correctly. The documentation should be
updated as well as it's incorrect today specifying that both properties
must be provided.

If the group doesn't want to support only providing one of the properties,
then I would expect that the onError callback is called when only one is
provided rather than simply ignoring them as is the case with iOS and
Windows Phone.

I posted my sample application and a spreadsheet with my results to
https://github.com/johnwargo/camera_res_test

--
John M. Wargo
@johnwargo 
www.johnwargo.com 
















--