+ 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 (ignisvul...@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.ka...@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.gal...@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 <ignisvul...@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ý <vve...@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/> >
