Re: Introductory Developer Email

[Andrew Grieve]

Awesome! Welcome to the team!


On Mon, Jan 6, 2014 at 3:40 PM, Brian LeRoux  wrote:

> Right on, welcome to the fray Josh.
>
>
> On Mon, Jan 6, 2014 at 3:31 PM, Anis KADRI  wrote:
>
> > Welcome Josh!
> >
> >
> > On Mon, Jan 6, 2014 at 9:20 AM, Josh Bavari  wrote:
> >
> > > Hello fellow Cordova Devs,
> > >
> > > I have been using PhoneGap / Cordova for about the last few years and
> > love
> > > that the project is ever evolving. I would like to help contribute to
> the
> > > Cordova project as well to help give back some of what was freely given
> > to
> > > myself.
> > >
> > > Some of my hobbies include mobile development (im guessing you already
> > knew
> > > hybrid apps), coding in Ruby and Javascript, process automation, and
> > > speaking / mentoring others.
> > >
> > > I hope to be chatting with many of you and contributing on issues that
> I
> > > myself find or that others may have an urgent priority for.
> > >
> > > Thanks, and may we build a better future.
> > >
> > >
> > > --
> > > "Clear thoughts produce clear results."
> > > Josh Bavari
> > > Application Developer
> > > Phone: 405-509-9448
> > > Cell: 405-812-0496
> > > Email: jbav...@gmail.com
> > >
> >
>

Re: Plugin Version Control Workflow

[Ross Gerbasi]

Hey Andrey,

Much like you said 99% of the users will want to ignore platforms and
plugins from version control. Making this work properly would not stop
someone from including them if they wanted to. If your workflow is better
including those folders you would have no problem doing so.

Ideally though if you can keep your custom code off in plugins, even if
they are not public plugins, would be ideal. Also as Dan mentioned you can
look into hooks to help modify platforms as needed.

Again though if you find checking everything in easier thats cool but the
CLI should be setup in a way that we do not need to.



On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore  wrote:

> Hi Andrey,
>
> I have worked on two small, simple Cordova applications, but we still at
> times had to modify platform specific code.  Not much, but some
> (AppDelegate.m for the iOS app, and the DroidGap subclass for Android--this
> is a 2.9.x project for now).
>
> Here's my solutions to your issues.
> * if you need to modify native plugin code, you should fork the repo and
> manage your changes via a git project, not in your project.
>
> If you use a recent enough version of Cordova, you can even pull plugins
> off git branches ( see https://issues.apache.org/jira/browse/CB-4981 ) so
> you could have different versions of your apps for different clients pull
> different branches of the same plugin.
>
> * if you need to modify code under platforms, use an after_platform_add
> hook, and keep your customized platform files elsewhere in your project
> tree.
>
> This way, you aren't version controlling everything, just what you've had
> to change.  Of course, when the Cordova platform changes underneath you
> (perhaps a new method is added to AppDelegate.m, and the version you have
> in source control overwrites that), you need to check these files
> carefully.  But when you version control everything and you upgrade, you
> have to merge in your custom changes into the new Cordova code in the same
> careful manner, plus you are carrying around everything else under
> platforms.
>
> Of course, I'm a big believer in the CLI, having everyone use the entire
> CLI toolchain, and treating everything under platforms and plugins as
> derived code that you can replace at any time.  If this isn't how you
> develop (if you prefer the 'native project dev' workflow, for example),
> then this may not work for you.
>
> Thanks.
> Dan
>
> PS Can you explain how keeping all the code in source control makes your
> merges as you move from Cordova version to Cordova version easier?  To me,
> that would seem to make them more difficult.
>
>
>
>
>
> On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <
> kant2...@googlemail.com> wrote:
>
> About plugin and platform version control.
> I heard a lot about that, and confused why you think that everybody would
> like to remove ./plugins and ./platforms folders from source control. I do
> agree that this is most likely the case for the simple applications and for
> the maybe 99% of current Cordova users, but I don't believe that this is
> truly important for the Cordova as the ecosystem for the cross-platform of
> the mobile development.
>
> Let me explain why I think that keep ./platforms and ./plugins under source
> control very important. I would base my reasoning on my current project
> needs.
> I currently develop 2 similar products for different clients from the same
> domain. I understand that in future I will have another clients from same
> problem domain which would like to have similar applications, just with
> different design. So I take the route of having 1 product line and
> customization of that product line for each client, depends on their needs.
> This is client facing application, so I would like to cover as much mobile
> platforms as possible with minimum amount of efforts. Currently I support
> only Android and iOS platforms, but envision that my clients will expand to
> the Windows Phone soon, and maybe I will force them to support Tizen in
> next year if that platform would be world-wide popular.
> I position my self as
> a) heavy Cordova user
> b) middle/low platform specific development. (I have to go deep in each
> platform, but that's not priority for me as Cordova users)
> I maintain 3 Git branches. 1 branch for core product and 2 branches for
> each client. In each branch I keep, platform specific code for the
> application (cordova-platform-ios/android code), Cordova plugins code +
> plugins developed specifically to this application.
> I definitely sure that I will need to add some functionality to the core
> platforms, either iOS or Android which will benefit the my application. I
> would try to push to the core Cordova as much as I can, but possible that
> not all contribution would be useful for the Cordova. Either way I plan for
> update to next version of Cordova (3.4, or 3.5 whenether). To keep my
> changes, which I add to current version of Cordova (3.3) and make update to
> 3.4 and later 

Camera Usage Causes Memory Warnings

[Brian Zitzow]

Hi,

I'm hoping to get some help with the camera usage causing memory warnings
and an eventual crashing of the application.

I've filed a bug with details here:

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

Re: Plugin Version Control Workflow

[Dan Moore]

Hi Andrey,

I have worked on two small, simple Cordova applications, but we still at times 
had to modify platform specific code.  Not much, but some (AppDelegate.m for 
the iOS app, and the DroidGap subclass for Android--this is a 2.9.x project for 
now).

Here's my solutions to your issues.
* if you need to modify native plugin code, you should fork the repo and manage 
your changes via a git project, not in your project.  

If you use a recent enough version of Cordova, you can even pull plugins off 
git branches ( see https://issues.apache.org/jira/browse/CB-4981 ) so you could 
have different versions of your apps for different clients pull different 
branches of the same plugin.

* if you need to modify code under platforms, use an after_platform_add hook, 
and keep your customized platform files elsewhere in your project tree.  

This way, you aren't version controlling everything, just what you've had to 
change.  Of course, when the Cordova platform changes underneath you (perhaps a 
new method is added to AppDelegate.m, and the version you have in source 
control overwrites that), you need to check these files carefully.  But when 
you version control everything and you upgrade, you have to merge in your 
custom changes into the new Cordova code in the same careful manner, plus you 
are carrying around everything else under platforms. 

Of course, I'm a big believer in the CLI, having everyone use the entire CLI 
toolchain, and treating everything under platforms and plugins as derived code 
that you can replace at any time.  If this isn't how you develop (if you prefer 
the 'native project dev' workflow, for example), then this may not work for you.

Thanks.
Dan

PS Can you explain how keeping all the code in source control makes your merges 
as you move from Cordova version to Cordova version easier?  To me, that would 
seem to make them more difficult.





On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov  
wrote:
 
About plugin and platform version control.
I heard a lot about that, and confused why you think that everybody would
like to remove ./plugins and ./platforms folders from source control. I do
agree that this is most likely the case for the simple applications and for
the maybe 99% of current Cordova users, but I don't believe that this is
truly important for the Cordova as the ecosystem for the cross-platform of
the mobile development.

Let me explain why I think that keep ./platforms and ./plugins under source
control very important. I would base my reasoning on my current project
needs.
I currently develop 2 similar products for different clients from the same
domain. I understand that in future I will have another clients from same
problem domain which would like to have similar applications, just with
different design. So I take the route of having 1 product line and
customization of that product line for each client, depends on their needs.
This is client facing application, so I would like to cover as much mobile
platforms as possible with minimum amount of efforts. Currently I support
only Android and iOS platforms, but envision that my clients will expand to
the Windows Phone soon, and maybe I will force them to support Tizen in
next year if that platform would be world-wide popular.
I position my self as
a) heavy Cordova user
b) middle/low platform specific development. (I have to go deep in each
platform, but that's not priority for me as Cordova users)
I maintain 3 Git branches. 1 branch for core product and 2 branches for
each client. In each branch I keep, platform specific code for the
application (cordova-platform-ios/android code), Cordova plugins code +
plugins developed specifically to this application.
I definitely sure that I will need to add some functionality to the core
platforms, either iOS or Android which will benefit the my application. I
would try to push to the core Cordova as much as I can, but possible that
not all contribution would be useful for the Cordova. Either way I plan for
update to next version of Cordova (3.4, or 3.5 whenether). To keep my
changes, which I add to current version of Cordova (3.3) and make update to
3.4 and later easier I keep all code in the source control to make all my
future merges easier. Same rules apply to the plugins,maybe I add some
code/fixes to plugins, or not don't matter - I have to plan for that.
I would like to contribute to Cordova everything what will benefit the
community to meet my selfish goals:
I want to make my upgrade path as straightforward as possible, for platform
code and for plugins code.

Maybe I was too verbose, but that was just to explain that I plan to align
my long-term goals with Cordova's long-term goals. I try to gave more
explanation, so you guys could plan not only for people which create
projects which are working on the specific version of Cordova, but also for
the guys which want to nurture their product together with Cordova.

I plainly don't see:
a) how I could work on my product

