cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From purplecabbage <purplecabb...@gmail.com>
Subject Re: One platform development vs. Cordova CLI
Date Tue, 15 Jul 2014 10:30:39 GMT
+ 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 <tommy@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" <tommy@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 <ignisvulpis@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ý <VVelda@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/>  
> 

Mime
View raw message