Re: CB-4846

2014-02-21 Thread Shazron 
Joe - this calls a background fetch handler for your app at an interval, it
doesn't really run in the background.

Erik - just a quick code review:
1. The method swizzling stuff is great but what I have planned (sometime in
the future, in progress) is this:
https://issues.apache.org/jira/browse/CB-5601
2. The way you are using callbacks is not quite correct

Agree on it being a user space plugin -- but I was thinking it could be in
cordova-plugins maybe when the time comes


On Fri, Feb 21, 2014 at 1:47 PM, Joe Bowser  wrote:

> Is this actually running a service?  I thought this just runs a
> Cordova App in the background, which Android already has a setting
> for.
>
> On Fri, Feb 21, 2014 at 1:44 PM, Brian LeRoux  wrote:
> > I think its cool as a user space plugin for now though. Have you
> published
> > it to http://plugins.cordova.io ? (Its just like npm / you can read up
> on
> > how here: https://github.com/apache/cordova-plugman)
> >
> > I really like the idea of us looking at background processing.
> >
> > Android services: how would that work? Does Firefox OS have the concept
> of
> > background services? I know Chrome Mobile Apps guys have been doing some
> > thinking here too.
> >
> >
> > On Fri, Feb 21, 2014 at 2:53 AM, Erik Jan de Wit 
> wrote:
> >
> >> Hi,
> >>
> >> I've created an initial version for
> >> https://issues.apache.org/jira/browse/CB-4846 the plugin is located at
> >> https://github.com/edewit/cordova-background-plugin
> >>
> >> Cheers,
> >> Erik Jan
>

Re: 3.4 release documentation website -- no translations

2014-02-21 Thread Steven Gill 
Hey Lisa,

I can look into this. I haven't actually done a version release for
translations before. Should I update all of the languages?

The list of supported languages:
* de
* es
* fr
* it
* ja
* ko
* ru
* sl
* zh

If you (or anyone else) are interested in learning how to create new
versions and update the website for docs, I will list the steps below.

First off, make sure you follow the readme in cordova/docs and install the
dependencies.

## Generating new version
The command to create new versions is

rake version[version, language]

so rake version[3.4.0, de]

A new version should be created under cordova-docs/docs/language/version.

## rendering public docs
Now run ./bin/generate. This will render all of the docs in
cordova-docs/docs to cordova-docs/public. This takes quite a while. Old
versions need to get regenerated when we add new versions because the menu
for old versions need to show the latest version available.

## add docs to cordova-site
copy the rendered docs from `cordova-docs` to `cordova-website` by using
the following command:

rsync -av --exclude='.svn*' public/ ../cordova-website/public/docs
svn add public/docs/my_lang/my_new_version
svn commit -m "Added docs version XXX for language YYY"

That should do it!






On Fri, Feb 21, 2014 at 6:51 AM, Lisa Seacat DeLuca wrote:

> Even though the English documentation appears to be updated, the other
> languages haven't been updated on our site since the 3.1 release.
> http://cordova.apache.org/docs/en/edge/index.html
>
>
>
> I know the documentation files have changed for the plugins and the
> individual plugins themselves haven't been translated yet for 3.4 but the
> core information (from cordova-docs) has been translated.  We're going to
> have a lot of angry translators if their hard work doesn't get pulled into
> the main website.  The files have been pushed to the master apache cordova
> repo for docs.  Does someone mind helping me get this live?
>
> Thanks and Happy Friday!!
>
>
> Lisa
>
> Lisa Seacat DeLuca
> Mobile Engineer | t: +415.787.4589 | 
> *ldel...@apache.org*| |
> *ldel...@us.ibm.com*  | 
> *lisaseacat.com*| [image:
> follow @LisaSeacat on twitter] | [image:
> follow Lisa Seacat DeLuca on linkedin]
>
>
>

Android: recreating plugins when loading url

2014-02-21 Thread Naik, Archana 
Hi, Devs,

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

Thanks
Archana

Re: CB-6088: platform add firefoxos fails if config.xml in project but not in www

2014-02-21 Thread Sebastien Blanc 
Yes,
I faced this issue too earlier today and created
https://issues.apache.org/jira/browse/CB-6082 for that.
Cool to have already a PR :)
Seb


On Fri, Feb 21, 2014 at 10:38 PM, Axel Nennker wrote:

> Hi,
>
> "platform add firefoxos" fails if config.xml in project but not in www.
>
> config.xml moved to project_dir but firefoxos.js expects it in www and
> fails.
>
> Here is a pull request that looks for config.xml in project_dir first but
> falls back to www if not found.
>
> https://github.com/apache/cordova-plugman/pull/52
>
> This is no problem on platforms like Android because e.g. android.js gets
> the package_name from AndroidManifest.xml but firefoxos.js tries to
> retrieve it from config.xml.
> manifest.webapp is not existing at this point.
>
> cheers
> Axel
>

Re: CB-4846

2014-02-21 Thread Joe Bowser 
Is this actually running a service?  I thought this just runs a
Cordova App in the background, which Android already has a setting
for.

On Fri, Feb 21, 2014 at 1:44 PM, Brian LeRoux  wrote:
> I think its cool as a user space plugin for now though. Have you published
> it to http://plugins.cordova.io ? (Its just like npm / you can read up on
> how here: https://github.com/apache/cordova-plugman)
>
> I really like the idea of us looking at background processing.
>
> Android services: how would that work? Does Firefox OS have the concept of
> background services? I know Chrome Mobile Apps guys have been doing some
> thinking here too.
>
>
> On Fri, Feb 21, 2014 at 2:53 AM, Erik Jan de Wit  wrote:
>
>> Hi,
>>
>> I've created an initial version for
>> https://issues.apache.org/jira/browse/CB-4846 the plugin is located at
>> https://github.com/edewit/cordova-background-plugin
>>
>> Cheers,
>> Erik Jan

Re: CB-4846

2014-02-21 Thread Brian LeRoux 
I think its cool as a user space plugin for now though. Have you published
it to http://plugins.cordova.io ? (Its just like npm / you can read up on
how here: https://github.com/apache/cordova-plugman)

I really like the idea of us looking at background processing.

Android services: how would that work? Does Firefox OS have the concept of
background services? I know Chrome Mobile Apps guys have been doing some
thinking here too.


On Fri, Feb 21, 2014 at 2:53 AM, Erik Jan de Wit  wrote:

