Add a possibility to parse initial values for Appium settings from capabilities

[mykola-mokhnach]

Proposed changes

It is sometimes necessary to set some particular appium setting per session. This feature will allow to pass default Appium settings values in capabilities, for example

{
        platformName: 'foo',
        browserName: 'bar',
        'settings[settingName]': 'baz',
        'settings[settingName2]': 'baz2',
}

so there is no need to separately call updateSettings API after the session is created.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

[jlipps]

nice idea! any reason you chose to put each setting as a string of the form settings[setting] rather than just adding a new cap called settings which has a value of type object? seems like that obviates the need for pullSettings entirely. might be a little harder to construct the cap client side, but every language i've seen has the possibility of complex capability values.

[jlipps]

why are we merging jwp settings into w3c settings? below these seem like exclusive options

[mykola-mokhnach]

I've seen the cases where the client sends jsonwp caps only, but the request contains firstMatch/alwaysMatch props. In such case we assume the client supports W3C and merge jwp caps to w3c ones

[jlipps]

i'm having trouble imagining the need for a recursive case...?

[mykola-mokhnach]

this might be the case for w3c caps, where they have firstMatch and alwaysMatch properties

[mykola-mokhnach]

I've changed the logic there. Now it's no more recursive

[jlipps]

what about a test for a setting that has an object as a value?

[mykola-mokhnach]

sure, will add

[mykola-mokhnach]

any reason you chose to put each setting as a string of the form settings[setting] rather than just adding a new cap called settings which has a value of type object? seems like that obviates the need for pullSettings entirely. might be a little harder to construct the cap client side, but every language i've seen has the possibility of complex capability values.

This is not very straightforward in java/C#, where one has to create a JSONObject first and put all the necessary values there. Also, I usually don't see a need to set multiple setting values at once. The current syntax looks more natural to set a couple of setting values. In the worst case we could also add a possibility to set settings[*], if this is really needed

[dpgraham]

I'd like a link to http://appium.io/docs/en/advanced-concepts/settings/index.html so we know what "Settings" are.

[mykola-mokhnach]

see below, the link is already there

[dpgraham]

Maybe const [, settingName] = /\bsettings\[(\S+)\]$/.exec(key);

[mykola-mokhnach]

this will throw if match is not an array

[dpgraham]

Can we still have a variable called settingName to make it more clear what's being parsed.

const [, settingName] = /\bsettings\[(\S+)\]$/.exec(key) || [];