New methods proposal #6
Conversation
spec-draft.md
Outdated
|
|
||
| The battery state should have two options: ON, OFF depending if the power ac state it's charging or not. | ||
|
|
||
| * GET /session/:sessionId/appium/device/battery_state |
There was a problem hiding this comment.
here and in all the following, we don't need appium/device in the endpoint. this spec draft is a draft of what would potentially be an official spec at some point. the appium/ prefix is for appium-specific functionality that would not be a part of this draft. or if we wanted to implement this in appium before its admission into the draft.
so i would recommend one of these two:
GET /session/:sessionId/device/battery_state
GET /session/:sessionId/battery_state
if we have enough things to put behind /device that could be a reasonable global prefix
spec-draft.md
Outdated
| * ON | ||
| * OFF | ||
|
|
||
| In some cases, apps might respond different on low battery level so the idea is to provide a method to set specific battery level for the devices. |
There was a problem hiding this comment.
maybe mention that this is percent? and should we state that it is a range of integers (rather than real values?).
spec-draft.md
Outdated
| * accepts PhoneNumber, GsmAction | ||
|
|
||
|
|
||
| `GsmAction`'s would be: |
There was a problem hiding this comment.
mention that these are strings?
spec-draft.md
Outdated
| ### SMS | ||
| During this days a lot of apps depend on receiving sms, even if they are not messaging platform, apps may want to check sms to validate accounts, send promotion codes, etc. We should add | ||
|
|
||
| * POST /session/:sessionId/appium/device/sms_send |
There was a problem hiding this comment.
I think just POST .../sms is fine; POST has the semantics of "creating" an sms on the device. but this is a nit.
spec-draft.md
Outdated
| During this days a lot of apps depend on receiving sms, even if they are not messaging platform, apps may want to check sms to validate accounts, send promotion codes, etc. We should add | ||
|
|
||
| * POST /session/:sessionId/appium/device/sms_send | ||
| * accepts PhoneNumber, Message |
There was a problem hiding this comment.
what is Message? is it just a string?
spec-draft.md
Outdated
| The idea is to be able to mock phone calls entering the device and handle the actions that triggers; you may want to accept it, cancel or put it on hold. | ||
|
|
||
| * POST /session/:sessionId/appium/device/gsm_call | ||
| * accepts PhoneNumber, GsmAction |
There was a problem hiding this comment.
how are these parameters passed? is it something like:
{"number": <PhoneNumber>, "action": <GsmAction>}?
|
|
@jlipps encourage me to write a proposal for adding new methods for mobile specs.
It would be good to start providing new endpoints for common functionalities available on every mobile device but hasnt been implemented yet; such as battery states, level and external communication factors which can trigger actions on applications that users would like to test.
This idea came up because we already started implementing it for android emulators and is probably going to be used cross-platform, so we should get everybody's opinion before adding new endpoints.
What do you guys think ?