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.
Related
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.
In my app I want the user to type names into a UITextField (or equivalent) and then when they press return, it will put that word(s) in a blue bubble that's usually associated with tags. The cursor then moves to the end where they can add more "tags".
This can be seen when adding contacts in the To, CC & BCC fields in the Mail app, and also when selecting contacts in the Messages app.
How is this done? Is it something that's provided in the UIKit or available somewhere else?
Many thanks,
Michael
Venmo just open sourced their token field.
https://github.com/venmo/VENTokenField.git
edited:
The equivalent control in desktop Cocoa is an NSTokenField, but there doesn't seem to be an equivalent for Cocoa Touch.
Since iOS 13 there exists UISearchTextField.
https://developer.apple.com/documentation/uikit/uisearchtextfield
You can see that component in action in the Photos App.
That should fit for many use cases. By removing the leftView you can also get rid of the search icon.
But be aware: You can‘t mix text and tokens at various positions.
From the docs:
Tokens always occur contiguously before any text in the search field.
Adding this here for reference:
Feel free to check out TaggerKit (a library I made), it's more or less what OP was talking about. You can basically add tags functionality to your app by just adding a view and a couple of properties.
I dont think you can do it with any built in functionality in the SDK, never seen such a feature. What you could do however is implement it yourself, have some custom blue button with some text over it, and when the user hits return you can have some code that takes the text and returns you the button that you need, shouldnt be too bad to implement
I have learned that in iOS 5, properties that are marked with UI_APPEARANCE_SELECTOR can be styled using appearance. Eg [[UINavigationBar appearance] setTintColor:....]. However, I seem not to be able to style all elements. UIButton, for instance, has no properties marked UI_APPEARANCE_SELECTOR, hence I am not able to use the above technique to style it.
My question is: How do I best style elements globally (all appearances in the application), when I cannot use appearance?
Right now I have defined some colors, fonts, shadow offsets etc. that I use many different places in my code. This allows me to change the look and behaviour of a lot of elements, but it still doesn't allow me to style all instances of a certain object with only one line of code.
Edit
In lack of better solutions I have created a number of categories with simple methods as the following:
+ (UIButton *)customLabelWithFrame:(CGRect)frame andText:(NSString *)text;
Also I have found that - in combination with the described categories - stretchable images are nice and useful.
With the above I am able to style in a global-ish manner, however I am not satisfied with the result and I still hope to find a better solution
What about standard subclassing or factory classes, as you mentioned yourself!?
For buttons I'm using factory classes myself.
I think a really nice solution could be the Android way of designing interfaces. Android relies on XML files to define the user interface. As a matter of fact, I'm working on a library that aims to give the projects I'm working on much the same capabilities. It's still a work in progress / experiment and as such really messy code (you have been warned!), but it might give you some ideas.
An example project can be downloaded here: http://dl.dropbox.com/u/6487838/WSLayoutManager.zip
Experiment a bit with the XML files by adding controls. Create custom control classes and instantiate them from the XML file, etc... It's fun stuff :)
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.
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.