You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Widget is trying to be located by variable name #307
I have one widget that is trying to be located by variable name, when it should be located only by AndroidFindBy locator. This happens when I am debugging the test. There is a server log snippet in the gist that contains the logs for searching after variable name.
Is your app native or hybrid? Is this native or HTML content?
Also
It is failed when you are trying to test app version for Android (I know that this question is silly, but I'm seeing iOSFindBy)? Have you read the text of this PR?
Do you use exactly AndroidDriver? Is there your own subclass of the AppiumDriver? Can I take a look at full server output (gist)?
I am using a native iOS & Android app. I use only native context. This happens when I run from iOS context, my driver is an instance of IODriver or AndroidDriver exactly, depending on the device I want to run the test.
When I get back to the office I will upload full log for both cases:
when I run the test on android
when I run the test on iOS
And yes, I have read the documentation. I have 3 types of widgets in my code:
If the widget do same things the same way you are free to
If Android and iOS widgens do same things at high-level, but ways thisngs are done have some special things then you can
@AndroidFindBy(locatorforandroid)
publicclassAndroidNavigationDrawerextendsNavigationDrawer {
@AndroidFindBy(locatorforandroid)
@CacheLookupprotectedMobileElementmChartMenuItemTxtView;
@AndroidFindBy(locatorforandroid)
@CacheLookupprotectedMobileElementmLogbookMenuItemTxtView;
//and so on
@iOSFindBy(locatorforios)
publicclassIOSNavigationDrawerextendsNavigationDrawer {
@iOSFindBy(locatorforios)
@CacheLookupprotectedMobileElementmChartMenuItemTxtView;
@iOSFindBy(locatorforios)
@CacheLookupprotectedMobileElementmLogbookMenuItemTxtView;
//and so on
It looks like you are using invalid ids for Android. I've read Android logs and seems that it couldn't find element by id="navigation_view". But I'm not sure. If it is true so please try with this id: your.app.package:id/navigation_view
Many thanks for looking into this, your help is much appreciated.
Yes, the serverLog was iOS log as well.
I was thinking that if I create a widget that uses only AndroidFindBy locator then this one will be searched only when in Android and when being in iOS that won't be searched at all. Actually that widget does not exist in the iOS version of the app.
I will use the abstract implementation or something else, no worries there. What about the Java wiki?
There are many cases such as yours that should be documented. I think it is not convinient to search in PR descriptions. So I want to aggregate info at WIKI.
Activity
TikhomirovSergey commentedon Feb 2, 2016
Hi @fabianaapateanu
I have some questions?
Is your app native or hybrid? Is this native or HTML content?
Also
It is failed when you are trying to test app version for Android (I know that this question is silly, but I'm seeing iOSFindBy)? Have you read the text of this PR?
Do you use exactly AndroidDriver? Is there your own subclass of the AppiumDriver? Can I take a look at full server output (gist)?
fabianaapateanu commentedon Feb 2, 2016
Hi,
I am using a native iOS & Android app. I use only native context. This happens when I run from iOS context, my driver is an instance of IODriver or AndroidDriver exactly, depending on the device I want to run the test.
When I get back to the office I will upload full log for both cases:
And yes, I have read the documentation. I have 3 types of widgets in my code:
Isn't this ok?
TikhomirovSergey commentedon Feb 2, 2016
Yeah. It is ok. i'm waiting for your logs...
fabianaapateanu commentedon Feb 2, 2016
Sorry for delay, updated gist
https://gist.github.com/fabianaapateanu/2566308f12437ccc7007
TikhomirovSergey commentedon Feb 3, 2016
Ok. It was difficult to read logs but I managed to do it :)
And I see two problems.
These strings were taken from files serveriOSLog.log and serverLog.log
This is iOS log. (!!!) It looks like you are trying to use Android widget-object against iOS app. It seems that this sample proofs my concerns: https://gist.github.com/fabianaapateanu/2566308f12437ccc7007#file-navigationdrawer-java-L2. Here is only AndroidFindBy
How to resolve
If Android and iOS widgens do same things at high-level, but ways thisngs are done have some special things then you can
and then
Please read this text again #267. Also you can take a look at current tests: https://github.com/appium/java-client/tree/master/src/test/java/io/appium/java_client/pagefactory_tests/widgets
It looks like you are using invalid ids for Android. I've read Android logs and seems that it couldn't find element by id="navigation_view". But I'm not sure. If it is true so please try with this id:
your.app.package:id/navigation_view
TikhomirovSergey commentedon Feb 3, 2016
@fabianaapateanu
I'm waiting for your response.
I've got some idea. What about Java client wiki?
fabianaapateanu commentedon Feb 3, 2016
Hello @TikhomirovSergey,
Many thanks for looking into this, your help is much appreciated.
Yes, the serverLog was iOS log as well.
I was thinking that if I create a widget that uses only AndroidFindBy locator then this one will be searched only when in Android and when being in iOS that won't be searched at all. Actually that widget does not exist in the iOS version of the app.
I will use the abstract implementation or something else, no worries there. What about the Java wiki?
TikhomirovSergey commentedon Feb 3, 2016
There are many cases such as yours that should be documented. I think it is not convinient to search in PR descriptions. So I want to aggregate info at WIKI.
@fabianaapateanu
Can I close this ticket?
fabianaapateanu commentedon Feb 3, 2016
Oh, ok I see, sure.
@TikhomirovSergey
Please do close it, yes. Many many thanks!!!
TikhomirovSergey commentedon Feb 3, 2016
Closed!