* allow both 'value' and 'text' params for setValue
this introduces a 'makeArgs' option for the spec which allows handling of more complex scenarios.
* clarify some variable names and add fuller commentary
* Added a test for unzipFile (which uses adm-zip)
* Tested that it worked with adm-zip and then failed once adm-zip was taken out
* Replaced 'adm-zip' with zip.extractAllTo from appium-supprt
* Update hash
* Add validateCapabilities and parseCapabilities
* Added merge capabilities
* Moved capabilities into it's own file
* Added capabilities as a possible required param
* Can pass desiredCapabilities or capabilities into createSession
* Remove 'required' desiredCapabilities
* desiredCapabilities isn't required any more because we can provide capabilities as well
* Will need to update validation logic in 'driver.createSession' to do the validation there instead
* Code cleanup
* Skip presence constraint in parseCapabilities
* We don't need to check that items are present until after we've formed the matched capabilities
* Added validation function to routes
* Function 'validate' takes params as an arg and then returns a message if the validation fails
* Uses this to validate that either "capabilities" or "desiredCapabilities" was provided
* Renamed capabilities to caps
* Move caps required validator from process to parse
* Removed InvalidParametersError
* Update BadParametersError so that if a message is added as the 3rd argument it shows a different error message
* Made validation re-usable
The webdriver spec specifies that requests where the method is POST
should be parsed as JSON (see https://www.w3.org/TR/webdriver/#processing-model step 6).
Appium is too restrictive. It only parses as JSON if the application/json
Content-Type is provided, making it incompatible with some Webdriver clients
that follow the spec but don't send a Content-Type header.
This commit makes Appium less restrictive by defaulting to the application/json
Content-Type if none is provided.
APK files were not being installed because they were being written to a file without an "apk" extension. So added back the appExt suffix logic. If it's given and the downloaded file is not a ZIP file, then everything behaves normally. If the downloaded file is a ZIP file, then regardless of what we thought initially, it will be unzipped and placed into another temp location.
Sometimes you can't tell the file type from a URL. Let URL minimizers or
if there are parameters, etc. So just check the content type of the
response. If it's a zip file, ensure it gets unzipped in subsequent
logic. Otherwise, assume it's an app file.
ProxyRequestError will be thrown for all unsuccessfull proxy requests, ProxyRequestError will contain the actual error route cause information(`jsonwp`)
Bruno Alassia