Added You.i Engine Support

[pfoster-youitv]

Change list

Added new io.appium.java_client.YouiEngine package to enable Appium to automate interactions with apps built using You.i Engine.

Package includes:

• ./YouiEngine/YouiEngineDriver.java
• ./YouiEngine/YouiEngineElement.java
• ./YouiEngine/internal/JsonToYouiEngineElementConverter.java
• ./remote/YouiEngineCapabilityType.java

Under the test side of the package:

• ./YouiEngine/SanityTest.java - based on the Java Client tutorial
• ./YouiEngine/YouiEngineAppiumSampleTest.java - self contained demo
• ./YouiEngine/util/AppiumTest.java - based on the Java Client tutorial
• ./YouiEngine/util/TestUtiliy.java - common utility methods for tests
• ./YouiEngineAppiumSample.app.zip - target app for above scripts when isAndroid = false
• ./YouiEngineAppiumSample-debug.apk - target app for above scripts when isAndroid = true

No changes made to existing files, only additions to specific to You.i Engine.

Google coding standards were applied with all error-level violations being corrected.

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)

Details

The only difference between writing a test for You.i Engine and any other Appium platform is the use of automationName = "youiengine" and the presence of youiEngineAppAddress. The youiEngineAppAddress must be set to the device's IP address.

Review the YouiEngineAppiumSampleTest.java for one way to write tests against a Youi Engine app using this Appium client. Adjust the capabilities found within this class to suit the environment the test will be run in, including the target device. The same test class can be used for Android or iOS by toggling the isAndroid boolean accordingly.

Supported Platforms

Android and iOS are currently supported.

Requirements

This client requires the appium-youiengine-driver.

Available Interactions

Following is a list of available interactions by supported platforms.

Common

closeApp
findElement*
findElements*
getAttribute**
getContext
getContextHandles
getLogs
getLogTypes
getScreenShotAs
getSessionId
getText
installApp
launchApp
removeApp
runAppInBackground
sendKeys***

* currently supports className, id and name By strategies .
** currently supports name attribute only.
*** special key code support not available.

Exclusive to Android

isAppInstalled
isLocked
lock
lockFor*
toggleData
toggleFlightMode
toggleLocationServices
toggleWifi
unlock

* this implementation takes in the number of seconds to lock the device for.

Exclusive to iOS

lockFor*
mobileShake

* this implementation takes in the number of seconds to lock the device for.

NOTE: Unlock calls will only work when unlocking is set to 'swipe to unlock'.

[philgreenyouilabs]

We will squash these commits.

[TikhomirovSergey]

Hi @pfoster-youitv @philgreenyouilabs
Will review it carefully. I like this PR. But it has to be checked.

[philgreenyouilabs]

Thanks @TikhomirovSergey!

[pfoster-youitv]

Please and thank you! @TikhomirovSergey

[jlipps]

Hi @TikhomirovSergey any movement on reviewing this?

[TikhomirovSergey]

@jlipps @pfoster-youitv @philgreenyouilabs
Guys, I'm totally sorry. Was busy. The great workload on my current job.

Ok. There are remarks.

[TikhomirovSergey]

The first remark is related to checkstile issues.
The way how to keep the code style was described there: https://github.com/appium/java-client/blob/master/docs/Note-for-developers.md#code-style

The current report: site.zip
Plese get these warnings and the error fixed and check it.

• set the path to JDK 7 to the JAVA_HOME
• follow these instructions and https://github.com/appium/java-client/blob/master/docs/Note-for-developers.md#code-style
• fix warning and the error everywhere... except the org.openqa.selenium package.
• also I think that the package name io.appium.java_client.YouiEngine may be changed to io.appium.java_client.youi.engine

[TikhomirovSergey]

ok. Other remarks and concerns:

1. It seems there is lack of new functions. Are any other features going to be added? Is there a new searching engine? How does the searching by accessibility id feel with it?