> Hi,
>
> I've created an initial version for
> https://issues.apache.org/jira/browse/CB-4846 the plugin is located at
> https://github.com/edewit/cordova-background-plugin
>
> Cheers,
> Erik Jan

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

2014-02-21 Thread Axel Nennker 
there is a pull request that implements this gap: prefix and phonegap
namespace stuff but this is Cordova and we have cdv: as prefix and another
namespace: xmlns:cdv="http://cordova.apache.org/ns/1.0";
Looks like config.json adapted by both projects is a way out.


2014-02-21 21:36 GMT+01:00 Don Coleman :

> Icons are a drag. Explicit configuration sucks, but is the way to go.
>
> It would be nice if the Cordova solution was compatible with PhoneGap Build
> icons<
> http://docs.build.phonegap.com/en_US/3.1.0/configuring_icons_and_splash.md.html#Icons%20and%20Splash%20Screens
> >
> .
>
>
>
>
> On Fri, Feb 21, 2014 at 11:24 AM, Axel Nennker  >wrote:
>
> > What is your favorite explicit configuration?
> > Am 21.02.2014 16:49 schrieb "Brian LeRoux" :
> >
> > > As much as I'd like a single icon source I do not think it is the right
> > > path. To do this right I think we need to audit all possible icons for
> > each
> > > platform and create a map to analyze what could be distilled across
> > > platforms.
> > >
> > > Ideally we'd accept a vector format (SVG) and generate all these
> > ridiculous
> > > sizes but designers will not like this. Pixel perfection, especially
> for
> > a
> > > springboard icon, is paramount. The only way we're getting there safely
> > is
> > > zero magic and explicit configuration.
> > >
> > > Lame, I know.
> > >
> > >
> > > On Thu, Feb 20, 2014 at 1:07 AM, Axel Nennker 
> > > wrote:
> > >
> > > > How about this strategy:
> > > >
> > > > project_dir/config.xml
> > > > - no new elements in config.xml like cdv:icon
> > > > - no new attributes in icon element in config.xml like cdv:platform
> or
> > > > gap:platform
> > > > - do not invent stuff we have to support for the rest of our life.
> > > >
> > > > On all platforms:
> > > > - if config.xml contains a  without any
> > > > attributes like width and heigth, then copy that src to to all
> platform
> > > > specific  locations where that platform expects launcher icons and
> > update
> > > > config files like manifest.webapp on FirefoxOS if there isn't a
> > specific
> > > > icon element for that location (see later).
> > > > - no downscaling of icons to lower sizes
> > > > - no upscaling of icons to higher sizes
> > > > - do not add dependencies to new node modules (e.g. to parse icon
> > files)
> > > >
> > > > On Android:
> > > > I) if there is a specific   then
> copy
> > > > that icon.png to res/drawable-mdpi (height is ignored if width is
> > > present,
> > > > no check for non-sqare icons)
> > > > II) Other sizes are handled according to this list from:
> > > > http://developer.android.com/guide/practices/screens_support.html
> > > >
> > > >- 36x36 for low-density
> > > >- 48x48 for medium-density
> > > >- 72x72 for high-density
> > > >- 96x96 for extra high-density
> > > >
> > > > Directories not matching this algorithm that have names starting with
> > > > res/drawable get the biggest icon if no default icon is available
> (I).
> > > > III) icons with width or height other than the ones mentioned here
> are
> > > > ignored.
> > > >
> > > > On FirefoxOS:
> > > > See
> https://developer.mozilla.org/en-US/Apps/Developing/Manifest#icons
> > > >
> > > > For Firefox OS, icons should follow the app icon
> > > > guidelines<
> > > > https://www.mozilla.org/en-US/styleguide/products/firefox-os/icons/
> >,
> > > > they should not have a drop shadow, and they should be in the
> following
> > > > sizes:
> > > >  128 x 128 For display on the Firefox Marketplace 60 x 60 For the
> > actual
> > > > on-device icon; only the 128px icon is mandatory, but it is
> recommended
> > > to
> > > > include this size as well for optimal device icon display
> > > > https://www.mozilla.org/en-US/styleguide/products/firefox-os/icons/
> > > >
> > > > I) ignore icon elements in config.xml without width or height
> > attributes
> > > > II) copy all icons mentioned in config.xml with width  or height
> equal
> > to
> > > > 60 or 128 to the app's root and create an icon section in
> > manifest.webapp
> > > > that matches these icons.
> > > > III) if no icon is specified for width/height 60 or 128 then copy
> each
> > > icon
> > > > mentioned in config.xml that has width or height specified.
> > > >
> > > > On other platforms:
> > > > some strategy matching the ones for Android and FirefoxOS. If a size
> is
> > > > there that is typical for that platform (72,144 for ios) then us only
> > > those
> > > > matching icons. Try to help developers.
> > > >
> > > > -Axel
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 2014-02-13 9:56 GMT+01:00 Axel Nennker :
> > > >
> > > > > The topic is reaching politics status...
> > > > >
> > > > > I think it is worth some effort to keep phonegap and cordova
> aligned.
> > > > > What is "Adobe"'s position on W3C widget and xml vs json?
> > > > >
> > > > > -Axel
> > > > >
> > > > > Regarding which PR to accept: I want support for launcher icons
> and I
> > > do
> > > > > not care whether my PR is accepted

CB-6088: platform add firefoxos fails if config.xml in project but not in www

2014-02-21 Thread Axel Nennker 
Hi,

"platform add firefoxos" fails if config.xml in project but not in www.

config.xml moved to project_dir but firefoxos.js expects it in www and
fails.

Here is a pull request that looks for config.xml in project_dir first but
falls back to www if not found.

https://github.com/apache/cordova-plugman/pull/52

This is no problem on platforms like Android because e.g. android.js gets
the package_name from AndroidManifest.xml but firefoxos.js tries to
retrieve it from config.xml.
manifest.webapp is not existing at this point.

cheers
Axel

Re: BlackBerry 10 - config.xml iicon entries are not filtered for gap:platform

2014-02-21 Thread Don Coleman 
I was thinking about patching the BB10 Cordova scripts to filter out
non-blackberry options, but since it looks like config.xml is changing to
config.json, I'll probably just handle with custom per project filters for
now.



On Fri, Feb 21, 2014 at 8:44 AM, Bryan Higgins wrote:

