Skip to content
This repository has been archived by the owner on May 20, 2020. It is now read-only.

New methods proposal #6

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Open

New methods proposal #6

Changes from 7 commits
Commits
Show all changes
14 commits
Select commit Hold shift + click to select a range
2374122
add mobile methods
vrunoa Jun 4, 2017
9f3e96a
write battery spec
vrunoa Jun 7, 2017
52fd1e3
add communication factors
vrunoa Jun 7, 2017
230c3d1
add battery endpoints
vrunoa Jun 15, 2017
a832a07
add sms, phone endpoints
vrunoa Jun 16, 2017
be39e92
add method for getting battery level
vrunoa Jun 16, 2017
be4ad07
update markdown
vrunoa Jun 16, 2017
f5cc541
remove appium from endpoints
vrunoa Jun 16, 2017
525eb16
define battery level as an Integer
vrunoa Jun 17, 2017
650a9b0
update phone call specs to accept json object
vrunoa Jun 17, 2017
ef3ae0c
remove _send from sms endpoint
vrunoa Jun 17, 2017
90fa797
set Message definition
vrunoa Jun 17, 2017
f0f4ac5
add gsm state
vrunoa Jun 19, 2017
b91d765
add gsm state
vrunoa Jun 19, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 56 additions & 1 deletion spec-draft.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -272,10 +272,65 @@ as follows:
* The virtual keyboard: use sendKeys
* acceleromator: TODO @mdas is working on this
* geolocation: use regular webdriver endpoints
* battery level: not in spec, perhaps exposed via executeScript
* network speed: not in spec, perhaps exposed via executeScript


Battery
-------
Device battery changes might trigger events on users applications, controlling this will help monitor and verify how apps responds to these factors.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

* returns BatteryState


* POST /session/:sessionId/appium/device/battery_state
* accepts BatteryState


A `BatteryState` can be one of two strings:
* 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe mention that this is percent? and should we state that it is a range of integers (rather than real values?).


* GET /session/:sessionId/appium/device/battery_level
* returns [0..100]

* POST /session/:sessionId/appium/device/battery_level
* accepts [0..100]


External communication factors
------------------------------
Receiving messages or phone calls it's usual on mobile devices, having the possibility to mock this events would improve the application reaction on this external factors.

### Phone calls(GSM)
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how are these parameters passed? is it something like:

{"number": <PhoneNumber>, "action": <GsmAction>}

?



`GsmAction`'s would be:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mention that these are strings?


* CALL
* ACCEPT
* CANCEL
* HOLD

The `CALL` action should trigger the mocked call to the device from the `PhoneNumber` provided, then another action should take place in order to complete the flow as in real life.


### 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think just POST .../sms is fine; POST has the semantics of "creating" an sms on the device. but this is a nit.

* accepts PhoneNumber, Message
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is Message? is it just a string?




WebViews and Other Contexts
---------------------------
One common feature of mobile platforms is the ability to embed a chromeless
Expand Down