2. I do not like that the one AppiumDriver subclass has commands for both iOS and Android. It looks like AppiumDriver looked two years ago. It was containing features for both iOS and Android. It was causing confusions and errors. There were any other things. So I and @Jonahss decided to split it to AndroidDriver and IOSDriver. But the problem is not completely resolved. There is an issue: The splitting of AndroidDriver and IOSDriver #398
   We (I'm and @SrinivasanTarget) are going to make:

• the abstract AppiumDriver:
• the abstract AndroidDriver and the abstract IOSDriver which will extend the AppiumDriver;
• AndroidAutomatorDriver and SelendroidDriver which will extend the AndroidDriver;
• IOSAutomationDriver and XCUITDriver (when it will be completely available) which will extend IOSDriver;

New youi engines could be included to the new hierarchy conveniently. What do you think?

3. I have not tried to run the proposed code. But I'm sure that it may not work because these commands are not included to the MobileCommand repository.

https://github.com/appium/java-client/pull/429/files#diff-ce6f39a92ea9fa433bdd2f3f2945f427R79
https://github.com/appium/java-client/pull/429/files#diff-ce6f39a92ea9fa433bdd2f3f2945f427R106
and some other

[TikhomirovSergey]

@SrinivasanTarget could you review it too if you can?

[SrinivasanTarget]

@pfoster-youitv Please fix these: https://www.codacy.com/app/appium/java-client/pullRequest?prid=272208

[SrinivasanTarget]

@pfoster-youitv @philgreenyouilabs I agree with @TikhomirovSergey comments.Here are my remarks,

1.Add AppiumServiceBuilder in tests.
2.I see lot of commented codes here in tests which needs to be removed. https://github.com/YOU-i-Labs/appium-java-client/blob/94992de7988fe9d0699d41a0400ff43e898869ed/src/test/java/io/appium/java_client/YouiEngine/SanityTest.java#L470
3.I suggest to document findBy strategies that appium-youiengine-driver supports.
4.Do we really need YouiEngineElement class, If so how is it gonna be different from MobileElement?

I enforce again to strictly follow code styles.Will run the tests post all the remarks are addressed.

Thanks for your patience.

[simongranger]

The first remark is related to checkstile issues.
The way how to keep the code style was described there: https://github.com/appium/java-client/blob/master/docs/Note-for-developers.md#code-style

Answer: We ran the StyleChecker before but it looks like it wasn't run for the last few commits.

1) It seems there is lack of new functions. Are any other features going to be added? Is there a new searching engine? How does the searching by accessibility id feel with it?

Answer: The ‘new’ functionality this provides is a unified API that test writers can code against. The reason this feature is important is because most, if not all apps written by our users target multiple platforms (We are a cross-platform engine.) Apps that target the same form factor (iOS and Android handsets and tablets for example) will be indistinguishable from a testing perspective. As for new features, for now we need to catch up on the functionality already provided in other drivers. You can find a full list of currently supported commands here: https://github.com/YOU-i-Labs/appium-youiengine-driver.
Where accessibility is concerned, apps built with YouiEngine historically have not been accessible. Unfortunately there is a lack of demand for an accessible video playing app. While we do plan to fix this as we expand into other types of apps it is not currently a feature developers are requesting.

2) I do not like that the one AppiumDriver subclass has commands for both iOS and Android. It looks like AppiumDriver looked two years ago. It was containing features for both iOS and Android. It was causing confusions and errors. There were any other things. So I and @Jonahss decided to split it to AndroidDriver and IOSDriver. But the problem is not completely resolved. There is an issue: #398
We (I'm and @SrinivasanTarget) are going to make:
the abstract AppiumDriver:
the abstract AndroidDriver and the abstract IOSDriver which will extend the AppiumDriver;
AndroidAutomatorDriver and SelendroidDriver which will extend the AndroidDriver;
IOSAutomationDriver and XCUITDriver (when it will be completely available) which will extend IOSDriver;
New youi engines could be included to the new hierarchy conveniently. What do you think?

Answer: A You.i Engine app is developed from a single code-base and deployed to multiple platforms on which it is almost identical in appearance and behaviour. This allows our users to use the same tests across multiple platforms. To facilitate this we would like to provide a single driver API across multiple platforms. Under the hood we will use the existing iOS and Android drivers whenever possible.
After discussing the implementation internally we arrived at the same conclusion. We should split the iOS and Android specific code into separate classes. We typically bridge functionality across platforms by splitting the implementation into pieces one for each platform and one for common code which also delegates to the platform specific implementations e.g.
YouiEngineDriver (The current class)
YouiEngineDriverIOS (A IOSDriver subclass which the YouiEngineDriver delegates to)
YouiEngineDriverAndroid (A AndroidDriver subclass which the YouiEngineDriver delegates to)
YouiEngineDriverIOS and YouiEngineDriverAndroid would only be instantiated if the platformName was iOS or Android and would provide the same API so that the YouiEngineDriver could always call the corresponding method on the delegate driver.
Regarding your planned changes to the class hierarchy, we look forward to them. Providing a single API for multiple platforms will be much easier if the separate implementations share a base class, and hopefully, an interface.

3) I have not tried to run the proposed code. But I'm sure that it may not work because these commands are not included to the MobileCommand repository.
https://github.com/appium/java-client/pull/429/files#diff-ce6f39a92ea9fa433bdd2f3f2945f427R79
https://github.com/appium/java-client/pull/429/files#diff-ce6f39a92ea9fa433bdd2f3f2945f427R106
and some other

Answer: Right, we did have issues with these commands. We will clean this up.

1.Add AppiumServiceBuilder in tests.

Answer: OK, we will do that

2.I see lot of commented codes here in tests which needs to be removed. https://github.com/YOU-i-Labs/appium-java-client/blob/94992de7988fe9d0699d41a0400ff43e898869ed/src/test/java/io/appium/java_client/YouiEngine/SanityTest.java#L470

Answer: OK, we will do that

3.I suggest to document findBy strategies that appium-youiengine-driver supports.

Answer: OK, we will do that

4.Do we really need YouiEngineElement class, If so how is it gonna be different from MobileElement?

Answer: I think we just defined YouiEngineElement using AndroidElement or IOSElement as a template. Doesn’t look like we define anything into it... [Edit]: MobileElement is defined as abstract therefore we need to define YouiEngineElement...

