My situation
I want to write UI-tests for an Android App and therefore I need to scroll in some of the App's fragments. The tests are written in Kotlin, Appium version is v1.15.1 .
My problem
I use the standard approach for scrolling(see below) and it works fine, as long as the coordinates of my starting point don't fall onto a clickable element. I also observed this behaviour when navigating through the App with the Appium Desktop Inspector.
My current approach
PlatformTouchAction(driver as AppiumDriver)
.press(PointOption.point(100, 500))
.waitAction(WaitOptions.waitOptions(Duration.ofMillis(1000)))
.moveTo(PointOption.point(100, 100))
.waitAction(WaitOptions.waitOptions(Duration.ofMillis(1000)))
.release()
.perform()
As mentioned before this works if the starting point (100,500) is not on a clickable element.
If for example a button happens to be at (100,500) the scroll/swipe is not performed, but in fact on scroll listeners are still called.
You can scroll with help of resource id of element. This can be achieved with UiAutomator2 as automation engine. You need to use automation name as UiAutomator2 in desires capabilities.
Add in desired capability UiAutomator2 if you are using appium as automation engine.
capabilities.setCapability(MobileCapabilityType.AUTOMATION_NAME, "UiAutomator2");
Now use below functions if you have element's resource id, and index as 0 if there is one element on page.
public void scrollByID(String Id, int index) {
try {
driver.findElement(MobileBy.AndroidUIAutomator("new UiScrollable(new UiSelector().scrollable(true).instance(0)).scrollIntoView(new UiSelector().resourceId(\""+Id+"\").instance("+index+"));"));
} catch (Exception e) {
e.printStackTrace();
}
}
This is dynamic approach it will scroll till element is not visible.
Related
I tried to test a webview in flutter app using flutter appium driver and faced a problem:
In a webview I have a text, that is placed in two lines. Because of that placing text is covered by another element.
I tried 3 approaches:
1.appium driver: mouse.moveTo then mouse.click.
Solution with mouse.moveTo then mouse.click did not work because appium need other parametr called duration, that is not included to parameters in our appium_driver.
2. Used flutter inspector to locate elements on the webview - solution was not succeed because this webviews are external and were not covered by any flutter overlay.
3. Clicking by bounds
Got all objects from the webview with TESTWorld().appiumDriver.pageSource. Found out that we have the xml with all objects on webview with properties as bounds,text. Made a list with 3 objects of “MyString“ string and clicked on them one by one with click() method from appium_driver. Second element “MyString“ is clickable, appium can click on it, but first instance of this string is in two lines, so this element is part of other big element, that’s why appium_driver can’t click on it.
Maybe someone knows another approach?
Because of that placing text is covered by another element
In a particular case, it sounds like an AUT issue. Appium uses WebDriver API for testing WebView and it is expected to not be able to interact with the overlapped element.
If there is no way to address and fix it in the app, you can try JS to send a click action (the same way we do in Webdriver):
WebElement textElement = driver.findElement(...);
JavascriptExecutor jsEx = (JavascriptExecutor)driver;
jsEx.executeScript("arguments[0].click();", textElement);
enter image description here
I want to know how to provide the numbering for each tab, so that author can provide the number as per their requirement.
This is the strangest requirement I ever heard of. You can sure do that, but it didn't make much sense of doing it system wide as one author can feel the dialog one way, other in completely different. The only reasonable solution is to use javascript to reorder the tabs in the way an author want and than save the settings for this specific component in his user profile. You can start implementing it by creating a clientlib with the category cq.authoring.dialog. In your JS you have to listen to specific dialog loading event as shown below. I think this should be enough and it's a good starting point.
// necessary as no granite or coral ui event is triggered, when the dialog is opened
// in a fullscreen mode the dialog is opened under specific url for serving devices with low screen resolution
if (location.href.match(/mnt\/override/)) {
$(window).on('load', function(e) {
setTimeout(doSomething, 100);
});
} else {
$(document).on('dialog-ready', function(e) {
Coral.commons.ready(function(){
setTimeout(doSomething, 100);
});
});
}
You can use granite:rel to define specific identifiers in the dialog definition and use save them later in the user settings. You can define drag & drop events using the tab selector [role="tab"].
This is not trivially possible. Decide upfront about the order when building the component, provide meaningful labels and go with that. Touch UI does not provide the feature you need.
I'm starting a new activity to display a leaderboard in my Android App.
When the leaderboard activity is displayed, and the user presses the home key and then resumes the app (so the leaderboard activity comes up again), and then navigates back to the main activity by pressing the back key, the back key and volume keys stop working).
I've attempted to override onBackPressed in my activity class. I can confirm that when this problem occurs, onBackPressed is not called (When back / volume is working, pressing back does trigger onBackPressed).
Normally I get a message in LogCat when I press the back key 'Unimplemented WebView method onKeyDown called from android.webkit.WebView,onKeyDown(WebView.java.2178)' - Again I can confirm that this message doesn't come up when the back key isn't working
Armed with the above information, I can only assume that it's something to do with the View not having focus or something along those lines. I would point out that touch input on the screen itself does work. It just seems to be the back and volume keys/buttons that have no effect.
It's an openGL ES 2.0 app so in my onPause() I'm calling view.onPause(); and in onResume, I'm calling view.onResume();
I really have no idea what's going on and I've been on this for 3 days straight so if anyone can point me in the right direction, that would be great.
If the user comes out of the leaderboard and back into the main app before they press the home key, then everything is OK, it's just if the home key is pressed while the leaderboard activity is displayed as described above.
So when I'm at the point where the back / volume keys aren't working, if I click my scores button and fire up the leaderboard activity again, they work. On returning to my activity, they stop working again.
Not sure if this is relevant at all but the following shows how I'm starting my leaderboard activity:
if (scoresButtonPresses){
displayLeaderBoard();
}
void displayLeaderBoard(){
//Display the leaderboard if already signed in
if (checkSignedIn()){
startActivityForResult(Games.Leaderboards.getLeaderboardIntent(getApiClient(), leaderboardID), 1);
}
//if not already connected, then set flag and connect to play services before displaying leaderbaord
else{
signInAction=SHOW_LEADERBOARD;
getGameHelper().beginUserInitiatedSignIn();
}
}
#Override
public void onSignInSucceeded() {
//If the flag is set, then display the leaderboard
if (signInAction==DISPLAY_LEADERBOARD){
startActivityForResult(Games.Leaderboards.getLeaderboardIntent(getApiClient(), leaderboardID), 1);
}
//Otherwise, reset the flag and take no action
else {signInAction=NO_ACTION;}
}
This is driving me crazy so any help or even a nudge in the right direction would be very much appreciated!!
Edit
After much testing I have learned a couple of things:
If I remove the view.onPause() && view.onResume() the problem seems to go away. So this appears to be something to do with the way key events are captured by the view. Pausing and resuming seems to mess something up.
I have also tried removing the view.onPause() and view.onResume() as above, but instead, putting in View.setVisibility(View.GONE); and then making it visible again in public void onWindowFocusChanged(boolean hasFocus). Again, I get the same problem. Interestingly, when I open the leaderboard, as expected the view's staus is 'gone' then hitting the home key and running the app again, it's set back to 'visible' - I don't understand this behaviour but I'll ask another question for that.
Lastly, and this I find really odd. If I put my app back to as I had it, then after hitting the home key and relaunching the app via Eclipse (and I can do this multiple times) the problem doesn't seem to occur. So in that respect, it appears to be something to do with touching the screen.
Edit
It appears as though this isn't limited to my app. I've tested this on a couple of other apps from the Play store and get the same result.
One app clearly uses a single activity model like mine and the back and volume stop working throughout the app.
The other may use a different activity for it menu and game. When I test on this app, the back/volume breaks but if you start a game (therefore a second activity), the back key starts working again, even when you return to the first activity (recreated this activity?!)
So maybe I can get around this by ensuring the activity is recreated? I thought i was already but maybe I'm not getting something. Maybe it's something to do with the stack.........
I have no solution to your problem but some additional insights since I'm facing the same bug/problem with the leaderboards and the back button (and it's driving me crazy).
I'm using a single activity with fragments from which I login to Google Play, open Leaderboards and Achievements in the exact way you are doing it (startActivityForResult). Always when I come back from any Google Play Service activity my back button is broken. Sometimes it's even enough if I try to login to Google Play for it to break, meaning the login popup sometimes breaks the back button (but not always).
Some more insights which might help to solve the problem:
I'm not using OpenGL, so it's not related to this - I'm just using a single activity and fragments
It's also breaking for me when I just use the back button for going back from any Google Play Activity (I don't even need to go via the home key, just normal back is enough).
When the back button is broken the Activity is not receiving any Key Events (OnKeyDown, OnKeyUp, dispatchKeyEvent) are all not working, although using the activity and touching it fully works. My guess is that some view is catching the events...
Edit:
I also tried checking activity.getCurrentFocus() and activity.hasWindowFocus() as well as the parent and context classes of activity.getCurrentFocus() to see if there is any difference between when it's working and when it's not - and there isn't any difference...
Edit:
It seems that a simple call to View.requestFocus() is fixing the problem. For my single activity (using fragments implementation) I have now added:
#Override
public void onResume(){
super.onResume();
Fragment fragment = getFragmentManager().findFragmentById(R.id.fragmentContainer);
fragment.getView().requestFocus();
}
and this seems to be fixing the problem. Sill have to do long term checking if it's always fixed. In your OpenGL implementation I guess you will have to get the main view of the activity in some other way since you are not using fragments.
I know it's pretty old question, but for clarification: accepted answer is correct, but incomplete. Focus requesting should be done in onResume, onActivityResult, onSignInSucceeded and onSignInFailed. In first two you have! to call super. Some code:
private void requestFocusAfterGooglePlay(){
if(gimmeFocus==null)
return;
View currFocus=getCurrentFocus();
gimmeFocus.setFocusableInTouchMode(true);
gimmeFocus.setFocusable(true);
gimmeFocus.requestFocus();
gimmeFocus.setFocusableInTouchMode(false);
gimmeFocus.setFocusable(false);
if(currFocus!=null)
currFocus.requestFocus();
}
#Override
public void onSignInFailed() {
requestFocusAfterGooglePlay();
}
#Override
public void onSignInSucceeded() {
requestFocusAfterGooglePlay();
}
#Override
public void onActivityResult(int requestCode, int resultCode, Intent data) {
requestFocusAfterGooglePlay();
super.onActivityResult(requestCode, resultCode, data);
}
#Override
public void onResume(){
super.onResume();
requestFocusAfterGooglePlay();
}
in my case gimmeFocus is a dummy View created as below:
<View
android:id="#+id/gimme_focus"
android:layout_width="0px"
android:layout_height="0px"
android:focusable="false"
android:focusableInTouchMode="false"/>
I have dynamic layout so I can't never be sure that any view exists in my layout, so I've created this dummy View, it might be also added programmatically. You might choose your fixed View for gaining focus, but rembember that changing focus might change view's look (drawable state).
I am currently working on a GWT project where I am displaying an HTML file within an iframe in my application. This HTML file is actually being written to as it is getting displayed, and I am hoping to be able to reload the frame so that the changes made to the HTML file are reflected on screen. I am able to do this two different ways that both work when running in development mode, however neither seem to work when the project is deployed.
The first method I tried was setting the frame's URL to itself:
frame.setUrl(frame.getUrl());
The second method I tried using JSNI:
public native void refresh() /*-{
if($doc.getElementById('__reportFrame') != null) {
$doc.getElementById('__reportFrame').src =
$doc.getElementById('__reportFrame').src;
}
}-*/;
When deployed, the frame gets displayed in a Window, and when the file is finished being written to, a call to either of these refresh methods is made, and the frame refreshes to contain the finished HTML file. When I am deployed, the call to refresh does not reload the contents of the frame, however if I bring up the frame's context menu (in Firefox), then go into 'This Frame', and click Reload, it successfully reloads the frame to contain the finished HTML file. I have tested this on multiple versions of Firefox without any luck.
Does anyone have any suggestions? Why would the behavior be different from one mode to the other?
Thanks.
wow, google is really fast with his search^^
You can use some JSNI to do this. Create a method such as
protected native void reloadIFrame(Element iframeEl) /-{
iframeEl.contentWindow.location.reload(true); }-/;
Then call it with your iFrame element
so your question you posted twice was already answerd here
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/64aa7712890652d3
We had a requirement where one GWT application(parent) had another GWT application(child) loaded in an iframe. The child application had to refresh the iframe after it performs certain DB operations. We used JSNI to accomplish the same.
private native void refreshChild(String url)/*-{
$wnd.location.href=url;
}-*/
In case, if the child frame needs to be redirected to another webpage, the url can be modified accordingly.
We did try to use the reload() method, but it did not help.
The above piece of code, of course needs to be written in the child application.
I want to disable/enable user interaction (mouse click more specificly) on many widgets like hyperlink, button, etc which are contained in a composite (flextable)
there are more than one click handlers, and I don't want to bother with removing and adding listeners according to mode (interaction enabled/disabled)
Any ideas would be appriciated...
You forgot to mention the version of GWT. In GWT 2.0 you can use this code snippet or something similar. This feature allows you to cancel events before they are handed over to the target widget.
Event.addNativePreviewHandler(new Event.NativePreviewHandler() {
public void onPreviewNativeEvent(NativePreviewEvent pEvent) {
final Element target = pEvent.getNativeEvent().getEventTarget().cast();
// block all events targetted at the children of the composite.
if (DOM.isOrHasChild(getElement(), target)) {
pEvent.cancel();
}
}
});
There is a GlassPanel compoent in google-web-toolkit-incubator. I am almost sure it does what you need. Either way, it is a good idea to cover a disabled component whit one of these.