You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Jan Velecký <VV...@seznam.cz> on 2014/07/13 22:18:23 UTC
One platform development vs. Cordova CLI
Hello,
there is serious backlog when using CLI in case one platform development. In
this case is better to change platform project config.xml instead of whole
project config.xml. Problem is what prepare should do, and what prepare
actually do. (And prepare is also run if we do build.) At this moment,
prepare in CLI does clean & copy...
Also prepare does it in different way in Android, than in iOS.
On Android, config.xml and androidmanifest.xml is probably recreated
(destroy previous formatting, what a feature...) and then probably add
differences, so changes and new options are preserved, however nobody wanna
read it...
On iOS, config.xml is completely recreated, no any option is preserved...
So, there are 2 questions...
If is Android CLI too clever to do preserve changes created by user, why it
ruins my formatting (new lines, maybe also tabulators)?
Why is iOS CLI such a stupid? Why it is not able to do it like Android CLI
(at least)?
Re: One platform development vs. Cordova CLI
Posted by julio cesar sanchez <jc...@gmail.com>.
I think I've read somewhere you can change some things in the info.plist on
phonegap build, why can't we?
El martes, 15 de julio de 2014, tommy-carlos williams <to...@devgeeks.org>
escribió:
> Never said this stuff couldn’t be fixed.
>
> I have been actively advocating for it to be fixed.
>
> Only wanted to spread some light on this statement:
>
> If you're touching any non-www project files (that is *.xml,
> *.plist, *.m, *.java etc...) or are using an IDE you should not be using
> cordova-cli and switch to single platform development.
> - tommy
>
>
>
> On 15 July 2014 at 22:11:24, Axel Nennker (ignisvulpis@gmail.com
> <javascript:;>) wrote:
>
> From looking at the code it seems that versionCode is handled on Android:
>
> https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/metadata/android_parser.js#L225
>
> There is a email thread about minSdkVersion and an quite recent issue:
>
> https://issues.apache.org/jira/browse/CB-7114?jql=text%20~%20%22minSdkVersion%22
>
> So these could be fixed.
>
> Regarding signing info: I am using ant on top of cordova like: e.g.: create
> app from my template; install plugins, run
> Ant modifies ant.properties too. Currently not to include signing info but
> to modify the classpath because I need a lib at compile time that is not
> included into the apk (openmobileapi).
> Not sure wheter these two requirements (signing info, noexportlib) should
> be of config.xml...
> At least I am not doing this stuff manually.
>
>
>
>
>
>
> 2014-07-15 12:11 GMT+02:00 tommy-carlos williams <tommy@devgeeks.org
> <javascript:;>>:
>
> > Assuming that splash screens and icons finally work in 3.5.x (so, only as
> > of a few weeks ago… not everyone’s projects are that new) –
> >
> >
> > Android:
> >
> > AndroidManifest.xml:
> > android:versionCode
> > (and possibly) android:minSdkVersion
> >
> > ant.properties
> > android signing info
> >
> >
> > This is just off the top of my head.
> >
> > There are more in iOS as well (mostly the same ones, but others depending
> > on features… like provisioning profiles, etc)
> >
> > Then there are the platforms outside the “big two”… plenty there.
> >
> > - tommy
> >
> >
> > On 15 July 2014 at 14:44:05, Axel Nennker (ignisvulpis@gmail.com
> <javascript:;>) wrote:
> >
> > Could you please give an example which files you need to change and why?
> > (Preferably Android)
> >
> > Thanks
> > Axel
> > Am 15.07.2014 02:23 schrieb "tommy-carlos williams" <tommy@devgeeks.org
> <javascript:;>>:
> >
> > > Sooo.. translation:
> > >
> > > “If you aren’t just making a test / example app…”
> > >
> > > ??
> > >
> > > Unless a lot has changed that I don’t know about, it is still
> impossible
> > > to make an app all the way to market without modifying those non-www
> > files
> > > using the CLI.
> > >
> > > There are fantastic workarounds available (mostly hooks, etc) for the
> CLI
> > > until we get it to the point where the platforms/* and plugins/*
> folders
> > > are build artefacts.
> > >
> > > - tommy
> > >
> > > On 15 July 2014 at 9:14:12, Anis KADRI (anis.kadri@gmail.com
> <javascript:;>) wrote:
> > >
> > > If you're touching any non-www project files (that is *.xml, *.plist,
> > *.m,
> > > *.java etc...) or are using an IDE you should not be using cordova-cli
> > and
> > > switch to single platform development. Browse the documentation and
> there
> > > is always the equivalent platform command available to you. Example:
> > > cordova build becomes ./cordova/build etc...You can then modify all
> your
> > > files at will but will loose the benefit of a shared www/ across
> > platforms.
> > >
> > >
> > > On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
> > > frederico.galvao@pontoget.com.br <javascript:;>> wrote:
> > >
> > > > I agree with the core message from Axel, but I'd refrase that last
> line
> > > as:
> > > >
> > > > "The bottom line is: either use Cordova CLI or not".
> > > >
> > > > Cordova can still be used without the CLI portion just as well, which
> > > > should suffice Jan for his needs.
> > > >
> > > > However, I'll add that you can still use Cordova with the CLI (and
> thus
> > > > following the directory structure and rules the CLI gives you) and
> > still
> > > be
> > > > efficient even if it's only one target platform.
> > > > What made you think that it is "better to change platform project
> > > > config.xml instead of whole project config.xml" should be clarified
> > > better
> > > > if you can, so that the Cordova team can improve the tool.
> > > >
> > > >
> > > > 2014-07-14 5:35 GMT-03:00 Axel Nennker <ignisvulpis@gmail.com
> <javascript:;>>:
> > > >
> > > > > My experience with Cordova (and other tools for that matter) is
> that
> > it
> > > > > makes no sense to change tool generated files.
> > > > > If the tool is improved you do not benefit from this improvement
> > > because
> > > > > your modified files will be changed by the new version.
> > > > > If you change a tool generated file you are out.
> > > > > When we started using Cordova me and other colleagues thought that
> > our
> > > > > project "needs" to change Cordova generated files too.
> > > > > In each case this turned out to be wrong.
> > > > > Most of the times writing a Cordova plugin is the solution.
> > > > >
> > > > > The bottom line is: either use Cordova or not. (or send a pull
> > request
> > > to
> > > > > improve it)
> > > > >
> > > > > -Axel
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2014-07-13 22:18 GMT+02:00 Jan Velecký <VVelda@seznam.cz
> <javascript:;>>:
> > > > >
> > > > > > Hello,
> > > > > > there is serious backlog when using CLI in case one platform
> > > > development.
> > > > > > In
> > > > > > this case is better to change platform project config.xml instead
> > of
> > > > > whole
> > > > > > project config.xml. Problem is what prepare should do, and what
> > > prepare
> > > > > > actually do. (And prepare is also run if we do build.) At this
> > > moment,
> > > > > > prepare in CLI does clean & copy...
> > > > > > Also prepare does it in different way in Android, than in iOS.
> > > > > > On Android, config.xml and androidmanifest.xml is probably
> > recreated
> > > > > > (destroy previous formatting, what a feature...) and then
> probably
> > > add
> > > > > > differences, so changes and new options are preserved, however
> > nobody
> > > > > wanna
> > > > > > read it...
> > > > > > On iOS, config.xml is completely recreated, no any option is
> > > > preserved...
> > > > > >
> > > > > > So, there are 2 questions...
> > > > > > If is Android CLI too clever to do preserve changes created by
> > user,
> > > > why
> > > > > it
> > > > > > ruins my formatting (new lines, maybe also tabulators)?
> > > > > > Why is iOS CLI such a stupid? Why it is not able to do it like
> > > Android
> > > > > CLI
> > > > > > (at least)?
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > *Frederico Galvão*
> > > >
> > > > Diretor de Tecnologia
> > > >
> > > > PontoGet Inovação Web
> > > >
> > > >
> > > > ( +55(62) 8131-5720
> > > >
> > > > * www.pontoget.com.br <http://www.pontoget.com/>
> > > >
> > >
> > >
> >
> >
>
>
Re: One platform development vs. Cordova CLI
Posted by tommy-carlos williams <to...@devgeeks.org>.
Never said this stuff couldn’t be fixed.
I have been actively advocating for it to be fixed.
Only wanted to spread some light on this statement:
If you're touching any non-www project files (that is *.xml, *.plist, *.m, *.java etc...) or are using an IDE you should not be using cordova-cli and switch to single platform development.
- tommy
On 15 July 2014 at 22:11:24, Axel Nennker (ignisvulpis@gmail.com) wrote:
From looking at the code it seems that versionCode is handled on Android:
https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/metadata/android_parser.js#L225
There is a email thread about minSdkVersion and an quite recent issue:
https://issues.apache.org/jira/browse/CB-7114?jql=text%20~%20%22minSdkVersion%22
So these could be fixed.
Regarding signing info: I am using ant on top of cordova like: e.g.: create
app from my template; install plugins, run
Ant modifies ant.properties too. Currently not to include signing info but
to modify the classpath because I need a lib at compile time that is not
included into the apk (openmobileapi).
Not sure wheter these two requirements (signing info, noexportlib) should
be of config.xml...
At least I am not doing this stuff manually.
2014-07-15 12:11 GMT+02:00 tommy-carlos williams <to...@devgeeks.org>:
> Assuming that splash screens and icons finally work in 3.5.x (so, only as
> of a few weeks ago… not everyone’s projects are that new) –
>
>
> Android:
>
> AndroidManifest.xml:
> android:versionCode
> (and possibly) android:minSdkVersion
>
> ant.properties
> android signing info
>
>
> This is just off the top of my head.
>
> There are more in iOS as well (mostly the same ones, but others depending
> on features… like provisioning profiles, etc)
>
> Then there are the platforms outside the “big two”… plenty there.
>
> - tommy
>
>
> On 15 July 2014 at 14:44:05, Axel Nennker (ignisvulpis@gmail.com) wrote:
>
> Could you please give an example which files you need to change and why?
> (Preferably Android)
>
> Thanks
> Axel
> Am 15.07.2014 02:23 schrieb "tommy-carlos williams" <to...@devgeeks.org>:
>
> > Sooo.. translation:
> >
> > “If you aren’t just making a test / example app…”
> >
> > ??
> >
> > Unless a lot has changed that I don’t know about, it is still impossible
> > to make an app all the way to market without modifying those non-www
> files
> > using the CLI.
> >
> > There are fantastic workarounds available (mostly hooks, etc) for the CLI
> > until we get it to the point where the platforms/* and plugins/* folders
> > are build artefacts.
> >
> > - tommy
> >
> > On 15 July 2014 at 9:14:12, Anis KADRI (anis.kadri@gmail.com) wrote:
> >
> > If you're touching any non-www project files (that is *.xml, *.plist,
> *.m,
> > *.java etc...) or are using an IDE you should not be using cordova-cli
> and
> > switch to single platform development. Browse the documentation and there
> > is always the equivalent platform command available to you. Example:
> > cordova build becomes ./cordova/build etc...You can then modify all your
> > files at will but will loose the benefit of a shared www/ across
> platforms.
> >
> >
> > On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
> > frederico.galvao@pontoget.com.br> wrote:
> >
> > > I agree with the core message from Axel, but I'd refrase that last line
> > as:
> > >
> > > "The bottom line is: either use Cordova CLI or not".
> > >
> > > Cordova can still be used without the CLI portion just as well, which
> > > should suffice Jan for his needs.
> > >
> > > However, I'll add that you can still use Cordova with the CLI (and thus
> > > following the directory structure and rules the CLI gives you) and
> still
> > be
> > > efficient even if it's only one target platform.
> > > What made you think that it is "better to change platform project
> > > config.xml instead of whole project config.xml" should be clarified
> > better
> > > if you can, so that the Cordova team can improve the tool.
> > >
> > >
> > > 2014-07-14 5:35 GMT-03:00 Axel Nennker <ig...@gmail.com>:
> > >
> > > > My experience with Cordova (and other tools for that matter) is that
> it
> > > > makes no sense to change tool generated files.
> > > > If the tool is improved you do not benefit from this improvement
> > because
> > > > your modified files will be changed by the new version.
> > > > If you change a tool generated file you are out.
> > > > When we started using Cordova me and other colleagues thought that
> our
> > > > project "needs" to change Cordova generated files too.
> > > > In each case this turned out to be wrong.
> > > > Most of the times writing a Cordova plugin is the solution.
> > > >
> > > > The bottom line is: either use Cordova or not. (or send a pull
> request
> > to
> > > > improve it)
> > > >
> > > > -Axel
> > > >
> > > >
> > > >
> > > >
> > > > 2014-07-13 22:18 GMT+02:00 Jan Velecký <VV...@seznam.cz>:
> > > >
> > > > > Hello,
> > > > > there is serious backlog when using CLI in case one platform
> > > development.
> > > > > In
> > > > > this case is better to change platform project config.xml instead
> of
> > > > whole
> > > > > project config.xml. Problem is what prepare should do, and what
> > prepare
> > > > > actually do. (And prepare is also run if we do build.) At this
> > moment,
> > > > > prepare in CLI does clean & copy...
> > > > > Also prepare does it in different way in Android, than in iOS.
> > > > > On Android, config.xml and androidmanifest.xml is probably
> recreated
> > > > > (destroy previous formatting, what a feature...) and then probably
> > add
> > > > > differences, so changes and new options are preserved, however
> nobody
> > > > wanna
> > > > > read it...
> > > > > On iOS, config.xml is completely recreated, no any option is
> > > preserved...
> > > > >
> > > > > So, there are 2 questions...
> > > > > If is Android CLI too clever to do preserve changes created by
> user,
> > > why
> > > > it
> > > > > ruins my formatting (new lines, maybe also tabulators)?
> > > > > Why is iOS CLI such a stupid? Why it is not able to do it like
> > Android
> > > > CLI
> > > > > (at least)?
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Frederico Galvão*
> > >
> > > Diretor de Tecnologia
> > >
> > > PontoGet Inovação Web
> > >
> > >
> > > ( +55(62) 8131-5720
> > >
> > > * www.pontoget.com.br <http://www.pontoget.com/>
> > >
> >
> >
>
>
Re: One platform development vs. Cordova CLI
Posted by Axel Nennker <ig...@gmail.com>.
>From looking at the code it seems that versionCode is handled on Android:
https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/metadata/android_parser.js#L225
There is a email thread about minSdkVersion and an quite recent issue:
https://issues.apache.org/jira/browse/CB-7114?jql=text%20~%20%22minSdkVersion%22
So these could be fixed.
Regarding signing info: I am using ant on top of cordova like: e.g.: create
app from my template; install plugins, run
Ant modifies ant.properties too. Currently not to include signing info but
to modify the classpath because I need a lib at compile time that is not
included into the apk (openmobileapi).
Not sure wheter these two requirements (signing info, noexportlib) should
be of config.xml...
At least I am not doing this stuff manually.
2014-07-15 12:11 GMT+02:00 tommy-carlos williams <to...@devgeeks.org>:
> Assuming that splash screens and icons finally work in 3.5.x (so, only as
> of a few weeks ago… not everyone’s projects are that new) –
>
>
> Android:
>
> AndroidManifest.xml:
> android:versionCode
> (and possibly) android:minSdkVersion
>
> ant.properties
> android signing info
>
>
> This is just off the top of my head.
>
> There are more in iOS as well (mostly the same ones, but others depending
> on features… like provisioning profiles, etc)
>
> Then there are the platforms outside the “big two”… plenty there.
>
> - tommy
>
>
> On 15 July 2014 at 14:44:05, Axel Nennker (ignisvulpis@gmail.com) wrote:
>
> Could you please give an example which files you need to change and why?
> (Preferably Android)
>
> Thanks
> Axel
> Am 15.07.2014 02:23 schrieb "tommy-carlos williams" <to...@devgeeks.org>:
>
> > Sooo.. translation:
> >
> > “If you aren’t just making a test / example app…”
> >
> > ??
> >
> > Unless a lot has changed that I don’t know about, it is still impossible
> > to make an app all the way to market without modifying those non-www
> files
> > using the CLI.
> >
> > There are fantastic workarounds available (mostly hooks, etc) for the CLI
> > until we get it to the point where the platforms/* and plugins/* folders
> > are build artefacts.
> >
> > - tommy
> >
> > On 15 July 2014 at 9:14:12, Anis KADRI (anis.kadri@gmail.com) wrote:
> >
> > If you're touching any non-www project files (that is *.xml, *.plist,
> *.m,
> > *.java etc...) or are using an IDE you should not be using cordova-cli
> and
> > switch to single platform development. Browse the documentation and there
> > is always the equivalent platform command available to you. Example:
> > cordova build becomes ./cordova/build etc...You can then modify all your
> > files at will but will loose the benefit of a shared www/ across
> platforms.
> >
> >
> > On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
> > frederico.galvao@pontoget.com.br> wrote:
> >
> > > I agree with the core message from Axel, but I'd refrase that last line
> > as:
> > >
> > > "The bottom line is: either use Cordova CLI or not".
> > >
> > > Cordova can still be used without the CLI portion just as well, which
> > > should suffice Jan for his needs.
> > >
> > > However, I'll add that you can still use Cordova with the CLI (and thus
> > > following the directory structure and rules the CLI gives you) and
> still
> > be
> > > efficient even if it's only one target platform.
> > > What made you think that it is "better to change platform project
> > > config.xml instead of whole project config.xml" should be clarified
> > better
> > > if you can, so that the Cordova team can improve the tool.
> > >
> > >
> > > 2014-07-14 5:35 GMT-03:00 Axel Nennker <ig...@gmail.com>:
> > >
> > > > My experience with Cordova (and other tools for that matter) is that
> it
> > > > makes no sense to change tool generated files.
> > > > If the tool is improved you do not benefit from this improvement
> > because
> > > > your modified files will be changed by the new version.
> > > > If you change a tool generated file you are out.
> > > > When we started using Cordova me and other colleagues thought that
> our
> > > > project "needs" to change Cordova generated files too.
> > > > In each case this turned out to be wrong.
> > > > Most of the times writing a Cordova plugin is the solution.
> > > >
> > > > The bottom line is: either use Cordova or not. (or send a pull
> request
> > to
> > > > improve it)
> > > >
> > > > -Axel
> > > >
> > > >
> > > >
> > > >
> > > > 2014-07-13 22:18 GMT+02:00 Jan Velecký <VV...@seznam.cz>:
> > > >
> > > > > Hello,
> > > > > there is serious backlog when using CLI in case one platform
> > > development.
> > > > > In
> > > > > this case is better to change platform project config.xml instead
> of
> > > > whole
> > > > > project config.xml. Problem is what prepare should do, and what
> > prepare
> > > > > actually do. (And prepare is also run if we do build.) At this
> > moment,
> > > > > prepare in CLI does clean & copy...
> > > > > Also prepare does it in different way in Android, than in iOS.
> > > > > On Android, config.xml and androidmanifest.xml is probably
> recreated
> > > > > (destroy previous formatting, what a feature...) and then probably
> > add
> > > > > differences, so changes and new options are preserved, however
> nobody
> > > > wanna
> > > > > read it...
> > > > > On iOS, config.xml is completely recreated, no any option is
> > > preserved...
> > > > >
> > > > > So, there are 2 questions...
> > > > > If is Android CLI too clever to do preserve changes created by
> user,
> > > why
> > > > it
> > > > > ruins my formatting (new lines, maybe also tabulators)?
> > > > > Why is iOS CLI such a stupid? Why it is not able to do it like
> > Android
> > > > CLI
> > > > > (at least)?
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Frederico Galvão*
> > >
> > > Diretor de Tecnologia
> > >
> > > PontoGet Inovação Web
> > >
> > >
> > > ( +55(62) 8131-5720
> > >
> > > * www.pontoget.com.br <http://www.pontoget.com/>
> > >
> >
> >
>
>
Re: One platform development vs. Cordova CLI
Posted by julio cesar sanchez <jc...@gmail.com>.
+ ios background modes
2014-07-15 12:36 GMT+02:00 tommy-carlos williams <to...@devgeeks.org>:
> +1 This
>
> On 15 July 2014 at 20:31:07, purplecabbage (purplecabbage@gmail.com) wrote:
>
> There are numerous last mile steps we are not involved in, which is why I wish more committers were submitting apps to more stores, at least to see the process.
>
Re: One platform development vs. Cordova CLI
Posted by tommy-carlos williams <to...@devgeeks.org>.
+1 This
On 15 July 2014 at 20:31:07, purplecabbage (purplecabbage@gmail.com) wrote:
There are numerous last mile steps we are not involved in, which is why I wish more committers were submitting apps to more stores, at least to see the process.
Re: One platform development vs. Cordova CLI
Posted by purplecabbage <pu...@gmail.com>.
+ custom protocol handling
+ document type registration
+ guid app id changes, or assigning different signing credentials
There are numerous last mile steps we are not involved in, which is why I wish more committers were submitting apps to more stores, at least to see the process.
Sent from my iPhone
> On Jul 15, 2014, at 3:11 AM, tommy-carlos williams <to...@devgeeks.org> wrote:
>
> Assuming that splash screens and icons finally work in 3.5.x (so, only as of a few weeks ago… not everyone’s projects are that new) –
>
>
> Android:
>
> AndroidManifest.xml:
> android:versionCode
> (and possibly) android:minSdkVersion
>
> ant.properties
> android signing info
>
>
> This is just off the top of my head.
>
> There are more in iOS as well (mostly the same ones, but others depending on features… like provisioning profiles, etc)
>
> Then there are the platforms outside the “big two”… plenty there.
>
> - tommy
>
>
> On 15 July 2014 at 14:44:05, Axel Nennker (ignisvulpis@gmail.com) wrote:
>
> Could you please give an example which files you need to change and why?
> (Preferably Android)
>
> Thanks
> Axel
> Am 15.07.2014 02:23 schrieb "tommy-carlos williams" <to...@devgeeks.org>:
>
>> Sooo.. translation:
>>
>> “If you aren’t just making a test / example app…”
>>
>> ??
>>
>> Unless a lot has changed that I don’t know about, it is still impossible
>> to make an app all the way to market without modifying those non-www files
>> using the CLI.
>>
>> There are fantastic workarounds available (mostly hooks, etc) for the CLI
>> until we get it to the point where the platforms/* and plugins/* folders
>> are build artefacts.
>>
>> - tommy
>>
>> On 15 July 2014 at 9:14:12, Anis KADRI (anis.kadri@gmail.com) wrote:
>>
>> If you're touching any non-www project files (that is *.xml, *.plist, *.m,
>> *.java etc...) or are using an IDE you should not be using cordova-cli and
>> switch to single platform development. Browse the documentation and there
>> is always the equivalent platform command available to you. Example:
>> cordova build becomes ./cordova/build etc...You can then modify all your
>> files at will but will loose the benefit of a shared www/ across platforms.
>>
>>
>> On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
>> frederico.galvao@pontoget.com.br> wrote:
>>
>>> I agree with the core message from Axel, but I'd refrase that last line
>> as:
>>>
>>> "The bottom line is: either use Cordova CLI or not".
>>>
>>> Cordova can still be used without the CLI portion just as well, which
>>> should suffice Jan for his needs.
>>>
>>> However, I'll add that you can still use Cordova with the CLI (and thus
>>> following the directory structure and rules the CLI gives you) and still
>> be
>>> efficient even if it's only one target platform.
>>> What made you think that it is "better to change platform project
>>> config.xml instead of whole project config.xml" should be clarified
>> better
>>> if you can, so that the Cordova team can improve the tool.
>>>
>>>
>>> 2014-07-14 5:35 GMT-03:00 Axel Nennker <ig...@gmail.com>:
>>>
>>>> My experience with Cordova (and other tools for that matter) is that it
>>>> makes no sense to change tool generated files.
>>>> If the tool is improved you do not benefit from this improvement
>> because
>>>> your modified files will be changed by the new version.
>>>> If you change a tool generated file you are out.
>>>> When we started using Cordova me and other colleagues thought that our
>>>> project "needs" to change Cordova generated files too.
>>>> In each case this turned out to be wrong.
>>>> Most of the times writing a Cordova plugin is the solution.
>>>>
>>>> The bottom line is: either use Cordova or not. (or send a pull request
>> to
>>>> improve it)
>>>>
>>>> -Axel
>>>>
>>>>
>>>>
>>>>
>>>> 2014-07-13 22:18 GMT+02:00 Jan Velecký <VV...@seznam.cz>:
>>>>
>>>>> Hello,
>>>>> there is serious backlog when using CLI in case one platform
>>> development.
>>>>> In
>>>>> this case is better to change platform project config.xml instead of
>>>> whole
>>>>> project config.xml. Problem is what prepare should do, and what
>> prepare
>>>>> actually do. (And prepare is also run if we do build.) At this
>> moment,
>>>>> prepare in CLI does clean & copy...
>>>>> Also prepare does it in different way in Android, than in iOS.
>>>>> On Android, config.xml and androidmanifest.xml is probably recreated
>>>>> (destroy previous formatting, what a feature...) and then probably
>> add
>>>>> differences, so changes and new options are preserved, however nobody
>>>> wanna
>>>>> read it...
>>>>> On iOS, config.xml is completely recreated, no any option is
>>> preserved...
>>>>>
>>>>> So, there are 2 questions...
>>>>> If is Android CLI too clever to do preserve changes created by user,
>>> why
>>>> it
>>>>> ruins my formatting (new lines, maybe also tabulators)?
>>>>> Why is iOS CLI such a stupid? Why it is not able to do it like
>> Android
>>>> CLI
>>>>> (at least)?
>>>
>>>
>>>
>>> --
>>>
>>> *Frederico Galvão*
>>>
>>> Diretor de Tecnologia
>>>
>>> PontoGet Inovação Web
>>>
>>>
>>> ( +55(62) 8131-5720
>>>
>>> * www.pontoget.com.br <http://www.pontoget.com/>
>
Re: One platform development vs. Cordova CLI
Posted by tommy-carlos williams <to...@devgeeks.org>.
Assuming that splash screens and icons finally work in 3.5.x (so, only as of a few weeks ago… not everyone’s projects are that new) –
Android:
AndroidManifest.xml:
android:versionCode
(and possibly) android:minSdkVersion
ant.properties
android signing info
This is just off the top of my head.
There are more in iOS as well (mostly the same ones, but others depending on features… like provisioning profiles, etc)
Then there are the platforms outside the “big two”… plenty there.
- tommy
On 15 July 2014 at 14:44:05, Axel Nennker (ignisvulpis@gmail.com) wrote:
Could you please give an example which files you need to change and why?
(Preferably Android)
Thanks
Axel
Am 15.07.2014 02:23 schrieb "tommy-carlos williams" <to...@devgeeks.org>:
> Sooo.. translation:
>
> “If you aren’t just making a test / example app…”
>
> ??
>
> Unless a lot has changed that I don’t know about, it is still impossible
> to make an app all the way to market without modifying those non-www files
> using the CLI.
>
> There are fantastic workarounds available (mostly hooks, etc) for the CLI
> until we get it to the point where the platforms/* and plugins/* folders
> are build artefacts.
>
> - tommy
>
> On 15 July 2014 at 9:14:12, Anis KADRI (anis.kadri@gmail.com) wrote:
>
> If you're touching any non-www project files (that is *.xml, *.plist, *.m,
> *.java etc...) or are using an IDE you should not be using cordova-cli and
> switch to single platform development. Browse the documentation and there
> is always the equivalent platform command available to you. Example:
> cordova build becomes ./cordova/build etc...You can then modify all your
> files at will but will loose the benefit of a shared www/ across platforms.
>
>
> On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
> frederico.galvao@pontoget.com.br> wrote:
>
> > I agree with the core message from Axel, but I'd refrase that last line
> as:
> >
> > "The bottom line is: either use Cordova CLI or not".
> >
> > Cordova can still be used without the CLI portion just as well, which
> > should suffice Jan for his needs.
> >
> > However, I'll add that you can still use Cordova with the CLI (and thus
> > following the directory structure and rules the CLI gives you) and still
> be
> > efficient even if it's only one target platform.
> > What made you think that it is "better to change platform project
> > config.xml instead of whole project config.xml" should be clarified
> better
> > if you can, so that the Cordova team can improve the tool.
> >
> >
> > 2014-07-14 5:35 GMT-03:00 Axel Nennker <ig...@gmail.com>:
> >
> > > My experience with Cordova (and other tools for that matter) is that it
> > > makes no sense to change tool generated files.
> > > If the tool is improved you do not benefit from this improvement
> because
> > > your modified files will be changed by the new version.
> > > If you change a tool generated file you are out.
> > > When we started using Cordova me and other colleagues thought that our
> > > project "needs" to change Cordova generated files too.
> > > In each case this turned out to be wrong.
> > > Most of the times writing a Cordova plugin is the solution.
> > >
> > > The bottom line is: either use Cordova or not. (or send a pull request
> to
> > > improve it)
> > >
> > > -Axel
> > >
> > >
> > >
> > >
> > > 2014-07-13 22:18 GMT+02:00 Jan Velecký <VV...@seznam.cz>:
> > >
> > > > Hello,
> > > > there is serious backlog when using CLI in case one platform
> > development.
> > > > In
> > > > this case is better to change platform project config.xml instead of
> > > whole
> > > > project config.xml. Problem is what prepare should do, and what
> prepare
> > > > actually do. (And prepare is also run if we do build.) At this
> moment,
> > > > prepare in CLI does clean & copy...
> > > > Also prepare does it in different way in Android, than in iOS.
> > > > On Android, config.xml and androidmanifest.xml is probably recreated
> > > > (destroy previous formatting, what a feature...) and then probably
> add
> > > > differences, so changes and new options are preserved, however nobody
> > > wanna
> > > > read it...
> > > > On iOS, config.xml is completely recreated, no any option is
> > preserved...
> > > >
> > > > So, there are 2 questions...
> > > > If is Android CLI too clever to do preserve changes created by user,
> > why
> > > it
> > > > ruins my formatting (new lines, maybe also tabulators)?
> > > > Why is iOS CLI such a stupid? Why it is not able to do it like
> Android
> > > CLI
> > > > (at least)?
> > >
> >
> >
> >
> > --
> >
> > *Frederico Galvão*
> >
> > Diretor de Tecnologia
> >
> > PontoGet Inovação Web
> >
> >
> > ( +55(62) 8131-5720
> >
> > * www.pontoget.com.br <http://www.pontoget.com/>
> >
>
>
Re: One platform development vs. Cordova CLI
Posted by Axel Nennker <ig...@gmail.com>.
Could you please give an example which files you need to change and why?
(Preferably Android)
Thanks
Axel
Am 15.07.2014 02:23 schrieb "tommy-carlos williams" <to...@devgeeks.org>:
> Sooo.. translation:
>
> “If you aren’t just making a test / example app…”
>
> ??
>
> Unless a lot has changed that I don’t know about, it is still impossible
> to make an app all the way to market without modifying those non-www files
> using the CLI.
>
> There are fantastic workarounds available (mostly hooks, etc) for the CLI
> until we get it to the point where the platforms/* and plugins/* folders
> are build artefacts.
>
> - tommy
>
> On 15 July 2014 at 9:14:12, Anis KADRI (anis.kadri@gmail.com) wrote:
>
> If you're touching any non-www project files (that is *.xml, *.plist, *.m,
> *.java etc...) or are using an IDE you should not be using cordova-cli and
> switch to single platform development. Browse the documentation and there
> is always the equivalent platform command available to you. Example:
> cordova build becomes ./cordova/build etc...You can then modify all your
> files at will but will loose the benefit of a shared www/ across platforms.
>
>
> On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
> frederico.galvao@pontoget.com.br> wrote:
>
> > I agree with the core message from Axel, but I'd refrase that last line
> as:
> >
> > "The bottom line is: either use Cordova CLI or not".
> >
> > Cordova can still be used without the CLI portion just as well, which
> > should suffice Jan for his needs.
> >
> > However, I'll add that you can still use Cordova with the CLI (and thus
> > following the directory structure and rules the CLI gives you) and still
> be
> > efficient even if it's only one target platform.
> > What made you think that it is "better to change platform project
> > config.xml instead of whole project config.xml" should be clarified
> better
> > if you can, so that the Cordova team can improve the tool.
> >
> >
> > 2014-07-14 5:35 GMT-03:00 Axel Nennker <ig...@gmail.com>:
> >
> > > My experience with Cordova (and other tools for that matter) is that it
> > > makes no sense to change tool generated files.
> > > If the tool is improved you do not benefit from this improvement
> because
> > > your modified files will be changed by the new version.
> > > If you change a tool generated file you are out.
> > > When we started using Cordova me and other colleagues thought that our
> > > project "needs" to change Cordova generated files too.
> > > In each case this turned out to be wrong.
> > > Most of the times writing a Cordova plugin is the solution.
> > >
> > > The bottom line is: either use Cordova or not. (or send a pull request
> to
> > > improve it)
> > >
> > > -Axel
> > >
> > >
> > >
> > >
> > > 2014-07-13 22:18 GMT+02:00 Jan Velecký <VV...@seznam.cz>:
> > >
> > > > Hello,
> > > > there is serious backlog when using CLI in case one platform
> > development.
> > > > In
> > > > this case is better to change platform project config.xml instead of
> > > whole
> > > > project config.xml. Problem is what prepare should do, and what
> prepare
> > > > actually do. (And prepare is also run if we do build.) At this
> moment,
> > > > prepare in CLI does clean & copy...
> > > > Also prepare does it in different way in Android, than in iOS.
> > > > On Android, config.xml and androidmanifest.xml is probably recreated
> > > > (destroy previous formatting, what a feature...) and then probably
> add
> > > > differences, so changes and new options are preserved, however nobody
> > > wanna
> > > > read it...
> > > > On iOS, config.xml is completely recreated, no any option is
> > preserved...
> > > >
> > > > So, there are 2 questions...
> > > > If is Android CLI too clever to do preserve changes created by user,
> > why
> > > it
> > > > ruins my formatting (new lines, maybe also tabulators)?
> > > > Why is iOS CLI such a stupid? Why it is not able to do it like
> Android
> > > CLI
> > > > (at least)?
> > >
> >
> >
> >
> > --
> >
> > *Frederico Galvão*
> >
> > Diretor de Tecnologia
> >
> > PontoGet Inovação Web
> >
> >
> > ( +55(62) 8131-5720
> >
> > * www.pontoget.com.br <http://www.pontoget.com/>
> >
>
>
Re: One platform development vs. Cordova CLI
Posted by tommy-carlos williams <to...@devgeeks.org>.
Sooo.. translation:
“If you aren’t just making a test / example app…”
??
Unless a lot has changed that I don’t know about, it is still impossible to make an app all the way to market without modifying those non-www files using the CLI.
There are fantastic workarounds available (mostly hooks, etc) for the CLI until we get it to the point where the platforms/* and plugins/* folders are build artefacts.
- tommy
On 15 July 2014 at 9:14:12, Anis KADRI (anis.kadri@gmail.com) wrote:
If you're touching any non-www project files (that is *.xml, *.plist, *.m,
*.java etc...) or are using an IDE you should not be using cordova-cli and
switch to single platform development. Browse the documentation and there
is always the equivalent platform command available to you. Example:
cordova build becomes ./cordova/build etc...You can then modify all your
files at will but will loose the benefit of a shared www/ across platforms.
On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
frederico.galvao@pontoget.com.br> wrote:
> I agree with the core message from Axel, but I'd refrase that last line as:
>
> "The bottom line is: either use Cordova CLI or not".
>
> Cordova can still be used without the CLI portion just as well, which
> should suffice Jan for his needs.
>
> However, I'll add that you can still use Cordova with the CLI (and thus
> following the directory structure and rules the CLI gives you) and still be
> efficient even if it's only one target platform.
> What made you think that it is "better to change platform project
> config.xml instead of whole project config.xml" should be clarified better
> if you can, so that the Cordova team can improve the tool.
>
>
> 2014-07-14 5:35 GMT-03:00 Axel Nennker <ig...@gmail.com>:
>
> > My experience with Cordova (and other tools for that matter) is that it
> > makes no sense to change tool generated files.
> > If the tool is improved you do not benefit from this improvement because
> > your modified files will be changed by the new version.
> > If you change a tool generated file you are out.
> > When we started using Cordova me and other colleagues thought that our
> > project "needs" to change Cordova generated files too.
> > In each case this turned out to be wrong.
> > Most of the times writing a Cordova plugin is the solution.
> >
> > The bottom line is: either use Cordova or not. (or send a pull request to
> > improve it)
> >
> > -Axel
> >
> >
> >
> >
> > 2014-07-13 22:18 GMT+02:00 Jan Velecký <VV...@seznam.cz>:
> >
> > > Hello,
> > > there is serious backlog when using CLI in case one platform
> development.
> > > In
> > > this case is better to change platform project config.xml instead of
> > whole
> > > project config.xml. Problem is what prepare should do, and what prepare
> > > actually do. (And prepare is also run if we do build.) At this moment,
> > > prepare in CLI does clean & copy...
> > > Also prepare does it in different way in Android, than in iOS.
> > > On Android, config.xml and androidmanifest.xml is probably recreated
> > > (destroy previous formatting, what a feature...) and then probably add
> > > differences, so changes and new options are preserved, however nobody
> > wanna
> > > read it...
> > > On iOS, config.xml is completely recreated, no any option is
> preserved...
> > >
> > > So, there are 2 questions...
> > > If is Android CLI too clever to do preserve changes created by user,
> why
> > it
> > > ruins my formatting (new lines, maybe also tabulators)?
> > > Why is iOS CLI such a stupid? Why it is not able to do it like Android
> > CLI
> > > (at least)?
> >
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>
Re: One platform development vs. Cordova CLI
Posted by Anis KADRI <an...@gmail.com>.
If you're touching any non-www project files (that is *.xml, *.plist, *.m,
*.java etc...) or are using an IDE you should not be using cordova-cli and
switch to single platform development. Browse the documentation and there
is always the equivalent platform command available to you. Example:
cordova build becomes ./cordova/build etc...You can then modify all your
files at will but will loose the benefit of a shared www/ across platforms.
On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
frederico.galvao@pontoget.com.br> wrote:
> I agree with the core message from Axel, but I'd refrase that last line as:
>
> "The bottom line is: either use Cordova CLI or not".
>
> Cordova can still be used without the CLI portion just as well, which
> should suffice Jan for his needs.
>
> However, I'll add that you can still use Cordova with the CLI (and thus
> following the directory structure and rules the CLI gives you) and still be
> efficient even if it's only one target platform.
> What made you think that it is "better to change platform project
> config.xml instead of whole project config.xml" should be clarified better
> if you can, so that the Cordova team can improve the tool.
>
>
> 2014-07-14 5:35 GMT-03:00 Axel Nennker <ig...@gmail.com>:
>
> > My experience with Cordova (and other tools for that matter) is that it
> > makes no sense to change tool generated files.
> > If the tool is improved you do not benefit from this improvement because
> > your modified files will be changed by the new version.
> > If you change a tool generated file you are out.
> > When we started using Cordova me and other colleagues thought that our
> > project "needs" to change Cordova generated files too.
> > In each case this turned out to be wrong.
> > Most of the times writing a Cordova plugin is the solution.
> >
> > The bottom line is: either use Cordova or not. (or send a pull request to
> > improve it)
> >
> > -Axel
> >
> >
> >
> >
> > 2014-07-13 22:18 GMT+02:00 Jan Velecký <VV...@seznam.cz>:
> >
> > > Hello,
> > > there is serious backlog when using CLI in case one platform
> development.
> > > In
> > > this case is better to change platform project config.xml instead of
> > whole
> > > project config.xml. Problem is what prepare should do, and what prepare
> > > actually do. (And prepare is also run if we do build.) At this moment,
> > > prepare in CLI does clean & copy...
> > > Also prepare does it in different way in Android, than in iOS.
> > > On Android, config.xml and androidmanifest.xml is probably recreated
> > > (destroy previous formatting, what a feature...) and then probably add
> > > differences, so changes and new options are preserved, however nobody
> > wanna
> > > read it...
> > > On iOS, config.xml is completely recreated, no any option is
> preserved...
> > >
> > > So, there are 2 questions...
> > > If is Android CLI too clever to do preserve changes created by user,
> why
> > it
> > > ruins my formatting (new lines, maybe also tabulators)?
> > > Why is iOS CLI such a stupid? Why it is not able to do it like Android
> > CLI
> > > (at least)?
> >
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>
Re: One platform development vs. Cordova CLI
Posted by Frederico Galvão <fr...@pontoget.com.br>.
I agree with the core message from Axel, but I'd refrase that last line as:
"The bottom line is: either use Cordova CLI or not".
Cordova can still be used without the CLI portion just as well, which
should suffice Jan for his needs.
However, I'll add that you can still use Cordova with the CLI (and thus
following the directory structure and rules the CLI gives you) and still be
efficient even if it's only one target platform.
What made you think that it is "better to change platform project
config.xml instead of whole project config.xml" should be clarified better
if you can, so that the Cordova team can improve the tool.
2014-07-14 5:35 GMT-03:00 Axel Nennker <ig...@gmail.com>:
> My experience with Cordova (and other tools for that matter) is that it
> makes no sense to change tool generated files.
> If the tool is improved you do not benefit from this improvement because
> your modified files will be changed by the new version.
> If you change a tool generated file you are out.
> When we started using Cordova me and other colleagues thought that our
> project "needs" to change Cordova generated files too.
> In each case this turned out to be wrong.
> Most of the times writing a Cordova plugin is the solution.
>
> The bottom line is: either use Cordova or not. (or send a pull request to
> improve it)
>
> -Axel
>
>
>
>
> 2014-07-13 22:18 GMT+02:00 Jan Velecký <VV...@seznam.cz>:
>
> > Hello,
> > there is serious backlog when using CLI in case one platform development.
> > In
> > this case is better to change platform project config.xml instead of
> whole
> > project config.xml. Problem is what prepare should do, and what prepare
> > actually do. (And prepare is also run if we do build.) At this moment,
> > prepare in CLI does clean & copy...
> > Also prepare does it in different way in Android, than in iOS.
> > On Android, config.xml and androidmanifest.xml is probably recreated
> > (destroy previous formatting, what a feature...) and then probably add
> > differences, so changes and new options are preserved, however nobody
> wanna
> > read it...
> > On iOS, config.xml is completely recreated, no any option is preserved...
> >
> > So, there are 2 questions...
> > If is Android CLI too clever to do preserve changes created by user, why
> it
> > ruins my formatting (new lines, maybe also tabulators)?
> > Why is iOS CLI such a stupid? Why it is not able to do it like Android
> CLI
> > (at least)?
>
--
*Frederico Galvão*
Diretor de Tecnologia
PontoGet Inovação Web
( +55(62) 8131-5720
* www.pontoget.com.br <http://www.pontoget.com/>
Re: One platform development vs. Cordova CLI
Posted by Axel Nennker <ig...@gmail.com>.
My experience with Cordova (and other tools for that matter) is that it
makes no sense to change tool generated files.
If the tool is improved you do not benefit from this improvement because
your modified files will be changed by the new version.
If you change a tool generated file you are out.
When we started using Cordova me and other colleagues thought that our
project "needs" to change Cordova generated files too.
In each case this turned out to be wrong.
Most of the times writing a Cordova plugin is the solution.
The bottom line is: either use Cordova or not. (or send a pull request to
improve it)
-Axel
2014-07-13 22:18 GMT+02:00 Jan Velecký <VV...@seznam.cz>:
> Hello,
> there is serious backlog when using CLI in case one platform development.
> In
> this case is better to change platform project config.xml instead of whole
> project config.xml. Problem is what prepare should do, and what prepare
> actually do. (And prepare is also run if we do build.) At this moment,
> prepare in CLI does clean & copy...
> Also prepare does it in different way in Android, than in iOS.
> On Android, config.xml and androidmanifest.xml is probably recreated
> (destroy previous formatting, what a feature...) and then probably add
> differences, so changes and new options are preserved, however nobody wanna
> read it...
> On iOS, config.xml is completely recreated, no any option is preserved...
>
> So, there are 2 questions...
> If is Android CLI too clever to do preserve changes created by user, why it
> ruins my formatting (new lines, maybe also tabulators)?
> Why is iOS CLI such a stupid? Why it is not able to do it like Android CLI
> (at least)?