> I'd like to see config.xml have a platform tag similar to plugin.xml.
> Neither Cordova nor BlackBerry native tools should understand PhoneGap
> attributes.
>
>
> On Thu, Feb 20, 2014 at 5:26 PM, Don Coleman 
> wrote:
>
> > I have a project that uses PhoneGap build for iOS and Android, and uses
> > Cordova to build for BlackBerry 10.
> >
> > The icons are specified in config.xml
> >
> > 
> >  gap:platform="android"
> >gap:density="ldpi" />
> >  gap:platform="android"
> >gap:density="mdpi" />
> >  gap:platform="android"
> >gap:density="hdpi" />
> >   gap:platform="android"
> >gap:density="xhdpi" />
> >  > gap:platform="blackberry" />
> >  > gap:platform="blackberry" gap:state="hover"/>
> > 
> >
> > When the bar file is built, the Entry-Point-Icon Manifest entry is
> > incorrect
> >
> > $ unzip -p platforms/blackberry10/build/device/bb10app.bar
> > META-INF/MANIFEST.MF | grep Entry
> >
> > Entry-Point: WEBWORKS_VERSION=2.0.0 CONSOLE_MODE=slog2
> > CASCADES_THEME=default app/native/wwe
> > Entry-Point-Type: Qnx/WebKit
> > Entry-Point-Icon:
> >
> >
> {72x72}native/icon.png:{36x36}native/res/icon/android/icon-36-ldpi.png:{48x48}native/res/icon/android/icon-48-mdpi.png:{72x72}native/res/icon/android/icon-72-hdpi.png:{96x96}native/res/icon/android/icon-96-xhdpi.png:{80x80}native/res/icon/blackberry/icon-80.png:{57x57}n
> > Entry-Point-Orientation: auto
> >
> >
> > The app looks deploys OK locally and passes blackberry-barchecker, but
> > BlackBerry Enterprise Server rejected the app due to this entry.
> >
> > I fixed the problem by preprocessing the config.xml before the
> blackberry10
> > build.
> >
> > Entry-Point: WEBWORKS_VERSION=2.0.0 CASCADES_THEME=default app/native/wwe
> > Entry-Point-Type: Qnx/WebKit
> > Entry-Point-Icon: native/res/icon/blackberry/icon-80.png
> > Entry-Point-Orientation: auto
> >
> >
> > Is this a problem that Cordova should handle? Or is it a problem with the
> > blackberry-nativepackager?
> >
>

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

2014-02-21 Thread Don Coleman 
Icons are a drag. Explicit configuration sucks, but is the way to go.

It would be nice if the Cordova solution was compatible with PhoneGap Build
icons
.




On Fri, Feb 21, 2014 at 11:24 AM, Axel Nennker wrote:

> What is your favorite explicit configuration?
> Am 21.02.2014 16:49 schrieb "Brian LeRoux" :
>
> > As much as I'd like a single icon source I do not think it is the right
> > path. To do this right I think we need to audit all possible icons for
> each
> > platform and create a map to analyze what could be distilled across
> > platforms.
> >
> > Ideally we'd accept a vector format (SVG) and generate all these
> ridiculous
> > sizes but designers will not like this. Pixel perfection, especially for
> a
> > springboard icon, is paramount. The only way we're getting there safely
> is
> > zero magic and explicit configuration.
> >
> > Lame, I know.
> >
> >
> > On Thu, Feb 20, 2014 at 1:07 AM, Axel Nennker 
> > wrote:
> >
> > > How about this strategy:
> > >
> > > project_dir/config.xml
> > > - no new elements in config.xml like cdv:icon
> > > - no new attributes in icon element in config.xml like cdv:platform or
> > > gap:platform
> > > - do not invent stuff we have to support for the rest of our life.
> > >
> > > On all platforms:
> > > - if config.xml contains a  without any
> > > attributes like width and heigth, then copy that src to to all platform
> > > specific  locations where that platform expects launcher icons and
> update
> > > config files like manifest.webapp on FirefoxOS if there isn't a
> specific
> > > icon element for that location (see later).
> > > - no downscaling of icons to lower sizes
> > > - no upscaling of icons to higher sizes
> > > - do not add dependencies to new node modules (e.g. to parse icon
> files)
> > >
> > > On Android:
> > > I) if there is a specific   then copy
> > > that icon.png to res/drawable-mdpi (height is ignored if width is
> > present,
> > > no check for non-sqare icons)
> > > II) Other sizes are handled according to this list from:
> > > http://developer.android.com/guide/practices/screens_support.html
> > >
> > >- 36x36 for low-density
> > >- 48x48 for medium-density
> > >- 72x72 for high-density
> > >- 96x96 for extra high-density
> > >
> > > Directories not matching this algorithm that have names starting with
> > > res/drawable get the biggest icon if no default icon is available (I).
> > > III) icons with width or height other than the ones mentioned here are
> > > ignored.
> > >
> > > On FirefoxOS:
> > > See https://developer.mozilla.org/en-US/Apps/Developing/Manifest#icons
> > >
> > > For Firefox OS, icons should follow the app icon
> > > guidelines<
> > > https://www.mozilla.org/en-US/styleguide/products/firefox-os/icons/>,
> > > they should not have a drop shadow, and they should be in the following
> > > sizes:
> > >  128 x 128 For display on the Firefox Marketplace 60 x 60 For the
> actual
> > > on-device icon; only the 128px icon is mandatory, but it is recommended
> > to
> > > include this size as well for optimal device icon display
> > > https://www.mozilla.org/en-US/styleguide/products/firefox-os/icons/
> > >
> > > I) ignore icon elements in config.xml without width or height
> attributes
> > > II) copy all icons mentioned in config.xml with width  or height equal
> to
> > > 60 or 128 to the app's root and create an icon section in
> manifest.webapp
> > > that matches these icons.
> > > III) if no icon is specified for width/height 60 or 128 then copy each
> > icon
> > > mentioned in config.xml that has width or height specified.
> > >
> > > On other platforms:
> > > some strategy matching the ones for Android and FirefoxOS. If a size is
> > > there that is typical for that platform (72,144 for ios) then us only
> > those
> > > matching icons. Try to help developers.
> > >
> > > -Axel
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2014-02-13 9:56 GMT+01:00 Axel Nennker :
> > >
> > > > The topic is reaching politics status...
> > > >
> > > > I think it is worth some effort to keep phonegap and cordova aligned.
> > > > What is "Adobe"'s position on W3C widget and xml vs json?
> > > >
> > > > -Axel
> > > >
> > > > Regarding which PR to accept: I want support for launcher icons and I
> > do
> > > > not care whether my PR is accepted or the other one.
> > > > Actually I do not understand why CB-2606 is open for so long.
> > > > https://issues.apache.org/jira/browse/CB-2606
> > > >
> > > >
> > > >
> > > >
> > > > 2014-02-12 23:33 GMT+01:00 Jesse :
> > > >
> > > > Part of what you are seeing is the phonegap namespace extensions that
> > are
> > > >> added for build.phonegap.com and the online tools. [1] [2]
> > > >>
> > > >>
> > > >> [1]
> > > >>
> > > >>
> > >
> >
> http://docs.build.phonegap.com/en_US/3.1.0/configuring_basics.md.html#The%20Basics
> > > >> [2]
> > > https://github.com/phonegap/phonegap-start/blob/

