I'm new to Appium and automation in general.
I'm trying to write a login test. I have six separate LinearLayout elements and in each of them I need to insert the value "1". I can identify the element (e.g. the element with the id "container_zero"), but I cannot send the value to it neither with the sendKeys() nor with the setValue() method.
Also, I tried just to type the required digits using the keyboard below (see the screenshots). But as this is a custom keyboard of the app (not a native Android keyboard), I cannot interact with it. I tried the method driver.pressKey(new KeyEvent()) with AndroidKey.NUMPAD_0 and AndroidKey.DIGIT_0 parameters - didn't work. Keyboard has none elements inside on which I could click (it's just a single element with the android.view.View class).
I also have an idea to press the required digit on the custom keyboard using the coordinates (X,Y), but I don't think that this is a good way out (maybe when I launch the test on different devices, the coordinates will be different - correct me if I'm wrong).
Please advice what can I do? I thought about using Espresso at this point, but we have the same app on iOS, so for now I think I would try to stick to the Appium for a little while longer due to its cross-platform feature.
but I cannot send the value to it neither with the sendKeys() nor with the setValue() method. - that is correct, you can see attributes of the element and it is not checkable, clickable, focusable etc. So that means that you are not able to sendKeys() or even click() on it.
Also, I tried just to type the required digits using the keyboard below (see the screenshots)... - that is the correct behaviour (related to your particular example) too, because there are no different elements of the buttons, only one FrameLayout for the whole keyboard.
I see two scenarios:
You can ask developer to enable button elements so you will be able to click() on it
You can calculate coordinates of these buttons in accordance with screen dimension, for example: 1 button = getWindowSize().getWidth() + 50, getWindowSize().getHeight() / 2;.
This scenario is very unstable because of different devices, but it could work if you find correct dependency between dimension and button positions.
Altogether you either need developer intervention or not so easy calculations for coordinates.
Related
I am facing an issue, In this case terms & conditions and privacy policy. two links are part of one class only and I am not able to click on privacy policy, but terms & conditions click works all the time by using that id.
There is no easy way to do this since Appium recognises it a a single element.
Luckily, you can do the following steps:
Find the TextView element
Determine the position of the elements top-left corner
Determine the TextView width and height
Calculate approximate coordinates for Privacy policy link based on width/height and start position (top-left corner)
Use the Actions
API tap method to click by coordinates
There is an article from Appium team that addresses a similar issue and provides Java code sample.
I want to create a sort of inline list of clickable text blocks in Android Studio. Below is the closest image I could find to the effect I would like. How would I achieve such an effect?
The information shown will be just a string, however clicking on this will take the user to another activity. It would be good if the text blocks also had a background, by the looks of it this app uses an image as the background, which should be fairly easy to set if the list is made from text views. I just don't know how to make a list with variable length inline objects.
See here: https://github.com/google/flexbox-layout
What I was looking for was specifically a horiztonal, wrapping, inline list.
I am able to use WindowsAccessBridge.dll to get access to java window (SwingSet2), and use the dll methods to interact with the controls.
I can iterate the tree (of java controls) using code shown here, and get information from the controls,
and I can do actions like SetText in Text box, or send click action to a button etc.
However, I am finding that the accessibility contexts are not consistent:
The SetText method works perfectly when I use the accessibility context got from the 'setMousePressedFP' method of the dll, after clicking on the text box.
However, I cant use the accessibility context got by iterating the control tree when trying to set text in a text box, although I verified that the other information e.g. size and other properties of the text box is same.
From this doc:
"The functions GetAccessibleContextAt and
GetAccessibleContextWithFocus retrieve an AccessibleContext object,
which is a magic cookie (really a Java Object reference) to an
Accessible object and a JVM cookie. "
However, the accessibility context differs everytime I click on the text box (without restarting the java program). The vmID matches eveytime.
If the AccessibleContext is really a Java Object reference, shouldnt I get the same AccessibleContext number everytime I click on the same control (without restarting the java window) ? and shouldnt that AccessibleContext number also be available in the tree?
Worst part is that the settext method doesnt work when I use the AccessibleContext got from iterating the control tree.
Edit to clarify the question further:
I am clicking on the same text box, so I would expect the windowsaccessdll function to return reference to the same control. As a long value the accessibeContext is different everytime I click, but its ok as the SetText method works everytime with the different long values and I can see the new text set in the text box.
The problem is when I iterate the control tree and the accessibility context got from the tree iteration doesnt work for the SetText method.
More specifically - how does the AccessibleContext compare to a c pointer - the c pointer would always be same when I get it for a specific control. The AccessibleContext appears to be a 8 digit long value that is different by few tens or hundreds based on where the mouse is clicked inside the text box.
Thanks in Advance.
I am using list-field in a BlackBerry application. In each list-field item, I have a bitmap-field at the left, text at center and again a bitmap-field at the right.
Can I determine whether the fields are focusable inside the list-field rows for keypad versions of BlackBerry Devices for e.g BlackBery Tour?
No in list field no control except whole row is focusable explicitly. If you want to perform any click events you can use touchEvent() but the calculation will be too complex and not so reliable.
If you want to have separate clickable items in one row you must use HorizontalFieldManager each time.
Update: : I have come across this scenario twice, and if I were in place of you I will consider what exactly the feature is about, If you are concerned about UI and there is not any heavy functionality behind focusing you can try touchEvent or navigationClick but using both will be cumbersome. Too much logic, too much thinking, hard to test.
If there is any functionality, you have an option to add them on menu, It will be more convenient way than using horizontal field manager or the above mentioned methods.
I just started yesterday using GWT, so maybe I'm not using the proper mechanism to solve that problem. So, I will try to explain exactly what I'm trying to do (with a simple problem) and 2 solutions I came up with to address that problem.
Problem:
Remember an index that can be updated via other widgets. Let's use focus to represent it.
[button 1]
[button 2] [button A]
[button 3]
The buttons [1..3] and [A] are not in the same class and need to find the element using the id using the DOM. The reason is that those 2 views needs to be orthogonal.
We can use up/down key to move the focus from button 1 to 3.
If we are on the buttons [1..3] and press right, we go to button A.
If we are on the button A and press left, we go to button previously focused.
What we want to do is save or set the focus index when pressing right.
Solution 1: Global variables
I'm not usually fond of global variables, but in some case it's handy. By using, for instance, a dictionary (Dictionary.getDictionary) defined globally in the javascript, I could save the current index in it using the "Focus Event" in that case.
So, in the key press event, when left would be fired, I would just read the value in the dictionary.
I haven't tested yet, but I think it should work.
Solution 2: Set the value with the Element
Element element = DOM.getElementById("button id A");
element.<setFocusLeftKey>("button id [1..3]");
Here what I would like to achieve is just in the "onFocus" Event, I would simply set the value of that button.
So is it possible to cast/find the object with the Element? I think that if there is no easy way, it's probably because it's not recommended.
Is there a simpler way/other method to achieve that?
So, any thought or solutions?
Thanks in advance.
P.S. I haven't found a better title for that, so if any suggestion, just put it in the comments and I'll update it.
Using ID is definitely not the suggested way to do this in GWT. You say you need this mechanism to keep your views orthogonal to one another. This is noble, but in GWT you would achieve by using another resource (an EventBus, implemented in SimpleEventBus) that hides the different components from one another. In fact, I would argue that looking up the element by ID strongly couples the two views and is smelly.
Armed your EventBus you simply create and fire custom events that let the views (or, better, their presenters) communcate with one another. For example here you could have: NavigateRightFromButtonsEvent and NavigagteLeftFromButtonA event.
However, depending on the size of your app (or as a first experiment) you could decide to couple your two views. In this case simply pass the view for the button list into the one for button A and vice-versa. This is not really worse than relying on a global ID.
No matter which mechanism you choose (event bus or wiring the views together), you should now have access directly to the instance of the widget you want to highlight. To focus, just call setFocus(true) on it.