Re: Plugin Version Control Workflow

[Andrey Kurdumov]

About plugin and platform version control.
I heard a lot about that, and confused why you think that everybody would
like to remove ./plugins and ./platforms folders from source control. I do
agree that this is most likely the case for the simple applications and for
the maybe 99% of current Cordova users, but I don't believe that this is
truly important for the Cordova as the ecosystem for the cross-platform of
the mobile development.

Let me explain why I think that keep ./platforms and ./plugins under source
control very important. I would base my reasoning on my current project
needs.
I currently develop 2 similar products for different clients from the same
domain. I understand that in future I will have another clients from same
problem domain which would like to have similar applications, just with
different design. So I take the route of having 1 product line and
customization of that product line for each client, depends on their needs.
This is client facing application, so I would like to cover as much mobile
platforms as possible with minimum amount of efforts. Currently I support
only Android and iOS platforms, but envision that my clients will expand to
the Windows Phone soon, and maybe I will force them to support Tizen in
next year if that platform would be world-wide popular.
I position my self as
a) heavy Cordova user
b) middle/low platform specific development. (I have to go deep in each
platform, but that's not priority for me as Cordova users)
I maintain 3 Git branches. 1 branch for core product and 2 branches for
each client. In each branch I keep, platform specific code for the
application (cordova-platform-ios/android code), Cordova plugins code +
plugins developed specifically to this application.
I definitely sure that I will need to add some functionality to the core
platforms, either iOS or Android which will benefit the my application. I
would try to push to the core Cordova as much as I can, but possible that
not all contribution would be useful for the Cordova. Either way I plan for
update to next version of Cordova (3.4, or 3.5 whenether). To keep my
changes, which I add to current version of Cordova (3.3) and make update to
3.4 and later easier I keep all code in the source control to make all my
future merges easier. Same rules apply to the plugins,maybe I add some
code/fixes to plugins, or not don't matter - I have to plan for that.
I would like to contribute to Cordova everything what will benefit the
community to meet my selfish goals:
I want to make my upgrade path as straightforward as possible, for platform
code and for plugins code.

Maybe I was too verbose, but that was just to explain that I plan to align
my long-term goals with Cordova's long-term goals. I try to gave more
explanation, so you guys could plan not only for people which create
projects which are working on the specific version of Cordova, but also for
the guys which want to nurture their product together with Cordova.

I plainly don't see:
a) how I could work on my product not keeping ./platforms and ./plugins
directories in the source control, and
b) why I should don't use Cordova CLI to update contents of my ./platforms
and ./plugins folders. I think that these tool has a good fit for basic
housekeeping of the files/plugins. Don't want to manually fiddle with
content of plugins for each platform and use plugman/cordova executables to
do the job.

Hopefully I was enough verbose to explain why I have needs what I have now,
and not too verbose so you flood in details.

To summarize my input is:
1. Keep tools that way, that it could work either when ./plugins,
./platforms in source control, or when these folders not in the VCS.
2. Take into account that people may want to customize Cordova distribution
and have path to future upgrades.
3. I want to take responsibility for some burden which this way could
potentially create for you guys,

Andrey Kurdyumov.



2014/1/7 Braden Shepherdson 

> I've wanted to add Cordova plugin dependencies to the app's top-level
> config.xml for a long time, but it's never reached the top of my
> priorities. I think with that support, we can avoid checking in ./plugins/
> and ./platforms altogether for 99% of app developers. If it doesn't solve
> anyone's use case, I'd love to hear about it.
>
> Braden
>
>
> On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi  wrote:
>
> > CB-4624 is exactly what I am looking for. I am not sure if it should be
> > config.xml or some other config file, it probably doesn't matter much
> when
> > it comes down to it. Is there any rules currently in place, like CLI
> > doesn't touch config.xml?
> >
> >
> > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve  > >wrote:
> >
> > > I think https://issues.apache.org/jira/browse/CB-4624 is the relevant
> > > issue
> > > here. Please add comments to it if it's not spec'ed or good enough.
> > >
> > > Also related is https://issues.apache.org/jira/browse/CB-5006 - meant
> to
> > > address local repos of plugins.

Re: Introductory Developer Email

[Brian LeRoux]

Right on, welcome to the fray Josh.


On Mon, Jan 6, 2014 at 3:31 PM, Anis KADRI  wrote:

