config.xml - Managing the config.xml file for multiple apps based on same codebase

[Rob Willett]

Hi,

We're trying to work our way through to find a simple solution to a problem. 

Currently our app works find and is available on the UK App store and UK Google Play store. No issues with that. 

We've had requests to produce a simpler version of the app, which cuts out a lot of functionality. We have no issues with putting simple checks around chunks of our code to remove certain bits of code. Most of this would be around the URL/Screen routing so certain screens aren't available. This poses no problems. It's similar to conditional compilations. As our code is reasonably well structured it will still work.

However what we want to do is to produce a new config.xml id and and version number (we know its a string). 

What we want to do is a have a single code branch, with a number of different config.xml files which have different configurations. We may have three versions of the app, which requires three different versions and ids. 

Is there an easy way to do this? 

Checking Google I found this

http://stackoverflow.com/questions/28367239/multiple-config-xml-files-for-cordova

which says we can't do it.

Our best thoughts (mmm... not sure if thats right) was to have

1. Multiple config.xml files which are moved into place by the build process. This means we have to keep multiple config.xml files synced and up to date.

2. We generate the config.xml by the build process from a single config.xml file template. This is more complicated but not that difficult and it means we have a single template and a more complex build system which is fine.

3. Something else we haven't thought of or are not aware of (same thing really).

We did look at creating multiple code trees with symbolic links and decided that we'd rather poke our eyes out with a stick, pour honey into them and shove our head in an ant colony. That would be a "no".

Any suggestions or views on this welcomed. 

One final question, is it possible to have a setting in the config.xml file that we can query in JavaScript so that we don't set a flag in JavaScript but inherit it from the config.xml file.

e.g.

<preference JambusterVersion="Light"/> OR

<preference JambusterVersion="Pro"/>

with a function call in JavaScript 

switch (GetConfigXMLPreferenceVariable("JambusterVersion"))

{

    case "Light": break;

    case "Pro": break

}

or similar.

If we could do that we could do an automated config.xml build and generate new apps from the build process alone.

Thanks

Rob

[Kerri Shotts]

Hi Rob!!

I think I'd go about it by modifying your project structure and build process to consider Cordova projects as build artifacts. I'd say you could just fiddle with the config.xml a bit and probably get it to work, but I suspect you'd really need to rm and add the platform each time you did so to be perfectly sure something didn't go awry. If that needs to happen anyway, you may as well have separate projects with different config.xml files. Your main "www" would then essentially be a level up, and copied into each Cordova project at build time. 

So your structure might look something like this:

your-app/

    package.json

    www/

    config/

        com.rob.appA.xml

        com.rob.appB.xml

        ...

    builds/

        appA/

            config.xml (copied from ../../config/com.rob.appA.xml)

            www/ (copied OR compiled from ../../www)

            platforms/ (etc.)

        appB/

            config.xml (copied from ../../config/com.rob.appB.xml)

            www/ (copied OR compiled from ../../www)

            platforms/ (etc.)

    ...

If only a couple settings are changing in each config.xml file, you could easily have a config.xml template, use sed (or other method) to do a search & replace, and then write the resulting config.xml to each app's build directory.

As for reading the config.xml file -- this(cordova-plugin-appsettings) plugin might work. Haven't tried it though.

Hope that helps some?

On Friday, July 8, 2016 at 1:30:36 AM UTC-5, Rob Willett wrote:

....

[Rob Willett]

Kerri,

Thanks for this. I think I can see your logic here , we think we have come up with a combined version of your idea and ours.

Your suggestion is sliding the code base under predefined config.xml files, ours was originally sliding new config.xml files over a predefined code base:) The major changes in the config.xml file are new splash screens, removing some redundant access-origin statements, changing the version and id strings over and a different background geolocation license key. Not massive changes, the splash screens will just be different PNG files so its only around 8-10 lines in total.

I'm unsure why you would need to add/rm the platform each time but your suggestion doesn't need that so it may be moot anyway. 

We've worked through a couple of whiteboard exercises and we *think* we can do the following which is a mixture of everybodys thinking :) 

1. All our directory systems within Cordova are standard and out of the box. e.g. the only file *we* edit in the application root directory is config.xml 

2.  All our directory systems in <ROOT>/www are standard as well, we have a templates directory, a TS directory where we store our TypeScript files, a JS directory where we store the created JavaScript files, a CSS directory etc etc,. Nothing radical. The only file we change in here is the index.html file. 

3. We create a new super root folder where all versions of the app will be stored. This your-app in your tree.

4. Each app has its own folder underneath as per your tree.

5. We create new project with ALL the right version numbers etc at a sub level (as you have done). This has a default www directory underneath it. 

4. We rename the current application as the master application. This sits in the top level (as yours does)

5. However we symbolically link www/ts, www/css, www/img. www/templates etc etc from the master to the NEW application version we have created. This means that we make changes to the master and then ALL versions of the applications get it. We use different index.html and config.xml files for each application though they will be very, very similar. 

6. No changes are required to the build process for each app, we symbolically link the 4-5 build files as well to the master copy. 

7. We are actually ruthless about directory management anyway, but since the symbolic links are relative as opposed to absolute we can copy the root directory around and we preserve those links. 

This means:

1. Our Jambuster build directory will get bigger as it stores all version, no big deal.

2. We only have one version of the truth (or code).

3. We can still use our build processes on our Macs with minimal change.

4. We can copy the whole directory as we have a master build directory. 

5. We can create new versions of the app by running a build script which sets everything up. 

6. ...

7. ... 

8. Profit

We'll kick this off later in the week and see how it goes. Monday is get a test build out as we're behind schedule.

Thanks

Rob

--
-- You received this message because you are subscribed to the Google
Groups "phonegap" group.
To post to this group, send email to phon...@googlegroups.com
To unsubscribe from this group, send email to
phonegap+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/phonegap?hl=en?hl=en
 
For more info on PhoneGap or to download the code go to www.phonegap.com
---
You received this message because you are subscribed to the Google Groups "phonegap" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phonegap+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.