Re: PushPlugin support for amazon-fireos

2014-02-21 Thread Shazron 
Hi Archana,
Feel free to fork, we can take this discussion off-list regarding contrib.


On Fri, Feb 21, 2014 at 11:14 AM, Naik, Archana  wrote:

> Hi, Guys
>
> I see this github : https://github.com/phonegap-build/PushPlugin for push
> notifications plugin. I would like to add amazon-fireos as a platform there.
> Amazon has Amazon Device Messaging (ADM) service to do similar GCM and
> iOS's push notifications.
> This is probably not the right list and am happy to take it offline with
> somebody from phone gap team.
>
> Thanks
> Archana
>

PushPlugin support for amazon-fireos

2014-02-21 Thread Naik, Archana 
Hi, Guys

I see this github : https://github.com/phonegap-build/PushPlugin for push 
notifications plugin. I would like to add amazon-fireos as a platform there.
Amazon has Amazon Device Messaging (ADM) service to do similar GCM and iOS's 
push notifications.
This is probably not the right list and am happy to take it offline with 
somebody from phone gap team.

Thanks
Archana

Re: Alignment with W3C specs

2014-02-21 Thread Lisa Seacat DeLuca 
Dom~

I think you're on the right track starting first by opening the JIRA 
issues.  My thoughts below on your questions...

More specifically:
* some of the W3C APIs are more stable than others; should we target to
align with all W3C APIs, or only the most stable? If the latter, any
thumb rule as to how stable a W3C API needs to be before aligning with
it?
LD: We should prioritize the list.  Which changes are the simplest to 
implement?  Which ones would make the biggest impact if they were 
integrated. 

* I understand that APIs need to be preserved between Major releases
according to http://wiki.apache.org/cordova/DeprecationPolicy ; if one
were to start working on aligned APIs for the various plugins, what
would be the best approach:
  - provide patches that replace the existing APIs with the new
(aligned) ones  for Cordova 4.x, and add deprecation warnings for the
existing APIs in 3.4+
  - provide patches that add the aligned APIs in 3.5+, deprecation
warnings for existing ones, and reimplement existing ones on top of the
aligned APIs

LD: As someone else suggested we could create a new plugin separate from 
the old one and maintain a separate repo until we're ready to switch from 
the old API to the new ones.

* how should we proceed when the number of features provided in W3C APIs
is smaller than the ones provided by Cordova?

LD: Take it as an opportunity to take those changes to the w3c groups and 
see if they can add to the specs.  That way it's a two way street. 
Depending of course on the features.  If the w3c feels strongly for why 
those features weren't added to the spec we should have that conversation. 
 It's probably something to talk about on an individual API basis.

* how should we deal with APIs that are no longer developed by W3C? I
see there was recent discussion on this on the Network Information API
for instance [2]

LD: Just like you did here the best way to get going on an issue is to 
send a note to the dev list. 

* how can we facilitate a feedback loop between the Cordova project and
the various W3C groups developing corresponding APIs? I understand that
everyone can get very busy on both sides, so I wonder if there is a way
to set up a kind of a regular checkpoint that would avoid our common
APIs to drift away, and would provide an opportunity to synchronize on
the future plans

LD: I already responded that I'd be willing to represent Cordova on the 
DAP w3c working group and Web/Mob w3c interest group as I am already part 
of those groups.  We could also have a smaller task force that meets 
bi-monthly using one of the w3c bridges to go over status. 


Lisa

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





From:   Dominique Hazael-Massieux 
To: dev@cordova.apache.org
Date:   02/21/2014 09:57 AM
Subject:Alignment with W3C specs



Hi all,

Let me introduce myself quickly: I am part of the W3C staff, am
responsible for supervising the mobile-related work in W3C, serve as the
“staff contact” for a variety of W3C groups (Web & Mobile Interest
Group, Device APIs Working Group, Geolocation Working Group, WebRTC
Working Group); I also edit a quarterly overview of Web technologies
relevant to mobile: http://www.w3.org/Mobile/mobile-web-app-state/

After some discussion with Brian, I filed yesterday a bunch of issues
around aligning Cordova plugins with W3C specs [1].

Given how widely used Cordova is, and given that I understand its goals
include to keep the development of hybrid apps as close as possible to
standards Web app, I feel it's pretty important we try to keep W3C and
Cordova APIs as aligned as possible.

I'm interested to contribute myself to that alignment, and to try to get
some of the Web & Mobile IG participants to help as well; but before
diving into that, I would like to start some higher level discussion on
how that alignment should happen, and how we keep the APIs aligned in
the long run.

More specifically:
* some of the W3C APIs are more stable than others; should we target to
align with all W3C APIs, or only the most stable? If the latter, any
thumb rule as to how stable a W3C API needs to be before aligning with
it?

* I understand that APIs need to be preserved between Major releases
according to http://wiki.apache.org/cordova/DeprecationPolicy ; if one
were to start working on aligned APIs for the various plugins, what
would be the best approach:
  - provide patches that replace the existing APIs with the new
(aligned) ones  for Cordova 4.x, and add deprecation warnings for the
existing APIs in 3.4+
  - provide patches that add the aligned APIs in 3.5+, deprecation
warnings for existing ones, and reimplement existing ones on top of the
aligned APIs

* how should we proceed when the number of features provided in W3C APIs
is smaller than the ones provided by Cordova?

* how should we deal with APIs that are no longer developed by W3C? I
see there was recent discussion on

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

2014-02-21 Thread Axel Nennker 
What is your favorite explicit configuration?
Am 21.02.2014 16:49 schrieb "Brian LeRoux" :