> Welcome Josh!
>
>
> On Mon, Jan 6, 2014 at 9:20 AM, Josh Bavari  wrote:
>
> > Hello fellow Cordova Devs,
> >
> > I have been using PhoneGap / Cordova for about the last few years and
> love
> > that the project is ever evolving. I would like to help contribute to the
> > Cordova project as well to help give back some of what was freely given
> to
> > myself.
> >
> > Some of my hobbies include mobile development (im guessing you already
> knew
> > hybrid apps), coding in Ruby and Javascript, process automation, and
> > speaking / mentoring others.
> >
> > I hope to be chatting with many of you and contributing on issues that I
> > myself find or that others may have an urgent priority for.
> >
> > Thanks, and may we build a better future.
> >
> >
> > --
> > "Clear thoughts produce clear results."
> > Josh Bavari
> > Application Developer
> > Phone: 405-509-9448
> > Cell: 405-812-0496
> > Email: jbav...@gmail.com
> >
>

Re: Introductory Developer Email

[Anis KADRI]

Welcome Josh!


On Mon, Jan 6, 2014 at 9:20 AM, Josh Bavari  wrote:

> Hello fellow Cordova Devs,
>
> I have been using PhoneGap / Cordova for about the last few years and love
> that the project is ever evolving. I would like to help contribute to the
> Cordova project as well to help give back some of what was freely given to
> myself.
>
> Some of my hobbies include mobile development (im guessing you already knew
> hybrid apps), coding in Ruby and Javascript, process automation, and
> speaking / mentoring others.
>
> I hope to be chatting with many of you and contributing on issues that I
> myself find or that others may have an urgent priority for.
>
> Thanks, and may we build a better future.
>
>
> --
> "Clear thoughts produce clear results."
> Josh Bavari
> Application Developer
> Phone: 405-509-9448
> Cell: 405-812-0496
> Email: jbav...@gmail.com
>

Introductory Developer Email

[Josh Bavari]

Hello fellow Cordova Devs,

I have been using PhoneGap / Cordova for about the last few years and love
that the project is ever evolving. I would like to help contribute to the
Cordova project as well to help give back some of what was freely given to
myself.

Some of my hobbies include mobile development (im guessing you already knew
hybrid apps), coding in Ruby and Javascript, process automation, and
speaking / mentoring others.

I hope to be chatting with many of you and contributing on issues that I
myself find or that others may have an urgent priority for.

Thanks, and may we build a better future.


-- 
"Clear thoughts produce clear results."
Josh Bavari
Application Developer
Phone: 405-509-9448
Cell: 405-812-0496
Email: jbav...@gmail.com

Re: IDE tweaks for CLI

[Michal Mocny]

(More OT: I've gone through my fourth damaged microUSB cable on this last
road trip.  They bend so easily in the car.)


On Mon, Jan 6, 2014 at 3:17 PM, Joe Bowser  wrote:

> On Mon, Jan 6, 2014 at 12:03 PM, Braden Shepherdson 
> wrote:
> > I have had a patchy history of trying to deploy to simulators and devices
> > using the CLI commands, but it may be something about my setup (eg. my
> HTC
> > One frequently drops out of the ADB devices list even though it's still
> > plugged in) or that I have only used it occasionally across many CLI
> > versions and my own patches and so on. If it's working for everyday users
> > (I know it's working for our CI) then that's great.
> >
>
> This may be OT, but this sounds like a hardware problem.  Does the USB
> Bus have enough power to support these devices? Is the MicroUSB cable
> connected properly?  Seriously, MicroUSB is terrible since the ports
> will eventually wear out, and the plugs bend if you put any stress on
> them (i.e. Device Wall).
>

Re: IDE tweaks for CLI

[Joe Bowser]

On Mon, Jan 6, 2014 at 12:03 PM, Braden Shepherdson  wrote:
> I have had a patchy history of trying to deploy to simulators and devices
> using the CLI commands, but it may be something about my setup (eg. my HTC
> One frequently drops out of the ADB devices list even though it's still
> plugged in) or that I have only used it occasionally across many CLI
> versions and my own patches and so on. If it's working for everyday users
> (I know it's working for our CI) then that's great.
>

This may be OT, but this sounds like a hardware problem.  Does the USB
Bus have enough power to support these devices? Is the MicroUSB cable
connected properly?  Seriously, MicroUSB is terrible since the ports
will eventually wear out, and the plugs bend if you put any stress on
them (i.e. Device Wall).

Re: IDE tweaks for CLI

[Michal Mocny]

We've quibbled over this before.  Regardless of your preference or
philosophy, at least some users are choosing/expecting to use IDE's and
then complaining about it.

I'm all for removing the barriers to all-CLI all the time (I'm also a "vim
guy"), but these changes significantly appease confusion for some subset of
our users, don't break anything, don't add noticeable overhead, and have
developer support.. so why wouldn't we endorse the improvements?

-Michal


On Mon, Jan 6, 2014 at 2:26 PM, Brian LeRoux  wrote:

> I'm sorry, what problems do you really have with the CLI for
> building/deploying? I have none nor see any issues that require slippers.
> ;)
>
> When I train people about Cordova based dev I always teach them the CLI and
> to use a text editor. Most are using Sublime (not Xcode) and many are
> rolling into a Grunt workflow (not Ant!).
>
> I suspect the majority of people using IDE's are actually our committers
> and not the web community user base.
>
>
> On Mon, Jan 6, 2014 at 11:11 AM, Braden Shepherdson  >wrote:
>
> > The unfortunate part is that Eclipse and Xcode are also (more or less)
> the
> > build systems for iOS and Android. You can build from CLI, and even
> deploy
> > from the CLI if the stars align and you have your ruby slippers on the
> > correct feet, but in practice most people are launching from IDEs. That
> > makes it tempting to use them to edit the files in the project, when in
> > fact one shouldn't be editing any of those files by hand, native or web.
> >
> > I'm glad to see some progress being made; this is easily the biggest user
> > training problem faced by the CLI workflow.
> >
> > Braden
> >
> >
> > On Thu, Jan 2, 2014 at 10:32 PM, Tommy Williams 
> > wrote:
> >
> > > I'm with you, Brian... CLI for CLI, project scripts for IDEs. Anything
> > else
> > > will just lead to madness..
> > > On 03/01/2014 12:21 pm, "Brian LeRoux"  wrote:
> > >
> > > > idk, if ppl want to use the cli I would reccomend using a text editor
> > and
> > > > our build chain
> > > >
> > > > if they want to use IDE's then they should not use the cli and just
> use
> > > the
> > > > project scripts
> > > >
> > > > (at least, this was the intent of the design as I originally saw it)
> > > >
> > > > not sure I see much benefit to making the cli ultra configurable
> > > >
> > > >
> > > > On Thu, Jan 2, 2014 at 4:10 PM, Andrew Grieve 
> > > > wrote:
> > > >
> > > > > We've had a bunch of users confused by Xcode and Eclipse showing
> only
> > > the
> > > > > output www/ and not the www/ that they are supposed to edit.
> > > > >
> > > > > There's bugs tracking addressing this for:
> > > > > iOS: https://issues.apache.org/jira/browse/CB-5397
> > > > > Android: https://issues.apache.org/jira/browse/CB-5715
> > > > >
> > > > > I've now taken a stab at addressing both of them through adding in
> > > > > references to the root www/, merges/ and config.xml for CLI
> projects
> > > > (using
> > > > > a separate project template for normal vs CLI projects).
> > > > >
> > > > > For Xcode, the build still works fine if you delete the reference
> to
> > > the
> > > > > output www/, but I've left it in by default.
> > > > > For Eclipse, there's no such option.
> > > > >
> > > > > If anyone wants to give it a whirl & provide feedback, that'd be
> > great!
> > > > >
> > > > > Andrew
> > > > >
> > > >
> > >
> >
>

Re: Moving www/config.xml -> config.xml (within CLI)

[Michal Mocny]

After discussing this and reading the other thread (on config.json
movement), I agree this is not the time for the rename.


On Mon, Jan 6, 2014 at 2:58 PM, Andrew Grieve  wrote:

> 1) Good point. Makes sense to me.
>
> 2) I think this is a tougher call. In on context, it does make more sense
> as "app.xml", since "config.xml" is the thing you're generating as an
> output. OTOH, there are a lot of tutorials & blog posts that say "put FOO
> in your config.xml", and so renaming it would be confusing in this context.
>
>
> On Mon, Jan 6, 2014 at 11:30 AM, Michal Mocny  wrote:
>
>> 1) Wouldn't it make more sense to default to the root config.xml if both
>> are present?  If you create a new project and import an old www project
>> using a new CLI (--source or --link), you would get both configuration
>> files (one at the root created by the template, and one inside your
>> imported www).  Wouldn't you expect to use the new config file in this
>> case, perhaps with a warning to delete the old one?  Not a big deal I guess
>> if you have a warning in either case.
>> 2) Do we want to rename config.xml to app.xml (or something else) to
>> finally kill the confusion between "platform config.xml" vs "project
>> config.xml"?
>>
>>
>> On Fri, Jan 3, 2014 at 1:52 PM, Andrew Grieve wrote:
>>
>>> Looks like there's already a JIRA for this:
>>>
>>> https://issues.apache.org/jira/browse/CB-4910
>>>
>>>
>>>
>>> On Thu, Jan 2, 2014 at 10:35 AM, Andrew Grieve 
>>> wrote:
>>>
>>> > I'll make a JIRA issue on Tuesday and paste the link to it here.
>>> >
>>> >
>>> > On Thu, Jan 2, 2014 at 10:32 AM, Ross Gerbasi 
>>> wrote:
>>> >
>>> >> Did this make it to jira? I also think its a good idea to pull
>>> config.xml
>>> >> out of the www root. Anyway to track this one?
>>> >>
>>> >>
>>> >> On Mon, Dec 30, 2013 at 1:51 PM, Dick Van den Brink <
>>> >> d_vandenbr...@outlook.com> wrote:
>>> >>
>>> >> > I think it is a a good idea! So a +1
>>> >> >
>>> >> > Sent from my Windows Phone
>>> >> > 
>>> >> > From: Axel Nennker
>>> >> > Sent: 12/30/2013 20:47
>>> >> > To: dev
>>> >> > Subject: Re: Moving www/config.xml -> config.xml (within CLI)
>>> >> >
>>> >> > I support this proposal.
>>> >> >
>>> >> > When I started work on CB-2606
>>> >> > https://issues.apache.org/jira/browse/CB-2606I noticed that the
>>> >> > element 
>>> >> > suggests that icons are put next to config.xml as well.
>>> >> > When config.xml is in the project root it becomes more natural to
>>> put
>>> >> icons
>>> >> > in /res/icons//icon.png
>>> >> >
>>> >> > -Axel
>>> >> >
>>> >> > ps:
>>> >> > I need opinions on my current implementation of CB-2606.
>>> >> > https://github.com/AxelNennker/cordova-cli
>>> >> > Please chime in to the email thread with the subject "Started
>>> >> Implementing
>>> >> > CB-2606 Add support for >> >> >
>>> >> >
>>> >> >
>>> >> > 2013/12/30 Andrew Grieve 
>>> >> >
>>> >> > > I thought this was previously discussed, but I can't find any JIRA
>>> >> issues
>>> >> > > or old emails about it.
>>> >> > >
>>> >> > > Proposal:
>>> >> > > For CLI projects:
>>> >> > > - Use www/config.xml if it exists
>>> >> > > - Otherwise use ./config.xml
>>> >> > > - Change the project template to use ./config.xml by default
>>> >> > >
>>> >> > >
>>> >> > > Reasons:
>>> >> > > - Paths in config.xml are relative to project root
>>> >> > > - Prevents a copy of config.xml ended up in platforms/*/www
>>> >> > > - Manifests are generally found at the top-level of projects.
>>> >> > >
>>> >> > >
>>> >> > > Sound good? If so I'll make an issue and work on this. Since it's
>>> >> > holidays,
>>> >> > > will wait until next week Tuesday (Jan 7) to proceed.
>>> >> > >
>>> >> > > Andrew
>>> >> > >
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>

Re: Moving .cordova/config.json -> cordova.json

[Brian LeRoux]

ya agreed, we should aim to do something early Feb once everyone is back
into the the flow


On Mon, Jan 6, 2014 at 11:59 AM, Michal Mocny  wrote:

> If we don't add a config.json by default, we need a new strategy for
> looking up paths for the root.
>
> I don't like naming the top-level config "config.xml", but after some
> thoughts on it, I don't think we should rename it just right now.  There
> are a lot of changes that would need to go along with that rename for it to
> make any sense.  I also agree with Brian that what we really need is to
> step back and consider an entirely better solution rather than something
> incremental.  Perhaps this is good subject matter for the next hangout /
> meet-up.
>
> -Michal
>
>
> On Fri, Jan 3, 2014 at 2:43 PM, Brian LeRoux  wrote:
>
> > probably a good idea for the moment / at some we will have a config file
> > reckoning!
> >
> >
> > On Fri, Jan 3, 2014 at 11:34 AM, Andrew Grieve 
> > wrote:
> >
> > > Okay, yeah, reading that back to myself and it seems like a bad idea
> > > (config.xml->app.xml). Probably would just add to confusion.
> > >
> > > So, top-level config.xml and top-level cordova.json.
> > >
> > > Maybe I could add to this that we don't create a cordova.json by
> default,
> > > since 99% most people shouldn't need it.
> > >
> > >
> > > On Fri, Jan 3, 2014 at 2:31 PM, Brian LeRoux  wrote:
> > >
> > > > actually, let me put this another way: I support .cordova/config.json
> > ->
> > > > cordova.json but I am not really interested in changing the name of
> > > > ./www/config.xml to ./www/app.xml
> > > >
> > > > ...feels to me we could consolidate this entire sitation with a
> single
> > > well
> > > > crafted configuration file (at the top level). ideally we have more
> > > > convention than configuration. feels like we have too many footguns
> to
> > > ease
> > > > our personal dev workflows as is than consideration for people
> actually
> > > > building apps.
> > > >
> > > >
> > > > On Fri, Jan 3, 2014 at 11:25 AM, Brian LeRoux  wrote:
> > > >
> > > > > Sorry, I completely do not understand this at all. The proposal is
> to
> > > > > change the name of config.xml to ease confusions and add a new top
> > > level
> > > > > config file?
> > > > >
> > > > >
> > > > > On Fri, Jan 3, 2014 at 11:15 AM, Andrew Grieve <
> agri...@chromium.org
> > > > >wrote:
> > > > >
> > > > >> Just spoke with Ian and I now understand his point about
> > cordova.json
> > > > >> being
> > > > >> for build environment, whereas config.xml is for application
> things.
> > > > >>
> > > > >> So, do think it'd be bad to have a cordova.json and a config.xml
> > right
> > > > >> next
> > > > >> to each other.
> > > > >>
> > > > >> How about:
> > > > >>
> > > > >> config.xml -> app.xml
> > > > >>  - This will (hopefully) ease confusion about CLI's config.xml vs.
> > > > >> platforms/ config.xml files.
> > > > >>  - E.g. we're adding icon & splashscreen support to CLI's
> > config.xml,
> > > > but
> > > > >> not for non-CLI config.xml files
> > > > >>  - E.g. app.xml and plugin.xml is where you make edits, config.xml
> > is
> > > > >> what's read at runtime.
> > > > >>
> > > > >> .cordova/config.json -> cordova.json
> > > > >>
> > > > >> Also - JIRA for this is
> > https://issues.apache.org/jira/browse/CB-4910
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux  wrote:
> > > > >>
> > > > >> > I understood and read it too Gorkem.
> > > > >> >
> > > > >> > I was (poorly) suggesting we look at the issue of configuration
> > in a
> > > > >> > complete view. Due to backwards compatibility we will be adding
> a
> > > new
> > > > >> file
> > > > >> > and the code to support the old file will be around a while.
> > > > >> >
> > > > >> > We can probably roll a whole lot more into a single file. What
> I"m
> > > not
> > > > >> sure
> > > > >> > about is what should and should not be.
> > > > >> >
> > > > >> >
> > > > >> > On Thu, Jan 2, 2014 at 12:31 PM, Gorkem Ercan <
> > > gorkem.er...@gmail.com
> > > > >> > >wrote:
> > > > >> >
> > > > >> > >
> > > > >> > > Reducing the number of configuration files is actually the
> goal
> > > > here.
> > > > >> > >
> > > > >> > > The abstraction is not a new one. It already exists and it is
> > part
> > > > of
> > > > >> the
> > > > >> > > $PROJECT/.cordova/config.json.
> > > > >> > > I am suggesting to move it to $HOME/.cordova/config.json so
> that
> > > we
> > > > no
> > > > >> > > longer need the
> > > > >> > > $PROJECT/.cordova/config.json and have only the cordova.xml to
> > > carry
> > > > >> > > project specific
> > > > >> > > properties.
> > > > >> > > --
> > > > >> > > Gorkem
> > > > >> > >
> > > > >> > >
> > > > >> > > On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote:
> > > > >> > > > Considering
> > http://wiki.apache.org/cordova/ConfigurationFilesI'm
> > > > >> not
> > > > >> > > sure
> > > > >> > > > we want more config either.
> > > > >> > > >
> > > > >> > > > Perhaps we n

Re: IDE tweaks for CLI

[Braden Shepherdson]

I'm glad to hear people are having success with IDE-less workflows. I'm a
vim guy through and through, and wish I didn't have to waste disk space or
memory on Xcode or Eclipse. I need them for native debugging, I suppose.

I have had a patchy history of trying to deploy to simulators and devices
using the CLI commands, but it may be something about my setup (eg. my HTC
One frequently drops out of the ADB devices list even though it's still
plugged in) or that I have only used it occasionally across many CLI
versions and my own patches and so on. If it's working for everyday users
(I know it's working for our CI) then that's great.

Braden


On Mon, Jan 6, 2014 at 2:26 PM, Brian LeRoux  wrote:

> I'm sorry, what problems do you really have with the CLI for
> building/deploying? I have none nor see any issues that require slippers.
> ;)
>
> When I train people about Cordova based dev I always teach them the CLI and
> to use a text editor. Most are using Sublime (not Xcode) and many are
> rolling into a Grunt workflow (not Ant!).
>
> I suspect the majority of people using IDE's are actually our committers
> and not the web community user base.
>
>
> On Mon, Jan 6, 2014 at 11:11 AM, Braden Shepherdson  >wrote:
>
> > The unfortunate part is that Eclipse and Xcode are also (more or less)
> the
> > build systems for iOS and Android. You can build from CLI, and even
> deploy
> > from the CLI if the stars align and you have your ruby slippers on the
> > correct feet, but in practice most people are launching from IDEs. That
> > makes it tempting to use them to edit the files in the project, when in
> > fact one shouldn't be editing any of those files by hand, native or web.
> >
> > I'm glad to see some progress being made; this is easily the biggest user
> > training problem faced by the CLI workflow.
> >
> > Braden
> >
> >
> > On Thu, Jan 2, 2014 at 10:32 PM, Tommy Williams 
> > wrote:
> >
> > > I'm with you, Brian... CLI for CLI, project scripts for IDEs. Anything
> > else
> > > will just lead to madness..
> > > On 03/01/2014 12:21 pm, "Brian LeRoux"  wrote:
> > >
> > > > idk, if ppl want to use the cli I would reccomend using a text editor
> > and
> > > > our build chain
> > > >
> > > > if they want to use IDE's then they should not use the cli and just
> use
> > > the
> > > > project scripts
> > > >
> > > > (at least, this was the intent of the design as I originally saw it)
> > > >
> > > > not sure I see much benefit to making the cli ultra configurable
> > > >
> > > >
> > > > On Thu, Jan 2, 2014 at 4:10 PM, Andrew Grieve 
> > > > wrote:
> > > >
> > > > > We've had a bunch of users confused by Xcode and Eclipse showing
> only
> > > the
> > > > > output www/ and not the www/ that they are supposed to edit.
> > > > >
> > > > > There's bugs tracking addressing this for:
> > > > > iOS: https://issues.apache.org/jira/browse/CB-5397
> > > > > Android: https://issues.apache.org/jira/browse/CB-5715
> > > > >
> > > > > I've now taken a stab at addressing both of them through adding in
> > > > > references to the root www/, merges/ and config.xml for CLI
> projects
> > > > (using
> > > > > a separate project template for normal vs CLI projects).
> > > > >
> > > > > For Xcode, the build still works fine if you delete the reference
> to
> > > the
> > > > > output www/, but I've left it in by default.
> > > > > For Eclipse, there's no such option.
> > > > >
> > > > > If anyone wants to give it a whirl & provide feedback, that'd be
> > great!
> > > > >
> > > > > Andrew
> > > > >
> > > >
> > >
> >
>

Re: Moving .cordova/config.json -> cordova.json

[Michal Mocny]

If we don't add a config.json by default, we need a new strategy for
looking up paths for the root.

I don't like naming the top-level config "config.xml", but after some
thoughts on it, I don't think we should rename it just right now.  There
are a lot of changes that would need to go along with that rename for it to
make any sense.  I also agree with Brian that what we really need is to
step back and consider an entirely better solution rather than something
incremental.  Perhaps this is good subject matter for the next hangout /
meet-up.

-Michal


On Fri, Jan 3, 2014 at 2:43 PM, Brian LeRoux  wrote:

> probably a good idea for the moment / at some we will have a config file
> reckoning!
>
>
> On Fri, Jan 3, 2014 at 11:34 AM, Andrew Grieve 
> wrote:
>
> > Okay, yeah, reading that back to myself and it seems like a bad idea
> > (config.xml->app.xml). Probably would just add to confusion.
> >
> > So, top-level config.xml and top-level cordova.json.
> >
> > Maybe I could add to this that we don't create a cordova.json by default,
> > since 99% most people shouldn't need it.
> >
> >
> > On Fri, Jan 3, 2014 at 2:31 PM, Brian LeRoux  wrote:
> >
> > > actually, let me put this another way: I support .cordova/config.json
> ->
> > > cordova.json but I am not really interested in changing the name of
> > > ./www/config.xml to ./www/app.xml
> > >
> > > ...feels to me we could consolidate this entire sitation with a single
> > well
> > > crafted configuration file (at the top level). ideally we have more
> > > convention than configuration. feels like we have too many footguns to
> > ease
> > > our personal dev workflows as is than consideration for people actually
> > > building apps.
> > >
> > >
> > > On Fri, Jan 3, 2014 at 11:25 AM, Brian LeRoux  wrote:
> > >
> > > > Sorry, I completely do not understand this at all. The proposal is to
> > > > change the name of config.xml to ease confusions and add a new top
> > level
> > > > config file?
> > > >
> > > >
> > > > On Fri, Jan 3, 2014 at 11:15 AM, Andrew Grieve  > > >wrote:
> > > >
> > > >> Just spoke with Ian and I now understand his point about
> cordova.json
> > > >> being
> > > >> for build environment, whereas config.xml is for application things.
> > > >>
> > > >> So, do think it'd be bad to have a cordova.json and a config.xml
> right
> > > >> next
> > > >> to each other.
> > > >>
> > > >> How about:
> > > >>
> > > >> config.xml -> app.xml
> > > >>  - This will (hopefully) ease confusion about CLI's config.xml vs.
> > > >> platforms/ config.xml files.
> > > >>  - E.g. we're adding icon & splashscreen support to CLI's
> config.xml,
> > > but
> > > >> not for non-CLI config.xml files
> > > >>  - E.g. app.xml and plugin.xml is where you make edits, config.xml
> is
> > > >> what's read at runtime.
> > > >>
> > > >> .cordova/config.json -> cordova.json
> > > >>
> > > >> Also - JIRA for this is
> https://issues.apache.org/jira/browse/CB-4910
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux  wrote:
> > > >>
> > > >> > I understood and read it too Gorkem.
> > > >> >
> > > >> > I was (poorly) suggesting we look at the issue of configuration
> in a
> > > >> > complete view. Due to backwards compatibility we will be adding a
> > new
> > > >> file
> > > >> > and the code to support the old file will be around a while.
> > > >> >
> > > >> > We can probably roll a whole lot more into a single file. What I"m
> > not
> > > >> sure
> > > >> > about is what should and should not be.
> > > >> >
> > > >> >
> > > >> > On Thu, Jan 2, 2014 at 12:31 PM, Gorkem Ercan <
> > gorkem.er...@gmail.com
> > > >> > >wrote:
> > > >> >
> > > >> > >
> > > >> > > Reducing the number of configuration files is actually the goal
> > > here.
> > > >> > >
> > > >> > > The abstraction is not a new one. It already exists and it is
> part
> > > of
> > > >> the
> > > >> > > $PROJECT/.cordova/config.json.
> > > >> > > I am suggesting to move it to $HOME/.cordova/config.json so that
> > we
> > > no
> > > >> > > longer need the
> > > >> > > $PROJECT/.cordova/config.json and have only the cordova.xml to
> > carry
> > > >> > > project specific
> > > >> > > properties.
> > > >> > > --
> > > >> > > Gorkem
> > > >> > >
> > > >> > >
> > > >> > > On Thu, Jan 02, 2014 at 12:16:57PM -0800, Brian LeRoux wrote:
> > > >> > > > Considering
> http://wiki.apache.org/cordova/ConfigurationFilesI'm
> > > >> not
> > > >> > > sure
> > > >> > > > we want more config either.
> > > >> > > >
> > > >> > > > Perhaps we need to think more comprehensively rather than
> > > proposing
> > > >> > more
> > > >> > > > abstractions.
> > > >> > > >
> > > >> > > >
> > > >> > > > On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan <
> > > >> gorkem.er...@gmail.com
> > > >> > > >wrote:
> > > >> > > >
> > > >> > > > >
> > > >> > > > > I think what I will describe here is more that what CLI
> > provides
> > > >> > today.
> > > >> > > > >
> > > >> > > > > An engine/lib has a version, id and a uri. On mo

Re: Moving www/config.xml -> config.xml (within CLI)

[Andrew Grieve]

1) Good point. Makes sense to me.

2) I think this is a tougher call. In on context, it does make more sense
as "app.xml", since "config.xml" is the thing you're generating as an
output. OTOH, there are a lot of tutorials & blog posts that say "put FOO
in your config.xml", and so renaming it would be confusing in this context.


On Mon, Jan 6, 2014 at 11:30 AM, Michal Mocny  wrote:

> 1) Wouldn't it make more sense to default to the root config.xml if both
> are present?  If you create a new project and import an old www project
> using a new CLI (--source or --link), you would get both configuration
> files (one at the root created by the template, and one inside your
> imported www).  Wouldn't you expect to use the new config file in this
> case, perhaps with a warning to delete the old one?  Not a big deal I guess
> if you have a warning in either case.
> 2) Do we want to rename config.xml to app.xml (or something else) to
> finally kill the confusion between "platform config.xml" vs "project
> config.xml"?
>
>
> On Fri, Jan 3, 2014 at 1:52 PM, Andrew Grieve wrote:
>
>> Looks like there's already a JIRA for this:
>>
>> https://issues.apache.org/jira/browse/CB-4910
>>
>>
>>
>> On Thu, Jan 2, 2014 at 10:35 AM, Andrew Grieve 
>> wrote:
>>
>> > I'll make a JIRA issue on Tuesday and paste the link to it here.
>> >
>> >
>> > On Thu, Jan 2, 2014 at 10:32 AM, Ross Gerbasi 
>> wrote:
>> >
>> >> Did this make it to jira? I also think its a good idea to pull
>> config.xml
>> >> out of the www root. Anyway to track this one?
>> >>
>> >>
>> >> On Mon, Dec 30, 2013 at 1:51 PM, Dick Van den Brink <
>> >> d_vandenbr...@outlook.com> wrote:
>> >>
>> >> > I think it is a a good idea! So a +1
>> >> >
>> >> > Sent from my Windows Phone
>> >> > 
>> >> > From: Axel Nennker
>> >> > Sent: 12/30/2013 20:47
>> >> > To: dev
>> >> > Subject: Re: Moving www/config.xml -> config.xml (within CLI)
>> >> >
>> >> > I support this proposal.
>> >> >
>> >> > When I started work on CB-2606
>> >> > https://issues.apache.org/jira/browse/CB-2606I noticed that the
>> >> > element 
>> >> > suggests that icons are put next to config.xml as well.
>> >> > When config.xml is in the project root it becomes more natural to put
>> >> icons
>> >> > in /res/icons//icon.png
>> >> >
>> >> > -Axel
>> >> >
>> >> > ps:
>> >> > I need opinions on my current implementation of CB-2606.
>> >> > https://github.com/AxelNennker/cordova-cli
>> >> > Please chime in to the email thread with the subject "Started
>> >> Implementing
>> >> > CB-2606 Add support for > >> >
>> >> >
>> >> >
>> >> > 2013/12/30 Andrew Grieve 
>> >> >
>> >> > > I thought this was previously discussed, but I can't find any JIRA
>> >> issues
>> >> > > or old emails about it.
>> >> > >
>> >> > > Proposal:
>> >> > > For CLI projects:
>> >> > > - Use www/config.xml if it exists
>> >> > > - Otherwise use ./config.xml
>> >> > > - Change the project template to use ./config.xml by default
>> >> > >
>> >> > >
>> >> > > Reasons:
>> >> > > - Paths in config.xml are relative to project root
>> >> > > - Prevents a copy of config.xml ended up in platforms/*/www
>> >> > > - Manifests are generally found at the top-level of projects.
>> >> > >
>> >> > >
>> >> > > Sound good? If so I'll make an issue and work on this. Since it's
>> >> > holidays,
>> >> > > will wait until next week Tuesday (Jan 7) to proceed.
>> >> > >
>> >> > > Andrew
>> >> > >
>> >> >
>> >>
>> >
>> >
>>
>
>

