Some Info.plist instructions appear unordered

[jcesarmobile]

Plugins like cordova-plugin-googleplus need this added in the Info.plist

<config-file target="*-Info.plist" parent="CFBundleURLTypes">
      <array>
        <dict>
            <key>CFBundleTypeRole</key>
            <string>Editor</string>
            <key>CFBundleURLName</key>
            <string>REVERSED_CLIENT_ID</string>
            <key>CFBundleURLSchemes</key>
            <array>
                <string>$REVERSED_CLIENT_ID</string>
            </array>
        </dict>
      </array>
    </config-file>

When we detect a config-file or edit-config tags we output something like this:

Plugin cordova-plugin-googleplus might require you to add 
    <dict>
      <key>CFBundleTypeRole</key>
      <key>CFBundleURLName</key>
      <key>CFBundleURLSchemes</key>
      <string>Editor</string>
      <string>REVERSED_CLIENT_ID</string>
      <array>
        <string>$REVERSED_CLIENT_ID</string>
      </array>
    </dict>
   in the existing CFBundleURLTypes entry of your Info.plist to work

Note that the keys appear first and then the other fields, while it should be key-value

The problem is we use a library we use to read the plugin.xml that converts the content to JS objects, and then convert the JS objects back to XML to show what the user should add to their Info.plist, but the conversion doesn't work as expected.

Only happens when the edit-config or config-file tags include dictionaries

[amitguptagwl]

To parse XML with FXP and parse back to JSON/JS Object

const xml = `<config-file target="*-Info.plist" parent="CFBundleURLTypes">
                <array>
                <dict>
                    <key>CFBundleTypeRole</key>
                    <string>Editor</string>
                    <key>CFBundleURLName</key>
                    <string>REVERSED_CLIENT_ID</string>
                    <key>CFBundleURLSchemes</key>
                    <array>
                        <string>$REVERSED_CLIENT_ID</string>
                    </array>
                </dict>
                </array>
            </config-file>
        `;

        const jsObj = XMLParser.parse(xml, {
            ignoreAttributes: false
        });
        const j2xParser = new J2XParser({
            ignoreAttributes: false
        });
        const result = j2xParser.parse(jsObj);
        console.log(result);

Output

<config-file target="*-Info.plist" parent="CFBundleURLTypes">
    <array>
        <dict>
            <key>CFBundleTypeRole</key>
            <key>CFBundleURLName</key>
            <key>CFBundleURLSchemes</key>
            <string>Editor</string>
            <string>REVERSED_CLIENT_ID</string>
            <array>
                <string>$REVERSED_CLIENT_ID</string>
            </array>
        </dict>
    </array>
</config-file>

[jcesarmobile]

So looks like it has the same problem, the result is unordered

[amitguptagwl]

Well!! Js object doesn't guarantee the order of object keys. So if you're looking to maintain the order then probably array mode or preserveOrder can help. However, in this case the output js obj is little different;

<store>
    locates in
    <region>US
        <part>north</part>
    </region>and
    <region>JAPAN</region>
    <fund>456.34</fund>
</store>

when preserveMode: true

[
    { "store": [
        { "__#text": "locates in" },
        { "region": [
                { "__#text": "US" },
                { "part": "north" }
        ]},
        { "__#text": "and" },
        { "region": "JAPAN" },
        { "fund": 456.34 }
    ]}
]

But I never tried to pass this response to the J2XParser. So yes for the time being, you can say it can't preserve the order. But it is a good user case that I can try. Thanks

[jcesarmobile]

The order is only important for <dict> elements as they contain key-value elements, so <key>CFBundleTypeRole</key> should be followed by <string>Editor</string>. But it's like that because it's used for plist files, that are xml like, but not exactly the same, so I would understand that your library (or any xml library) doesn't handle it.

Another possible approach in the CLI would be to read the edit-config and config-file tags content as text and display it as is.

[imhoffd]

Could we use an XML library to parse the file, ignoring edit-config and config-file, and then use plist for them?

[jcesarmobile]

what we read is the plugin.xml that contains the edit-config and config-file tags, so not sure if plist will work on them, but we can try

[ionitron-bot]

This issue has been labeled as type: bug. This label is added to issues that that have been reproduced and are being tracked in our internal issue tracker.