I am currently detecting elements by their accessibility labels when writing automation testing?
This causes a lot of problems.
Is this the correct way of detecting elements?
If not is there a better way to
detect elements without using the
accessibility label?
UI Automation uses the accessibility label (if it’s set) to derive a name property for each element. Aside from the obvious benefits, using such names can greatly simplify development and maintenance of your test scripts.
The name property is one of four properties of these elements that can be very useful in your test scripts.
name: derived from the accessibility
label
value: the current value of the
control, for example, the text in a
text field
elements: any child
elements contained within the current
element, for example, the cells in a
table view
parent: the element that
contains the current element
Instruments User Guide
Don't understand what you mean by "This causes a lot of problems.". Accessing elements by their accessibility properties in Automation Instrument is quite easy.
var button = UIATarget.localTarget().frontMostApp().mainWindow().buttons()["Cancel"];
Of course you can access elements also by their order on the screen. For example:
var button = UIATarget.localTarget().frontMostApp().mainWindow().buttons()[3];
will refer to 4th button (they are numbered from 0) label on your screen. But in case you will decide to rearrange elements on your screen in next version of the app this method can broke your tests, therefore accessing them by accessibility label is more safe.
In addition accessibility elements makes your app more accessible for people (with disabilities) who will rely on VoiceOver for using app interface- so using accessibility properties in making interface tests force you to build better accessibility for your app.
Related
Coming from the .NET world, I was used to naming my UI elements with the type prefix. Examples:
btnSend
lblName
etc...
The advantage is that in intellisense/autocomplete, the moment I start typing "btn..." I get to see the list of all my buttons.
However, I find that in Swift, the most common approach is to name UI elements with a type suffix instead:
sendButton
nameLabel
usersTableView
etc...
The problem is that I can't remember the names of all my buttons. When I start typing "butto...", I was hoping to see a list of all my buttons, but instead I'm seeing all the framework classes first, and I have to scroll down to see my stuff.
So, my question: is there a convention for naming UI elements? Does Apple recommend naming a button as sendButton instead of btnSend (or buttonSend)? Is there a setting in XCode that will allow me to see items I defined first in the autocomplete list?
You can use any style as long as you are consistent with it throughout your application but still, if you want to go through the design guidelines you can check swift-style-guide by raywenderlich and api-design-guidelines from Apple.
Is there any library / framework that could simplify Universal Windows Platform app development of the application that contains multiple Frames.
I mean, using MVVM Light or BezySoftware MVVM-Navigation the application is highly tied to the idea of navigating between different pages that are hosted by single frame.
The UI I try to develop consist of multiple content frames (main, left, right) which content varies. I need something that will let me navigate easily between different views (by placing these views into appropriate frame) and provide the same features I would have with BezySoftware MVVM-Navigation, so:
handling of the view model state persistence
the ability to activate / query deactivate view models
back button feature
Few different options:
Combination of a single navigation service injected into your view model AND user controls for areas that need to be repeated view to view (e.g. a tabs, status bars, etc). With this route, every time you create a new view you would paste in the common user controls that need to appear. You would also be able to expose bindable properties from said user controls.
Combination of ContentControl, DataTemplate, and DataTemplateSelector to load in either an entire view (Page) or fragments of XAML. As one person pointed out you cannot use DataType attribute, instead you use the DataTemplateSelector class to do the mapping for you. With this approach you can also use triggers to dynamically change the template (content) based on changes to properties on your view model and/or user interactions.
A mix between 1 and 2 above.
I might right the whole thing right here, but it too lengthy. I just recommend you see this article to get your answer.
MVVM patter in UWP
I would like to let the user set 5 different settings. Each setting has a finite amount of values to choose (in my case : smaller, small, normal, large, very large)
I tried to use the UIPickerviews for this, but it needs a lot of space and I would like to have all on one page. I realized, that apple doesn't support simple dropdowns in IOS!?!?
following sample just shows only one setting and it fills up 1/3 of the screen.
In Android I managed to do this with simple dropdowns.
Any hints on how I could do this, without programming my own dropdown box ?
iOS does not have dropdowns as you say. I have created a custom control for my company that implements a dropdown. Some of my fellow iOS developers have yelled at me and said the dropdowns don't follow Apple's HIG. (You can take a look at our free app FaceDancer to see our dropdown control if you're interested.)
Apple uses picker views instead. What you can do is to have some sort of clickable element for each item (buttons for each one, e.g. "pick size", or make each field itself clickable) that displays a picker on top of the screen to let the user pick that value.
Note that there are large numbers of (both free and paid) third party frameworks offering all kinds of additional controls. I bet somebody has implemented a drop-in dropdown menu for iOS. Take a look at CocoaControls and search the iOS section for "dropdown". You can also look on Github and SourceForge.net.
I solved my problem by using a UISegmentedControl.
In my case with only 5 values, for me its the best choise. But for more then 10 values we have to use obviously external controls as Duncan mentoined.
var arraySizes5 = [sverysmall, ssmall, snormal, slarge, sverylarge];
var segmentcontrol_TextSizeTextViewer = UISegmentedControl();
segmentcontrol_TextSizeTextViewer = UISegmentedControl(items: arraySizes5);
self.view.addSubview(segmentcontrol_TextSizeTextViewer);
GWT's Editor framework is really handy and it can not only be used for editing POJOs but also for read-only display.
However I am not entirely sure what the best practice is for doing inline edits.
Let's assume I have a PersonProxy and I have one Presenter-View pair for displaying and editing the PersonProxy. This Presenter-View should by default display the PersonProxy in read-only mode and if the user presses on a edit button it should allow the user to edit the PersonProxy object.
The solution I came up with was to create two Editors (PersonEditEditor and PersonDisplayEditor) that both added via UiBinder to the View. The PersonEditEditor contains
ValueBoxEditorDecorators and the PersonDisplayEditor contains normal Labels.
Initially I display the PersonDisplayEditor and hide PersonEditEditor.
In the View I create two RequestFactoryEditorDriver for each Editor and make it accessable from the Presenter via the View interface. I also define a setState() method in the View interface.
When the Presenter is displayed for the first time I call PersonDisplayDriver.display() and setState(DISPLAYING).
When the user clicks on the Edit button I call PersonEditDriver.edit() and setState(EDITING) from my Presenter.
setState(EDITING) will hide the PersonDisplayEditor and make the PersonEditEditor visible.
I am not sure if this is the best approach. If not what's the recommended approach for doing inline edits? What's the best way to do unit-testing on the Editors?
If you can afford developing 2 distinct views, then go with it, it gives you the most flexibility.
What we did in our app, where we couldn't afford the cost of developing and maintaining two views, was to bake the two states down into our editors, e.g. a custom component that can be either a label or a text box (in most cases, we simply set the text box to read-only and applied some styling to hide the box borders).
To detect which mode we're in, because we use RequestFactoryEditorDriver (like you do), we have our editors implement HasRequestContext: receiving a null value here means the driver's display() method was used, so we're in read-only mode. An alternative would be to use an EditorVisitor along with some HasReadOnly interface (which BTW is exactly what RequestFactoryEditorDriver does to pass the RequestContext down to HasRequestContext editors).
Yes,Presenter-View pair should be. But Here two ways to achieve this feature if you like to go with:
1) Integrate Edit/View code design in one ui.xml i.e.Edit code in EDitHorizonatlPanel and View code in ViewHorizontalPanel.The panel has different id. By using id, show/hide panel with display method. if getView().setState() ==Displaying then show ViewHorizontalPanel and if getView().setState()==Editing then show EditHorizontalPanel.
2) Instead of using labels, Use textboxes only. set Enable property is false when you need it in view mode otherwise true
You have created two Presenter/view but I think if Edit/View function has similar code so no need to rewrite similar code again and again for view purpose.
If a big project has so many Edit/View function and you will create such type of multiple View/Presenter than your project size become so huge unnecessary.
I think that whatever I have suggest that might be not good approach but a way should be find out which help to avoid code replication.
I've been working on a Cook Book App and I've been making each page individually which takes a really long time to do, I asked a question similar to this and it was brought to my attention that you can setup a way to automate the design process so all you need to do is input your data.
Can someone please explain in as much detail as possible how you setup your xcode files/code to automate such a process
So for example I would just enter the page text and it would automatically put my standard background picture in and add a scroll view and appropriate buttons etc.
Thanks
You could make one master view that contains all the controls that you need: standard background picture, scroll view, appropriate buttons, etc, and make any subsequent views that you create inherit from this view, so that they all contain those controls.
You could also use just one view and work with multiple instances of it, one instance per page. Just make sure to have a Text property on it, or a constructor that takes in your text string, so that you could set it to a different text on each page.
Xcode project templates and file templates are pretty easy to make, with a few caveats.
Check the answers to these questions:
Add new templates in Xcode
Change templates in XCode
Also take a gander at these handy tutorials:
Custom Xcode Templates
Xcode: How to customize the existing project templates
It sounds to me like your putting your data into your views (pages). That's a big design error. You need to employ the Model-View-Controller design pattern and separate your data from your views. That will make it easy to create one view (template) that you can reload with data to display each individual recipe.
The first thing to do is to separate your data from the view. You need to have the recipes stored in an array, dictionary, Core Data etc and then wrap that data in a dedicated object. The second thing to do is to create a dedicated view to display all the recipes. As the user moves from recipe to recipe the app will simply remove and add information to the same view as needed.
I would recommend Cocoa Recipes for Mac OS X: The Vermont Recipes, Second Edition because it addresses these issues and it uses a recipe type app as its example. It's for Cocoa but the basic principles apply to iPhone apps as well.