Added WebDriver methods to unlock device and check whether the device is currently locked #84
Conversation
… is currently locked
There was a problem hiding this comment.
This is really up for discussion. I personally believe that the Appium server should be responsible for this, not the client. If the maintainers decide not to add this, that's totally understandable. It was just helpful for "robustifying" while testing the change.
I'm only running this check on Android because iOS should be back in an unlocked state by the end of the execute call.
There was a problem hiding this comment.
i agree that the server should be responsible for only returning when we're in a known locked state
There was a problem hiding this comment.
so for now, if it's flakey, we can just show users how to add the wait in their own client code. meanwhile, we'll work on making the appium server more responsible :-)
There was a problem hiding this comment.
We'd love to remove wait in each method and make users insert wait in their own code.
(Other clients also don't have wait in Appium client side.)
| Hi @jlipps , @tylersnavely-wf I'm interested to have this functionality in my python code. Do you have some news? This PR is still alive? |
| Sorry @thomascarpentier , I had honestly forgotten about this. I really haven't done anything with the project since this was created. It looks like stripping the additions to |
There was a problem hiding this comment.
Thanks for your PR! I left a comment.
BTW, after merging appium/appium-xcuitest-driver#595, we'll be able to use lock/unlock for XCUITest as well.
| Looking forward to be able to use unlock in Python. Thanks for working on this. |
6 participants
Resolves: #49