I am testing my app with the UI Automated Testing framework. I have a UIACollectionView I would like to pull down or drag my CollectionView. I already tried the ways from the documentation:
to drag up
target.dragInsideWithOptions({startOffset:{x:0.5, y:0.9}, endOffset:{x:0.5, y:0.2}, duration:2.0});
or to pull down:
target.dragInsideWithOptions({startOffset:{x:0.5, y:0.3}, endOffset:{x:0.5, y:0.8}, duration:2.0});
when this didnt work I tried to use the inheritated methods of the UIAScrollView. chatList is my UIACollectionView
archivedChatCell = chatList.cells()["Noise"]
archivedChatCell.scrollToElementWithValueForKey(1, "isVisible")
chatList.scrollDown()
chatList.scrollToElementWithPredicate("Noise")
But nothing is moving in the screen. I read in some threads that this (dragInsideWithOptions) is a Apple problem that needs to be fixed for the iOS7 UI Testing.
Does someone have any idea what the problem is? Am I missing something or is there a work around for that?
The weird thing is, I am using the same code in a different CollectionView in my App, the dragInsideWithOptions works fine and drags or pulls the screen.
thank you
Yes, dragInsideWithOptions and flickInsideWithOptions are not working on the simulator. However, they do work on a real device. Therefore, my suggestion is to use a real device until Apple fixes the problem.
Related
I'm learning to use the split view in an app. I am asking the table to reload the data every time I add new things. My code and settings are seem fine. But not work on iPhone. After I ask someone and he told me to try on an iPad device, it works.
Finally, I find out where the problem is, but I don't know how to fix it. I added a line that prints the size of splitView.viewControllers. The iPad simulator returns 2, which is what I am expecting. But it returns 1 without any changes in the iPhone device. So, what's wrong with it, and how may I solve it? Thank you very much.
enter image description here
enter image description here
Anybody having issues tapping on cells where a lot of cells exist? I keep getting the error "Failed to get refreshed snapshot".
I tried using the recorder but that also seems to freeze. I assume it's trying to cache all the cells in the view.
Example: I have cells for each day on a calendar with accessibilityIdentifiers. I have no problems tapping on the cells using the Identifiers with KIF.
Yes, i have. Its about 1 error of 100 tests. Maybe is an apple bug: https://forums.developer.apple.com/thread/6437. I don't know any workarounds :(
A work around would be to tap screen coordinates as mentioned by taylesworth on Apple Developer Forums
Example:
let coordinate = cell.coordinateWithNormalizedOffset(CGVector(0.5, 0.5))
coordinate.tap()
I'm writing an app in Swift 2.0. The app works fine in every aspect, beside one.
When I tilt the screen of both device and emulator the orientation change animation is missing. Instead of a smooth rotation I get a clunky orientation change. Portrait -> Landscape. Nothing in between.
Giving the fact that the animation should be the default, I would like to know if anybody knows the possible solution to this problem. I searched everywhere and apparently nobody has this problem, instead people try to disable that animation!
After some tests and thanks to Zell.B, I moved the code from didFinishLaunchWithOptions to applicationDidBecomeActive and everything works fine.
Deleting the applicationDidFinishLaunching method from the app delegate class can also cause the lack of animation problem. Adding it back in can fix it.
I have devoleped a simple iOS app and on test using Appium all the UIControls staus is shown as visibility false. The below image is the screenshot of the test. I set accessibility label on storyboard
The code I wrote for a simple textfield is given below.
self.txt_txt.isAccessibilityElement = YES;
self.txt_txt.accessibilityElementsHidden=NO;
I have done a little R&D on this and haven't found anything keep 'visibility ' true for UIControls.How to keep visibility true in the above case.If not in code are there any other scripts to run?. Any thoughts are welcome.
I believe this is a bug when using iOS8, based on the information shown in the Appium bug database here:
https://github.com/appium/appium/issues/4131
Looking at the last comment to this bug, it seems that in iOS7 elements are correctly identified as "visible: true", but the same ones in iOS8 are not.
As far as I understand it, at the moment it's not yet clear if this is a bug in Appium or in iOS8.
[I know this has been done to death, and I'd ask follow up questions on an existing question were it not for not having enough stackoverflow points to make one:(]
I'm after an App Store valid way of forcing an existing UI to re-orientate without having to destroy the main ViewController or View. We work in fullscreen mode, so I'm assuming I can't use any of the toolbar approaches normally quoted. Finally I'm only interested in iOS5.
For iOS6 I have a solution based on the answers in How to change the device orientation programmatically in iOS 6. I used the solution which includes ForcePortrait, with the variation that I changed it so I can supply the required orientation as a parameter.
For iOS5 I have experimented with the suggestion of:
[UIDevice currentDevice] performSelector:NSSelectorFromString(#"setOrientation:") withObject:(id)UIInterfaceOrientationPortrait];
from How to set device (UI) orientation programmatically?. This works well but I'm worried that it would be rejected by App Store (complete no no for us).
Has anyone used this on something that has App Store approval and/or got a better suggestion?
Check this out: Force Rotate UIViewController.
Maybe it will work. This is however very hackish.
[Found a solution, at any rate. Not sure if it the best.]
Got the temporary UIViewController approach to work by adding shouldAutorotateToInterfaceOrientation. The meaning of this is overloaded by iOS5 to discover not only should it autoRotate but also should it start in a particular orientation to start with - I guess that is why it is replaced by several methods at iOS6.. Thus we return true in orientations that are OK.
Perhaps should have realised that before.
Not quite as neat as the setOrientation hack. Key glitch we've noticed is that when you then rotate the device around to the proper orientation you still get a rotation animation. This does not occur on iOS6. Oh well, you win some, you lose some.