> As much as I'd like a single icon source I do not think it is the right
> path. To do this right I think we need to audit all possible icons for each
> platform and create a map to analyze what could be distilled across
> platforms.
>
> Ideally we'd accept a vector format (SVG) and generate all these ridiculous
> sizes but designers will not like this. Pixel perfection, especially for a
> springboard icon, is paramount. The only way we're getting there safely is
> zero magic and explicit configuration.
>
> Lame, I know.
>
>
> On Thu, Feb 20, 2014 at 1:07 AM, Axel Nennker 
> wrote:
>
> > How about this strategy:
> >
> > project_dir/config.xml
> > - no new elements in config.xml like cdv:icon
> > - no new attributes in icon element in config.xml like cdv:platform or
> > gap:platform
> > - do not invent stuff we have to support for the rest of our life.
> >
> > On all platforms:
> > - if config.xml contains a  without any
> > attributes like width and heigth, then copy that src to to all platform
> > specific  locations where that platform expects launcher icons and update
> > config files like manifest.webapp on FirefoxOS if there isn't a specific
> > icon element for that location (see later).
> > - no downscaling of icons to lower sizes
> > - no upscaling of icons to higher sizes
> > - do not add dependencies to new node modules (e.g. to parse icon files)
> >
> > On Android:
> > I) if there is a specific   then copy
> > that icon.png to res/drawable-mdpi (height is ignored if width is
> present,
> > no check for non-sqare icons)
> > II) Other sizes are handled according to this list from:
> > http://developer.android.com/guide/practices/screens_support.html
> >
> >- 36x36 for low-density
> >- 48x48 for medium-density
> >- 72x72 for high-density
> >- 96x96 for extra high-density
> >
> > Directories not matching this algorithm that have names starting with
> > res/drawable get the biggest icon if no default icon is available (I).
> > III) icons with width or height other than the ones mentioned here are
> > ignored.
> >
> > On FirefoxOS:
> > See https://developer.mozilla.org/en-US/Apps/Developing/Manifest#icons
> >
> > For Firefox OS, icons should follow the app icon
> > guidelines<
> > https://www.mozilla.org/en-US/styleguide/products/firefox-os/icons/>,
> > they should not have a drop shadow, and they should be in the following
> > sizes:
> >  128 x 128 For display on the Firefox Marketplace 60 x 60 For the actual
> > on-device icon; only the 128px icon is mandatory, but it is recommended
> to
> > include this size as well for optimal device icon display
> > https://www.mozilla.org/en-US/styleguide/products/firefox-os/icons/
> >
> > I) ignore icon elements in config.xml without width or height attributes
> > II) copy all icons mentioned in config.xml with width  or height equal to
> > 60 or 128 to the app's root and create an icon section in manifest.webapp
> > that matches these icons.
> > III) if no icon is specified for width/height 60 or 128 then copy each
> icon
> > mentioned in config.xml that has width or height specified.
> >
> > On other platforms:
> > some strategy matching the ones for Android and FirefoxOS. If a size is
> > there that is typical for that platform (72,144 for ios) then us only
> those
> > matching icons. Try to help developers.
> >
> > -Axel
> >
> >
> >
> >
> >
> >
> >
> > 2014-02-13 9:56 GMT+01:00 Axel Nennker :
> >
> > > The topic is reaching politics status...
> > >
> > > I think it is worth some effort to keep phonegap and cordova aligned.
> > > What is "Adobe"'s position on W3C widget and xml vs json?
> > >
> > > -Axel
> > >
> > > Regarding which PR to accept: I want support for launcher icons and I
> do
> > > not care whether my PR is accepted or the other one.
> > > Actually I do not understand why CB-2606 is open for so long.
> > > https://issues.apache.org/jira/browse/CB-2606
> > >
> > >
> > >
> > >
> > > 2014-02-12 23:33 GMT+01:00 Jesse :
> > >
> > > Part of what you are seeing is the phonegap namespace extensions that
> are
> > >> added for build.phonegap.com and the online tools. [1] [2]
> > >>
> > >>
> > >> [1]
> > >>
> > >>
> >
> http://docs.build.phonegap.com/en_US/3.1.0/configuring_basics.md.html#The%20Basics
> > >> [2]
> > https://github.com/phonegap/phonegap-start/blob/master/www/config.xml
> > >>
> > >>
> > >> @purplecabbage
> > >> risingj.com
> > >>
> > >>
> > >> On Wed, Feb 12, 2014 at 2:03 PM, Andrew Grieve 
> > >> wrote:
> > >>
> > >> > Just started a new thread to propose removing the namespace.
> > >> >
> > >> > Don't the we should use "gap:density", since that's pretty
> PhoneGap-y
> > as
> > >> > opposed to Cordova-y.
> > >> >
> > >> > How about we have "size" and "density" attributes that are just
> > >> synonyms?
> > >> >
> > >> > Off for the day.
> > >> >
> > >> >
> > >> >
> > >> > On Wed, Feb 12, 2014 at 4:57 PM, Axel Nennker <
> ignisvul..

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

2014-02-21 Thread Brian LeRoux 
As much as I'd like a single icon source I do not think it is the right
path. To do this right I think we need to audit all possible icons for each
platform and create a map to analyze what could be distilled across
platforms.

Ideally we'd accept a vector format (SVG) and generate all these ridiculous
sizes but designers will not like this. Pixel perfection, especially for a
springboard icon, is paramount. The only way we're getting there safely is
zero magic and explicit configuration.

Lame, I know.


On Thu, Feb 20, 2014 at 1:07 AM, Axel Nennker  wrote:

> How about this strategy:
>
> project_dir/config.xml
> - no new elements in config.xml like cdv:icon
> - no new attributes in icon element in config.xml like cdv:platform or
> gap:platform
> - do not invent stuff we have to support for the rest of our life.
>
> On all platforms:
> - if config.xml contains a  without any
> attributes like width and heigth, then copy that src to to all platform
> specific  locations where that platform expects launcher icons and update
> config files like manifest.webapp on FirefoxOS if there isn't a specific
> icon element for that location (see later).
> - no downscaling of icons to lower sizes
> - no upscaling of icons to higher sizes
> - do not add dependencies to new node modules (e.g. to parse icon files)
>
> On Android:
> I) if there is a specific   then copy
> that icon.png to res/drawable-mdpi (height is ignored if width is present,
> no check for non-sqare icons)
> II) Other sizes are handled according to this list from:
> http://developer.android.com/guide/practices/screens_support.html
>
>- 36x36 for low-density
>- 48x48 for medium-density
>- 72x72 for high-density
>- 96x96 for extra high-density
>
> Directories not matching this algorithm that have names starting with
> res/drawable get the biggest icon if no default icon is available (I).
> III) icons with width or height other than the ones mentioned here are
> ignored.
>
> On FirefoxOS:
> See https://developer.mozilla.org/en-US/Apps/Developing/Manifest#icons
>
> For Firefox OS, icons should follow the app icon
> guidelines<
> https://www.mozilla.org/en-US/styleguide/products/firefox-os/icons/>,
> they should not have a drop shadow, and they should be in the following
> sizes:
>  128 x 128 For display on the Firefox Marketplace 60 x 60 For the actual
> on-device icon; only the 128px icon is mandatory, but it is recommended to
> include this size as well for optimal device icon display
> https://www.mozilla.org/en-US/styleguide/products/firefox-os/icons/
>
> I) ignore icon elements in config.xml without width or height attributes
> II) copy all icons mentioned in config.xml with width  or height equal to
> 60 or 128 to the app's root and create an icon section in manifest.webapp
> that matches these icons.
> III) if no icon is specified for width/height 60 or 128 then copy each icon
> mentioned in config.xml that has width or height specified.
>
> On other platforms:
> some strategy matching the ones for Android and FirefoxOS. If a size is
> there that is typical for that platform (72,144 for ios) then us only those
> matching icons. Try to help developers.
>
> -Axel
>
>
>
>
>
>
>
> 2014-02-13 9:56 GMT+01:00 Axel Nennker :
>
> > The topic is reaching politics status...
> >
> > I think it is worth some effort to keep phonegap and cordova aligned.
> > What is "Adobe"'s position on W3C widget and xml vs json?
> >
> > -Axel
> >
> > Regarding which PR to accept: I want support for launcher icons and I do
> > not care whether my PR is accepted or the other one.
> > Actually I do not understand why CB-2606 is open for so long.
> > https://issues.apache.org/jira/browse/CB-2606
> >
> >
> >
> >
> > 2014-02-12 23:33 GMT+01:00 Jesse :
> >
> > Part of what you are seeing is the phonegap namespace extensions that are
> >> added for build.phonegap.com and the online tools. [1] [2]
> >>
> >>
> >> [1]
> >>
> >>
> http://docs.build.phonegap.com/en_US/3.1.0/configuring_basics.md.html#The%20Basics
> >> [2]
> https://github.com/phonegap/phonegap-start/blob/master/www/config.xml
> >>
> >>
> >> @purplecabbage
> >> risingj.com
> >>
> >>
> >> On Wed, Feb 12, 2014 at 2:03 PM, Andrew Grieve 
> >> wrote:
> >>
> >> > Just started a new thread to propose removing the namespace.
> >> >
> >> > Don't the we should use "gap:density", since that's pretty PhoneGap-y
> as
> >> > opposed to Cordova-y.
> >> >
> >> > How about we have "size" and "density" attributes that are just
> >> synonyms?
> >> >
> >> > Off for the day.
> >> >
> >> >
> >> >
> >> > On Wed, Feb 12, 2014 at 4:57 PM, Axel Nennker 
> >> > wrote:
> >> >
> >> > > Hm. I guess the id test is historical stuff. It is legal XML and the
> >> > parser
> >> > > ignores it.
> >> > >
> >> > > Regarding the NS prefix: cdv vs gap
> >> > > I am quite sure I did not invent cdv myself.
> >> > >
> >> > > Regarding the w3c widget standard: I am OK with ditching it. Should
> >> there
> >> > > be a poll or how do you handle such thin

Re: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

2014-02-21 Thread Axel Nennker 
True but...
CB-2606 is open for ages and people don't seem to be able to agree on a
format (see namespace discussion).
e.g. Phonegap has a solution but uses another prefix/namespace.
My latest suggestion in this threat is what I think is "a small step
forward". Not perfect, sure.
Different icons on different platforms are not supported but you do not
need gap:platform or cdv:platform or platform.
The history of my commits to
https://github.com/apache/cordova-cli/pull/126reflect what people
suggested. (or my attempts to guess what might be
acceptable for all)