Re: Moving www/config.xml -> config.xml (within CLI)

[Michal Mocny]

1) Wouldn't it make more sense to default to the root config.xml if both
are present?  If you create a new project and import an old www project
using a new CLI (--source or --link), you would get both configuration
files (one at the root created by the template, and one inside your
imported www).  Wouldn't you expect to use the new config file in this
case, perhaps with a warning to delete the old one?  Not a big deal I guess
if you have a warning in either case.
2) Do we want to rename config.xml to app.xml (or something else) to
finally kill the confusion between "platform config.xml" vs "project
config.xml"?


On Fri, Jan 3, 2014 at 1:52 PM, Andrew Grieve  wrote:

> Looks like there's already a JIRA for this:
>
> https://issues.apache.org/jira/browse/CB-4910
>
>
>
> On Thu, Jan 2, 2014 at 10:35 AM, Andrew Grieve 
> wrote:
>
> > I'll make a JIRA issue on Tuesday and paste the link to it here.
> >
> >
> > On Thu, Jan 2, 2014 at 10:32 AM, Ross Gerbasi 
> wrote:
> >
> >> Did this make it to jira? I also think its a good idea to pull
> config.xml
> >> out of the www root. Anyway to track this one?
> >>
> >>
> >> On Mon, Dec 30, 2013 at 1:51 PM, Dick Van den Brink <
> >> d_vandenbr...@outlook.com> wrote:
> >>
> >> > I think it is a a good idea! So a +1
> >> >
> >> > Sent from my Windows Phone
> >> > 
> >> > From: Axel Nennker
> >> > Sent: 12/30/2013 20:47
> >> > To: dev
> >> > Subject: Re: Moving www/config.xml -> config.xml (within CLI)
> >> >
> >> > I support this proposal.
> >> >
> >> > When I started work on CB-2606
> >> > https://issues.apache.org/jira/browse/CB-2606I noticed that the
> >> > element 
> >> > suggests that icons are put next to config.xml as well.
> >> > When config.xml is in the project root it becomes more natural to put
> >> icons
> >> > in /res/icons//icon.png
> >> >
> >> > -Axel
> >> >
> >> > ps:
> >> > I need opinions on my current implementation of CB-2606.
> >> > https://github.com/AxelNennker/cordova-cli
> >> > Please chime in to the email thread with the subject "Started
> >> Implementing
> >> > CB-2606 Add support for  >> >
> >> >
> >> >
> >> > 2013/12/30 Andrew Grieve 
> >> >
> >> > > I thought this was previously discussed, but I can't find any JIRA
> >> issues
> >> > > or old emails about it.
> >> > >
> >> > > Proposal:
> >> > > For CLI projects:
> >> > > - Use www/config.xml if it exists
> >> > > - Otherwise use ./config.xml
> >> > > - Change the project template to use ./config.xml by default
> >> > >
> >> > >
> >> > > Reasons:
> >> > > - Paths in config.xml are relative to project root
> >> > > - Prevents a copy of config.xml ended up in platforms/*/www
> >> > > - Manifests are generally found at the top-level of projects.
> >> > >
> >> > >
> >> > > Sound good? If so I'll make an issue and work on this. Since it's
> >> > holidays,
> >> > > will wait until next week Tuesday (Jan 7) to proceed.
> >> > >
> >> > > Andrew
> >> > >
> >> >
> >>
> >
> >
>

Re: IDE tweaks for CLI

[Brian LeRoux]

I'm sorry, what problems do you really have with the CLI for
building/deploying? I have none nor see any issues that require slippers. ;)

When I train people about Cordova based dev I always teach them the CLI and
to use a text editor. Most are using Sublime (not Xcode) and many are
rolling into a Grunt workflow (not Ant!).

I suspect the majority of people using IDE's are actually our committers
and not the web community user base.


On Mon, Jan 6, 2014 at 11:11 AM, Braden Shepherdson wrote:

> The unfortunate part is that Eclipse and Xcode are also (more or less) the
> build systems for iOS and Android. You can build from CLI, and even deploy
> from the CLI if the stars align and you have your ruby slippers on the
> correct feet, but in practice most people are launching from IDEs. That
> makes it tempting to use them to edit the files in the project, when in
> fact one shouldn't be editing any of those files by hand, native or web.
>
> I'm glad to see some progress being made; this is easily the biggest user
> training problem faced by the CLI workflow.
>
> Braden
>
>
> On Thu, Jan 2, 2014 at 10:32 PM, Tommy Williams 
> wrote:
>
> > I'm with you, Brian... CLI for CLI, project scripts for IDEs. Anything
> else
> > will just lead to madness..
> > On 03/01/2014 12:21 pm, "Brian LeRoux"  wrote:
> >
> > > idk, if ppl want to use the cli I would reccomend using a text editor
> and
> > > our build chain
> > >
> > > if they want to use IDE's then they should not use the cli and just use
> > the
> > > project scripts
> > >
> > > (at least, this was the intent of the design as I originally saw it)
> > >
> > > not sure I see much benefit to making the cli ultra configurable
> > >
> > >
> > > On Thu, Jan 2, 2014 at 4:10 PM, Andrew Grieve 
> > > wrote:
> > >
> > > > We've had a bunch of users confused by Xcode and Eclipse showing only
> > the
> > > > output www/ and not the www/ that they are supposed to edit.
> > > >
> > > > There's bugs tracking addressing this for:
> > > > iOS: https://issues.apache.org/jira/browse/CB-5397
> > > > Android: https://issues.apache.org/jira/browse/CB-5715
> > > >
> > > > I've now taken a stab at addressing both of them through adding in
> > > > references to the root www/, merges/ and config.xml for CLI projects
> > > (using
> > > > a separate project template for normal vs CLI projects).
> > > >
> > > > For Xcode, the build still works fine if you delete the reference to
> > the
> > > > output www/, but I've left it in by default.
> > > > For Eclipse, there's no such option.
> > > >
> > > > If anyone wants to give it a whirl & provide feedback, that'd be
> great!
> > > >
> > > > Andrew
> > > >
> > >
> >
>

Re: IDE tweaks for CLI

[Braden Shepherdson]

The unfortunate part is that Eclipse and Xcode are also (more or less) the
build systems for iOS and Android. You can build from CLI, and even deploy
from the CLI if the stars align and you have your ruby slippers on the
correct feet, but in practice most people are launching from IDEs. That
makes it tempting to use them to edit the files in the project, when in
fact one shouldn't be editing any of those files by hand, native or web.

I'm glad to see some progress being made; this is easily the biggest user
training problem faced by the CLI workflow.

Braden


On Thu, Jan 2, 2014 at 10:32 PM, Tommy Williams  wrote:

> I'm with you, Brian... CLI for CLI, project scripts for IDEs. Anything else
> will just lead to madness..
> On 03/01/2014 12:21 pm, "Brian LeRoux"  wrote:
>
> > idk, if ppl want to use the cli I would reccomend using a text editor and
> > our build chain
> >
> > if they want to use IDE's then they should not use the cli and just use
> the
> > project scripts
> >
> > (at least, this was the intent of the design as I originally saw it)
> >
> > not sure I see much benefit to making the cli ultra configurable
> >
> >
> > On Thu, Jan 2, 2014 at 4:10 PM, Andrew Grieve 
> > wrote:
> >
> > > We've had a bunch of users confused by Xcode and Eclipse showing only
> the
> > > output www/ and not the www/ that they are supposed to edit.
> > >
> > > There's bugs tracking addressing this for:
> > > iOS: https://issues.apache.org/jira/browse/CB-5397
> > > Android: https://issues.apache.org/jira/browse/CB-5715
> > >
> > > I've now taken a stab at addressing both of them through adding in
> > > references to the root www/, merges/ and config.xml for CLI projects
> > (using
> > > a separate project template for normal vs CLI projects).
> > >
> > > For Xcode, the build still works fine if you delete the reference to
> the
> > > output www/, but I've left it in by default.
> > > For Eclipse, there's no such option.
> > >
> > > If anyone wants to give it a whirl & provide feedback, that'd be great!
> > >
> > > Andrew
> > >
> >
>

Re: Plugin Version Control Workflow

[Braden Shepherdson]

I've wanted to add Cordova plugin dependencies to the app's top-level
config.xml for a long time, but it's never reached the top of my
priorities. I think with that support, we can avoid checking in ./plugins/
and ./platforms altogether for 99% of app developers. If it doesn't solve
anyone's use case, I'd love to hear about it.

Braden


On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi  wrote:

> CB-4624 is exactly what I am looking for. I am not sure if it should be
> config.xml or some other config file, it probably doesn't matter much when
> it comes down to it. Is there any rules currently in place, like CLI
> doesn't touch config.xml?
>
>
> On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve  >wrote:
>
> > I think https://issues.apache.org/jira/browse/CB-4624 is the relevant
> > issue
> > here. Please add comments to it if it's not spec'ed or good enough.
> >
> > Also related is https://issues.apache.org/jira/browse/CB-5006 - meant to
> > address local repos of plugins.
> >
> >
> > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov <
> kant2...@googlemail.com
> > >wrote:
> >
> > > Hi all,
> > >
> > > Would be very helpful if you change formatting of the plugins manifest
> > > files (android.json, ios.json). Currently it is print all JSON string
> to
> > > the big single line, which difficult to merge when needed.
> > >
> >
>

Re: storage

[Jesse]

The key win I think is simply having a consistent implementation.
CanIUse reports that indexedDB is available on Android 4.4+ and every other
of our supported platforms, with a very notable exception of Mobile Safari.
Ultimately this is a plugin, and Parashuram is working on it, so I am sure
he would appreciate help.
To echo what Brian says, it is all currently possible, maybe just not as
consistently as some would like, but ultimately Cordova is really just the
bridge, the tools, and the container, so I don't think it is fair to call
it incomplete ... and pull requests are always welcome.




@purplecabbage
risingj.com


On Mon, Jan 6, 2014 at 9:43 AM, Brian LeRoux  wrote:

> I'm trying to not sound like a broken record but I still do not hear an
> actual use cases that is unique to IndexedDB. I understand that you like
> it, I do too, and the browsers will support it eventually in Cordova so
> effort spent there is not really a demonstrable win (to me) unless I hear a
> use case for it not currently possible (if not more appropriate) for
> reading and writing plain old text, JSON, or Blobs.
>
> IndexedDB is a structured key/value store. Files have names (keys) and
> values. IndexedDB provides a non blocking async read/write. So does our
> File API. Transactional support is not built into our File API so that
> might be something you'd want if reads/writes could conflict.
>
>
> On Sun, Jan 5, 2014 at 10:02 AM, venkata kiran surapaneni <
> svkir...@gmail.com> wrote:
>
> > +1 to Axel.
> >
> > Cordova is incomplete without providing support for indexeddb and
> websql. I
> > think most of the apps require local database. There are some frameworks
> > which provide different level of implementations. But those
> implementations
> > are usually designed for browsers and then enhanced for mobile support
> and
> > so has several limitations like not working when the application is
> > switched to background.
> >
> > Cordova should have a uniform wrapper on top of indexeddb and websql to
> > actually allow developers to create a cross platform apps, which is what
> > Cordova promises.
> >
>

Re: storage

[Brian LeRoux]

I'm trying to not sound like a broken record but I still do not hear an
actual use cases that is unique to IndexedDB. I understand that you like
it, I do too, and the browsers will support it eventually in Cordova so
effort spent there is not really a demonstrable win (to me) unless I hear a
use case for it not currently possible (if not more appropriate) for
reading and writing plain old text, JSON, or Blobs.

IndexedDB is a structured key/value store. Files have names (keys) and
values. IndexedDB provides a non blocking async read/write. So does our
File API. Transactional support is not built into our File API so that
might be something you'd want if reads/writes could conflict.


On Sun, Jan 5, 2014 at 10:02 AM, venkata kiran surapaneni <
svkir...@gmail.com> wrote:

> +1 to Axel.
>
> Cordova is incomplete without providing support for indexeddb and websql. I
> think most of the apps require local database. There are some frameworks
> which provide different level of implementations. But those implementations
> are usually designed for browsers and then enhanced for mobile support and
> so has several limitations like not working when the application is
> switched to background.
>
> Cordova should have a uniform wrapper on top of indexeddb and websql to
> actually allow developers to create a cross platform apps, which is what
> Cordova promises.
>