[simongranger]

^^ @TikhomirovSergey @SrinivasanTarget

[TikhomirovSergey]

@simongranger
Sorry for delay

So let go on

You said

Answer: A You.i Engine app is developed from a single code-base and deployed to multiple platforms on which it is almost identical in appearance and behaviour. This allows our users to use the same tests across multiple platforms. To facilitate this we would like to provide a single driver API across multiple platforms.

Ok. But the proposed code looks like the unified functionality is valid for the one supported platform and not valid for another. From this string till the end of the file. So I cant get the reason for the such unifying. Are these commands going to be working for both supported platforms?

Do I clear understand that these changes have not large impact? The specific team and related teams?
Are there the same JSONWP commands as the default Appium supports with few differences? May be...
Is there the same server side with a bit changes? If so then the alternative solution has more profit. How about that:

• You can specify all required additional cammands
• And then (just the example)

Map<String, CommandInfo> yourMap = new HashMap<>();
yourMap.putAll(MobileCommand.commandRepository);
yourMap.put("yourAdditionalCommand", MobileCommand.postC("/session/:sessionId/the/path/to/the command"));

AppiumCommandExecutor executor = new AppiumCommandExecutor(yourMap, new URL("your URL"));
driver = new IOSDriver<>(executor, capabilities);

//and then you are free to
ImmutableMap.Builder builder = ImmutableMap.builder();
         ...
execute("yourAdditionalCommand", builder.build());

I thing it is easy to be facilitated and it is flexible.

Thanks for the patience. Maybe I just missing something. But it is important to make all thing clear and publish the code as robust as it possible. I'm waiting for your answer/suggestions.

[pfoster-youitv]

Lots of good comments here. I'm sorry I haven't responded, I've been on vacation for the last week. I'll catch up with Simon and see what needs to be done.

To be clear - the goal is to have test authors write a single test for an app (not device specific calls) once and be able to use it on whatever platform our You.i Engine automation layer supports. We don't want our test authors to need to write different tests for different platforms to test functionality that will be cross platform.

We are not talking to Android's automation layer and we are not talking to iOS's automation layer for these tests so there should not be a need to distinguish between the two - just talk directly to our own automation layer.

The current disconnect between iOS and Android (in our implementation) are around toggling network settings but we might be able to get around this by calling into our own layer and having it do this instead of trying to use the native automation layers. I'll talk with the team again about this.

[simongranger]

@TikhomirovSergey We have removed the references to iOS and Android in our java driver and will let the Server return an exception for any commands that are not supported. Does that satisfy your requirements?

[simongranger]

@SrinivasanTarget For now, we don't see the use case for the AppiumServiceBuilder and will consider adding it later if necessary.

[simongranger]

Other than the 2 comments just above. We believe we have addressed all the comments. We'd like to get this PR merge before the end of the week :)

[jlipps]

Hi everyone, I've been following this thread off and on and it seems to me that the proposed changes are reasonable. Would be great to get this out and let youi's users start automating via appium if there are no more objections!

[TikhomirovSergey]

I decided to delay the build 4.1.0 for one day.
Guys, Is this PR still needed? May be there is sense to close it without merging.

There is an enhancement (#445) that make access to commands easier.

Also:

• This code is not compiled.
• I do not want to merge copy-pasting
• We are going to automate the building with CI and we want to use default Appium (latest stable versions) server for this. The SanityTest will be failed untill You.i Engine node is included to Appium server builds. So the test is not needed now. Each one command is tested and works ok.

I'm ok if the new driver would look like https://github.com/TikhomirovSergey/java-client/tree/YOU-i-Labs-develop/src/main/java/io/appium/java_client/youiengine. I would like to merge it at this case.
It does the same as AppiumDriver and it might execute mobele OS specific commands eventually. If so then we hope it is going to be developed further and it will contain features that could be "sold" to users.

Also there are plans for the next (after 4.1.0) release:

• To make AppiumDriver the non-abstract class (so may be there is sense to keep java_client repo withoit YouiEngineDriver);
• to make it use any mobile-specific search engine which extends MobileBy (the proposed code can't do it now too)
• to move the swipe to TouchAction.

What do uou think about this?

ping @SrinivasanTarget @jlipps

[SrinivasanTarget]

I totally agree with @TikhomirovSergey comments. 👍

[pfoster-youitv]

Depending on what we see later today, this PR will be closed or changed (to similar to what you've noted).

YouiEngine code is in the server and there is an existing driver already published in NPM. The SanityTest passes on iOS 100% and nearly 100% on Android with these changes. The android exceptions are logged internally to be addressed.

The java client is the only part that is holding back the release and we don't want to have it as an external class to be imported, we want the customers to just be able to get the official Appium files and use them - no extra work.

You would prefer they be a minimal subclass from AppiumDriver and other classes? I thought pulling in the platform specific calls would make it easier for users to call. I can remove that if that's the common practice.

[pfoster-youitv]

Closing this one - there will be another based on conversation with @TikhomirovSergey