Don just sent another email where he has a project and wants to use cordava
for some platforms and phonegap for others.
"BlackBerry 10 - config.xml iicon entries are not filtered for gap:platform"
This does not work. Cordova does not handle the Phonegap
extensions/prefix/namespace.
Either we implement the Phonegap icon extensions or we wait for 4.0 to get
rid of config.xml.
Or we implement the "small step forward" (with it's restrictions) and wait
for 4.0 to get rid of config.xml.

-Axel



2014-02-21 15:48 GMT+01:00 Jonathan Bond-Caron :

> On Fri Feb 21 09:43 AM, Axel Nennker wrote:
> >
> > I would like to avoid to invent new elements or attributes. I think my
> plan works
> > and would like to know what the group thinks about it.
> >
>
> The "icon problem" is you can have different icons of the same size for
> different platforms.
>
> The cordova config has data model problem, there's no magical code
> generation that's going to solve that.
>
>

Alignment with W3C specs

2014-02-21 Thread Dominique Hazael-Massieux 
Hi all,

Let me introduce myself quickly: I am part of the W3C staff, am
responsible for supervising the mobile-related work in W3C, serve as the
“staff contact” for a variety of W3C groups (Web & Mobile Interest
Group, Device APIs Working Group, Geolocation Working Group, WebRTC
Working Group); I also edit a quarterly overview of Web technologies
relevant to mobile: http://www.w3.org/Mobile/mobile-web-app-state/

After some discussion with Brian, I filed yesterday a bunch of issues
around aligning Cordova plugins with W3C specs [1].

Given how widely used Cordova is, and given that I understand its goals
include to keep the development of hybrid apps as close as possible to
standards Web app, I feel it's pretty important we try to keep W3C and
Cordova APIs as aligned as possible.

I'm interested to contribute myself to that alignment, and to try to get
some of the Web & Mobile IG participants to help as well; but before
diving into that, I would like to start some higher level discussion on
how that alignment should happen, and how we keep the APIs aligned in
the long run.

More specifically:
* some of the W3C APIs are more stable than others; should we target to
align with all W3C APIs, or only the most stable? If the latter, any
thumb rule as to how stable a W3C API needs to be before aligning with
it?

* I understand that APIs need to be preserved between Major releases
according to http://wiki.apache.org/cordova/DeprecationPolicy ; if one
were to start working on aligned APIs for the various plugins, what
would be the best approach:
  - provide patches that replace the existing APIs with the new
(aligned) ones  for Cordova 4.x, and add deprecation warnings for the
existing APIs in 3.4+
  - provide patches that add the aligned APIs in 3.5+, deprecation
warnings for existing ones, and reimplement existing ones on top of the
aligned APIs

* how should we proceed when the number of features provided in W3C APIs
is smaller than the ones provided by Cordova?

* how should we deal with APIs that are no longer developed by W3C? I
see there was recent discussion on this on the Network Information API
for instance [2]

* how can we facilitate a feedback loop between the Cordova project and
the various W3C groups developing corresponding APIs? I understand that
everyone can get very busy on both sides, so I wonder if there is a way
to set up a kind of a regular checkpoint that would avoid our common
APIs to drift away, and would provide an opportunity to synchronize on
the future plans

Sorry for this long message, and thanks for any feedback you might have!

Dom

1. namely:
https://issues.apache.org/jira/browse/CB-6065 battery
https://issues.apache.org/jira/browse/CB-6066 html media capture
https://issues.apache.org/jira/browse/CB-6068 contacts
https://issues.apache.org/jira/browse/CB-6069 motion
https://issues.apache.org/jira/browse/CB-6070 orientation
https://issues.apache.org/jira/browse/CB-6071 notifications
https://issues.apache.org/jira/browse/CB-6072 File transfer
https://issues.apache.org/jira/browse/CB-6073 I18N
https://issues.apache.org/jira/browse/CB-6074 Media
https://issues.apache.org/jira/browse/CB-6075 Vibration which was marked
as a dup of https://issues.apache.org/jira/browse/CB-5459

2. http://markmail.org/message/576zycp5uqcbvni4

Re: ApacheCon attendees and talks

2014-02-21 Thread Rich Bowen 
50 minutes. And there's actually a day and a half of cordova. Pretty
excited about that.

-- 
Rich Bowen, mobile edition
rbo...@rcbowen.com
On Feb 20, 2014 1:06 PM, "Brian LeRoux"  wrote:

> Pretty sure there is an entire Cordova track. Wish I could be there for
> that. =)
>
> I've cc'd Rich whom should know about session length.
>
>
> On Thu, Feb 20, 2014 at 10:17 AM, Steven Gill wrote:
>
>> I shall also be there! Would love to meetup!
>>
>> Talk: getting started with apache cordova & the cli.
>>
>> Not sure how long they are supposed to be yet. That would be useful info
>> to
>> have though :P
>>
>> -Steve
>>
>> On Thu, Feb 20, 2014 at 8:18 AM, Gorkem Ercan > >wrote:
>>
>> > will be there... I have a talk named "Developing Cordova Applications
>> with
>> > Eclipse IDE"
>> > --
>> > Gorkem
>> >
>> >
>> > On Wed, Feb 19, 2014 at 11:46 PM, Don Coleman 
>> > wrote:
>> >
>> > > That's a good idea to meet up.
>> > >
>> > > One of my talks was accepted - Connecting Arduino and Phones with
>> > Bluetooth
>> > > and Cordova
>> > > And they also accepted a lab - Hands on with NFC and Apache Cordova
>> > >
>> > >
>> > >
>> > >
>> > > On Wed, Feb 19, 2014 at 3:44 PM, Andrew Grieve 
>> > > wrote:
>> > >
>> > > > Yep, I'll be there.
>> > > >
>> > > >
>> > > > On Wed, Feb 19, 2014 at 10:36 AM, Lisa Seacat DeLuca <
>> > ldel...@us.ibm.com
>> > > > >wrote:
>> > > >
>> > > > > Taking a poll to see who all is planning on attending ApacheCon
>> and
>> > the
>> > > > > titles of your talks.  It'd like to get some time to meetup with
>> > other
>> > > > > Cordova committers while we're there.
>> > > > >
>> > > > > Here are the two I planned on presenting:
>> > > > > "Crowd Sourcing Translations - A Look at How Apache Cordova's
>> > > > > Documentation is Available in Multiple Languages"
>> > > > > "Using Modern Web Technologies to Rapid Develop an Apache Cordova
>> > > Mobile
>> > > > > App"
>> > > > >
>> > > > > Last i saw on our mailing list attendees from our group are:
>> > > > > Andrew Grieve
>> > > > > talk: The Cordova Development Lifecycle (how we manage 50
>> > repos
>> > > > > and not go insane) lightning talk: Cordova's Sweet Spot (e.g. what
>> > kind
>> > > > of
>> > > > > apps are good fits for hybrid)
>> > > > > Steve Gill
>> > > > > Don Coleman
>> > > > > Presentation - Connecting Arduino and Phones with
>> Bluetooth
>> > and
>> > > > > Cordova Presentation - Writing NFC applications with Apache
>> Cordova
>> > > > > Lab - Hands on with NFC and Apache Cordova
>> > > > >
>> > > > > Do we get 30 minutes or an hour for the talks?  I didn't see that
>> > > > > information on the submission page.
>> > > > >
>> > > > >
>> > > > > Lisa
>> > > > >
>> > > > > Lisa Seacat DeLuca
>> > > > > Mobile Engineer | t: +415.787.4589 | *ldel...@apache.org*<
>> > > > ldel...@apache.org>| |
>> > > > > *ldel...@us.ibm.com*  | *lisaseacat.com*<
>> > > > http://www.lisaseacat.com/>| [image:
>> > > > > follow @LisaSeacat on twitter] > >|
>> > > > [image:
>> > > > > follow Lisa Seacat DeLuca on linkedin]<
>> > > > http://www.linkedin.com/in/lisaseacat>
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: Engine confusion

2014-02-21 Thread Marcel Kinard 
I prefer the former. I'd rather do a match for a simple attribute value (which 
is easy to write an XSD for), than have to parse/unparse a value convention 
with a bunch of hyphens or some custom syntax.

On Feb 21, 2014, at 9:36 AM, Jonathan Bond-Caron  
wrote:

>  runtime="chromeview" />
> 
> Vs.
>  ?
>

3.4 release documentation website -- no translations

2014-02-21 Thread Lisa Seacat DeLuca 
Even though the English documentation appears to be updated, the other 
languages haven't been updated on our site since the 3.1 release. 
http://cordova.apache.org/docs/en/edge/index.html



I know the documentation files have changed for the plugins and the 
individual plugins themselves haven't been translated yet for 3.4 but the 
core information (from cordova-docs) has been translated.  We're going to 
have a lot of angry translators if their hard work doesn't get pulled into 
the main website.  The files have been pushed to the master apache cordova 
repo for docs.  Does someone mind helping me get this live?

