-
-
Notifications
You must be signed in to change notification settings - Fork 765
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to inherit from MobileElement class for version 3.1.0 #220
Comments
Hi @alewang <build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.3</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<compilerId>eclipse</compilerId>
</configuration>
<dependencies>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-compiler-eclipse</artifactId>
<version>2.5</version>
</dependency>
</dependencies>
</plugin>
...
</plugins>
</build> If it is not acceptable solution and it extremally needs to use eclipse then it needs time. Which Eclipse version do you use? I use Eclipse Luna. There are many plugins are installed for my needs (Spring, JBoss tools and more). When I use this Eclipse instance the code like yours is compiled. When I use another instance without these plugins I'm facing the same problem. So one of plugins or their companents manages this code to be compiled. So there is lack of information about Eclipse configuration at README (this info is for contributors). Why do you have to extend MobileElement? There are two interesting points. The first is that it is possible to find more simple solution. The second is.. I think about a new feature for Appium java client. Maybe it is your case. :) |
I'm working on your problem... |
Thanks for the help. I will give this a try today. |
Our reason for why we want to extend MobileElement is that we want to cache some data about an element so that we do not have to query the Appium server for that data each time. In one of our particular cases, it was most natural to have the element object itself maintain a reference to its own cached data, so we tried doing that by extending the MobileElement class. We saw an interesting surprise when we changed the java-client version to 3.1.0. |
Yeah! It is compiled some unusual way in order to avoid excessive casting from WebElement to MobileElement. Users complained so much. But java has some restrictions. Why do you not use page objects? Page object design pattern. Page factory for java client. |
I'll take a look! Thanks for the help. |
Do IDEA and it's settings help you? It is not possible to solve this problem only on Appium side. Fortunately I have a good idea... ;) |
Minor improvements of the method declaration
I tried IDEA 14.1.4 with the updated settings in the POM file, but the same error shows up on the child class. I'm thinking about ways to solve this, and I think the cleanest solution might be for me to go to Selenium's source and open a pull request to make their RemoteWebElements class parametrized. When I have some time, I'll try doing that. |
Have you tried to change java compiler to "Eclipse" in IDEA? It's workaround for now
Actually I'm aready doing this. I'll add some improvements to this PR today or tomorrow: SeleniumHQ/selenium#604 Actually we've tried to propose something similar. That change was rejected. I just forgot about generic construction that you can see here: SeleniumHQ/selenium#604 |
Neat, I didn't know I could change the compiler. The error just shows as a warning with the Eclipse compiler. |
For somebody who doesn't know how to change compiler
@afwang It will just allow to compile a subclass. |
Please look at SeleniumHQ/selenium#863 |
Fixed at #413 |
I am unable to inherit from the MobileElement class. One of the samples of the errors I see is:
I took a look through the source code, and it seems the cause is due to the DefaultGenericMobileElement class (MobileElement's parent class) extending from RemoteWebElements and implementing the various interfaces. The method signatures in RemoteWebElements and the Generic* interfaces match exactly, but they have different return types. RemoteWebElement's methods' return types are of the type List, while the return types for the various interfaces are List (with T being the parametrized type).
I would like to extend from the MobileElement class for some very specific functionality. I tried using the @SuppressWarnings annotation with various names (including "all"), but nothing seems to tell Eclipse that this error is not a problem.
What can I do on my end to "fix" this error?
What can I do for Appium to prevent these conflicting, overlapping methods with equivalent signatures from well.... overlapping?
The text was updated successfully, but these errors were encountered: