Using xcode Ui Automation tool for iOS app, I'm trying create a UI test case. But I got into a situation where a toggle button doesn't have any label value. Due to which UI automation tool is failing to find the element and giving an error.
Is there any other way to select the toggle button. Was thinking of tapping based on co-ordinates, but the co-ordinates vary for different devices.
I've searched thoroughly for an answer but couldn't find one.
Can some one please shed light on this please.
Thanks in Advance !!
According to the best practices, you should add accessibilityIdentifier to the button and use this identifier to select a button. Labels can be changing or can be localized. accessibilityIdentifier are only "visible" for the UI tests.
You can set accessibilityIdentifier in the Interface Builder or in the code. In the UI tests, you can access element exactly the same as using value.
Related
The goal is a simple and clean implementation to build a pop-up window similar to the search-filters from the YouTube-App, see picture. Tapping on the half-transparent border should close the pop-up. The same pop-up is supposed to be called from several screens (within nested navigation-structures) and just give back the choices to the respective screen.
I did quite some search and documentation reading, so I seem to have the following four options:
Use an Alert window and heavily modifying the alert message, but this option does not allow me to cancel by clicking on the transparent area.
Using some promising-looking component which is very beta like react-native-popupwindow is not really an option either.
Use a modal component which claims to be a simple way to present content above an enclosing view. According to How to dim a background in react native modal? and Tap outside of modal to close modal (react-native-modal)" this seems to be a possible option.
However, some people say that you should rather use Overlay and use Modal only as a last resort.
Please advice which of the solutions you tested in real life. What do you suggest? Maybe there is even an easier solution?
Related question(s) here on StackOverflow:
Transparent overlay in React Native
Modal is totally your way to go.
My personal choice would be https://github.com/react-native-community/react-native-modal which has the best performances and flexibility overall.
Apologies in advance if this is answered but I genuinely couldn't find it. I'm trying to bring up the keyboard type on iPad which appears when pressing the "#+=" button. I've tried going through all the types on the docs and I'm sure that this wasn't successful. Am I missing something or does the user have to click this button every time?
Edit: this question was closed as "off-topic" because it didn't include code or ideas or what I've tried already... Therefore for a bit of extra detail, I used EVERY keyboard type that is available on the docs e.g.
theTextField.keyboardType = UIKeyboardTypeNumberPad;
This did not yield the results that I require, which is the keyboard plane that appears when you press the #+= button because I wanted users to go straight to that one.
Unfortunately, this is impossible. It's not a keyboard type you want, it's a keyboard plane. There is no public API to switch or in any way access the keyboard planes.
One solution could be to create your own keyboard with the symbols you want. Another solution would be to open the keyboard and then generate a touch event that will switch the keyboard plane. However, this would be complicated, non-portable and a bit dangerous.
You have no ability to affect the built-in keyboards.
You can however create your own custom input view which you would set on the inputView of your text editing view before you make it first responder. Then iOS will show this view instead.
Have a look at this project of mine which implemented a "Morse keyboard" (April Fool's joke), but demonstrates how to achieve a custom keyboard that still interacts with a text field as you'd expect. http://www.cocoanetics.com/2012/04/dtmorsekeyboard-tutorial/
Just wanted to know if anyone knew how to put the focus on a popover for a Safari extension. Currently, the popover acts as if the window is inactive. This prevents any mouseover events from working and trying to type in any input field is difficult because there is no flashing cursor.
According to a post on the Safari developer forums, this is a known issue with Lion and they are looking into it.
So I created a menubar app (agent application) and I need to find some way to get textual input via the menubar icon. I heard that making a popup modal with a textfield is frowned upon, and putting a text field in an NSMenuItem is bad for functionality. It doesn't even work, when I try.
You could use the new NSPopOver API in Lion. It will create a non-modal window anchored to a particular location, which seems to be exactly what you're looking for.
I'm developing a iPad app which has a popover which appears to show you a list of items. I need the ability to delete one of the items, so I'm considering adding the ability to press-and-hold (a.k.a. long tap) on one of the list items which would show another popover for that item, with an action list showing a delete button.
Two questions:
In terms of iPad UX, is this a good idea? Haven't seen it anywhere, and I guess it could be a little confusing...but how else can I do this?
Is this possible, code wise? I haven't tried it, but I am still pretty new to iOS development so I could see myself fumbling round for hours before finding out there's a technical reason why it's not possible.
Thanks!
It's not a good idea, and I don't think it's possible even though it's possible.
Apple's Human Interface Guidelines clearly state that you should not do it. This is as definitive an answer as there can be regarding UX.
For inspiration on how to delete items without requiring a popover, look at how UITableView does it, for instance.
Often, you'll have an Edit button in the top toolbar inside the popover to trigger edit mode.
If you want some kind of confirmation dialog, use UIActionSheet. They look good and work well enough, especially in popovers. In your case, I think these are the way to go.