Thanks and Happy Friday!!


Lisa

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

RE: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

2014-02-21 Thread Jonathan Bond-Caron 
On Fri Feb 21 09:43 AM, Axel Nennker wrote:
> 
> I would like to avoid to invent new elements or attributes. I think my plan 
> works
> and would like to know what the group thinks about it.
> 

The "icon problem" is you can have different icons of the same size for 
different platforms.

The cordova config has data model problem, there's no magical code generation 
that's going to solve that.

Re: [ANNOUNCE] Cordova 3.4.0 Released!

2014-02-21 Thread Marcel Kinard 
Steve, thanks much for being our release engineer!

This is a great group.

On Feb 20, 2014, at 2:27 PM, Steven Gill  wrote:

> Woohoo! Congrats all.
> 
> Blog post:
> http://cordova.apache.org/announcements/2014/02/20/cordova-340.html
> Tweet: https://twitter.com/apachecordova/status/436582745477615616

RE: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

2014-02-21 Thread Axel Nennker 
I think that 4.0 drops XML altogether for the project's config. We already
had long discussions about prefixes and namespaces which gave me the
impression that most people would like to drop the w3c widget standard and
XML.

I would like to avoid to invent new elements or attributes. I think my plan
works and would like to know what the group thinks about it.

Axel
Am 21.02.2014 15:23 schrieb "Jonathan Bond-Caron" :

> On Fri Feb 21 09:14 AM, Jonathan Bond-Caron wrote:
> > On Thu Feb 20 04:07 AM, Axel Nennker wrote:
> > > How about this strategy:
> > >
> >
> > Would this work:
> >   > ref="icons" src="icon.jpg" width="96" height="96" />  > ref="splashscreens" src="splash.jpg" width="1024" height="768" />
> >
> > 
> >
> > 
> >
> > The cdv: prefix in the only clean way to get to something useful in 4.0
> >
>
> In 4.0, it becomes:
> 
> 
> 
>
> 
> 
> 
>
>

RE: Engine confusion

2014-02-21 Thread Jonathan Bond-Caron 
On Wed Feb 12 02:12 PM, Tim Kim wrote:
> 
> 
> Yep, Braden is correct. That is totally a bug.  Filed here:
> https://issues.apache.org/jira/browse/CB-6023
> 

Thoughts on?


Vs.

 

I'm trying to look at how this can apply to 'runtimes'. E.g.




Vs.
 ?

RE: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

2014-02-21 Thread Jonathan Bond-Caron 
On Fri Feb 21 09:14 AM, Jonathan Bond-Caron wrote:
> On Thu Feb 20 04:07 AM, Axel Nennker wrote:
> > How about this strategy:
> >
> 
> Would this work:
>   ref="icons" src="icon.jpg" width="96" height="96" />  ref="splashscreens" src="splash.jpg" width="1024" height="768" />
> 
> 
>
> 
> 
> The cdv: prefix in the only clean way to get to something useful in 4.0
>

In 4.0, it becomes:

RE: cordova launcher icon support https://github.com/apache/cordova-cli/pull/126

2014-02-21 Thread Jonathan Bond-Caron 
On Thu Feb 20 04:07 AM, Axel Nennker wrote:
> How about this strategy:
> 
> project_dir/config.xml
> - no new elements in config.xml like cdv:icon
> - no new attributes in icon element in config.xml like cdv:platform or
> gap:platform
> - do not invent stuff we have to support for the rest of our life.
> 
> On all platforms:
> - if config.xml contains a  without any attributes 
> like
> width and heigth, then copy that src to to all platform specific  locations 
> where

Would this work:





   
 

The cdv: prefix in the only clean way to get to something useful in 4.0

Re: BlackBerry 10 - config.xml iicon entries are not filtered for gap:platform

2014-02-21 Thread Bryan Higgins 
I'd like to see config.xml have a platform tag similar to plugin.xml.
Neither Cordova nor BlackBerry native tools should understand PhoneGap
attributes.


On Thu, Feb 20, 2014 at 5:26 PM, Don Coleman  wrote:

> I have a project that uses PhoneGap build for iOS and Android, and uses
> Cordova to build for BlackBerry 10.
>
> The icons are specified in config.xml
>
> 
> gap:density="ldpi" />
> gap:density="mdpi" />
> gap:density="hdpi" />
> gap:density="xhdpi" />
>  gap:platform="blackberry" />
>  gap:platform="blackberry" gap:state="hover"/>
> 
>
> When the bar file is built, the Entry-Point-Icon Manifest entry is
> incorrect
>
> $ unzip -p platforms/blackberry10/build/device/bb10app.bar
> META-INF/MANIFEST.MF | grep Entry
>
> Entry-Point: WEBWORKS_VERSION=2.0.0 CONSOLE_MODE=slog2
> CASCADES_THEME=default app/native/wwe
> Entry-Point-Type: Qnx/WebKit
> Entry-Point-Icon:
>
> {72x72}native/icon.png:{36x36}native/res/icon/android/icon-36-ldpi.png:{48x48}native/res/icon/android/icon-48-mdpi.png:{72x72}native/res/icon/android/icon-72-hdpi.png:{96x96}native/res/icon/android/icon-96-xhdpi.png:{80x80}native/res/icon/blackberry/icon-80.png:{57x57}n
> Entry-Point-Orientation: auto
>
>
> The app looks deploys OK locally and passes blackberry-barchecker, but
> BlackBerry Enterprise Server rejected the app due to this entry.
>
> I fixed the problem by preprocessing the config.xml before the blackberry10
> build.
>
> Entry-Point: WEBWORKS_VERSION=2.0.0 CASCADES_THEME=default app/native/wwe
> Entry-Point-Type: Qnx/WebKit
> Entry-Point-Icon: native/res/icon/blackberry/icon-80.png
> Entry-Point-Orientation: auto
>
>
> Is this a problem that Cordova should handle? Or is it a problem with the
> blackberry-nativepackager?
>

CB-3208 [FFOS] 1.1 had issues with mozContact.prototype

2014-02-21 Thread Piotr Zalewa 

Please pull
https://github.com/apache/cordova-plugin-contacts/pull/21

--
Piotr Zalewa
Mozilla

CB-4846

2014-02-21 Thread Erik Jan de Wit 
Hi,

I’ve created an initial version for 
https://issues.apache.org/jira/browse/CB-4846 the plugin is located at 
https://github.com/edewit/cordova-background-plugin

Cheers,
Erik Jan