I am new to UI Testing in Xcode 7, and I find it very difficult to determinate how can I test multiple details about my app. I have been able to test the basic things, such as different labels exist, and their values are changed when I tap the corresponding buttons.
However, I have no idea how can I test that the color of these labels changes to the one desired, or that a new screen is presented modally when I tap a button. After searching in Google and Stackoverflow I have found nothing but the basic tutorials that let me test what I have already accomplished. How should I proceed to expand my tests and make them actually useful?
There are some limitations. I don't believe testing color (or fonts for example) is possible... yet. However you can definitely test the navigation from screen to screen...
XCTAssertTrue(app.navigationBars["ViewControllerTitle"].exists)
Of course, it all depends on how your screen works. In the example, we're assuming there is a disabled navigation bar label. You just have to find something visual (text) on the screen that uniquely identifies it. It does take some getting used to.
As stated, the specifics for testing for color are not yet possible. However, you might want to consider Unit Tests for that. You can test GUI components for color in those. That's where the line between Unit and UI Testing can get a bit blurry. But, if you need to test for color, that is one way to do it.
Related
I am fairly new to developing for iOS. I have a fully functioning program written in Swift and the UI was created in the scene builder on Xcode. I created an app for my work to simplify closing out the registers and other financial aspects. The app is complete and works perfectly, but was designed on the iPhoneX. The problem is that only a few of the employees have an iPhoneX, but they all have some kind of iPhone. I have tried setting up constraints but it never works. Ive tried scaling restraints and position restraints but I can't get the layout to look right on any other phone, and when I add the constraints it affects the view on the iPhoneX as well and doesn't look good on any iPhone. I need help getting this to work on all iPhones. I would like it to look and act the exact same regardless of the size of the phone, basically just scaled down. There are a lot of things on the screen and I can't figure out how to do this. Please help!!!
I have been working on this for a long time and I really need help. Please let me know if I need to clarify anything. I have posted links to some pictures of my UI so you have an idea of whats going on.
Constraints I tried adding, although I have played around with some other options.
Here's what it looks like on the iPhoneX, this is how I want it to look.
What it looks like on iPhoneSE (with constraints).
One thing I noticed in your Xcode project that none of your features are in UIView. Without it, it will be quite challenging and somewhat always different results. In theory, if you use AutoLayout features correctly it should work without UIView, but they make life so much easier. This is something I learned the hard way at the beginning of my iOS development. First set up your UIViews without any content inside it, give them some background colour to differentiate, once they are working on all devices. You can pin your features to superviews with no difficulty.
Since you have a repetitive features, you could also consider using Stack Views. You don't have complicated features, so as long as AutoLayout is set up correctly you should have no problems seeing it ok on all devices
I have lots of views - sub classes (UILabel, UIVIew, UIButton etc) using core graphics (within drawrect).
These show fine within normal interface builder.
However they do not show in the preview assistant editor for the storyboard (where you can see how views should look on actual devices).
I've been doing some research and found posts suggesting prepareForInterfaceBuilder should be used. However this doesn't show in preview for me.
I asked this question some years ago, IB_DESIGNABLE, having views show in preview? however I can't reproduce this, I'm not convinced it did work back then either.
I'm still following the same approach, with a framework and that link shows my implementation.
I know that prepareForInterfaceBuilder should be used to do something different, to show something basic. Therefore I believe that core graphics won't work.
However, I can't even get a simple change in background color to work in the preview, although it does work in normal interface builder.
I would like to know if this is a bug (that core graphics can not be used in preview) or still a limitation in xcode?
At the very least I'd like to do something simple (like a change in background color). I have a lot of views and an impossible task to make auto layout changes.
Previously I was producing lots of screen shots, different devices, languages etc (via automation) just so I could see my auto layout changes, which is really slow way to work.
I can verify this is a long standing bug. Apple doesn't care. Custom view be damned. All those dollars spent for more broken Xcode functionality.
Android?
Daniel
This question already has answers here:
Adding Views. Storyboard VS. Programmatically [closed]
(2 answers)
Closed 6 years ago.
Is it more efficient to add views and subviews programmatically than using a storyboard to add them ?
What is be the best practice ? Does the best practice depend on the situation ? If so, when is it preferable to use the one method over the other ?
Storyboard vs Code comes up an awful lot. And I think looking at it as which is better often starts flame wars. So instead I'll list out pros and cons for each, then you can hopefully make an informed decision.
This is by no means an exhaustive list. I'd love to see edits or comments adding additional bullet points.
Storyboard Pros
Storyboards are great for getting a concept working quickly.
They're great for seeing your actual app and previewing it on multiple devices.
They make it really easy to customize appearances and explore whats possible.
They're fantastic for beginners as they remove one barrier and let you focus on code for your app rather than some boiler plate UI.
Storyboard Cons
Storyboards and Xibs are not great for merging. Its possible to read the XML and make decisions about merge conflicts, but its certainly not enjoyable.
Overtime as you customize your app and build the custom parts that make it special, Storyboards can't keep up. This means that the benefit of seeing and previewing your app as you see it on device slowly loses its value as more and more of your app is done in code out of necessity.
Storyboards don't have a huge performance hit for actual users, but they definitely slow Xcode down on even the fastest machines.
You can't customize everything in Interface Builder that you can in code, so its inevitable you'll have some code and some Storyboard customization. Later when you want to change something, you'll have to check at least two places for the right place to change it.
If you're using the same fonts and colors throughout the app, its easy to change in code in one place. In Storyboard you'll need to change it for every single label or view you've set up. You can easily set fonts and colors in code while using Storyboard for the rest of your layout, but over time you'll find your storyboards represent less and less of your actual app.
While its possible to have pixel perfect designs in Storyboard, drag and drop isn't as precise as entering specific numbers. Storyboard does support entering those numbers, but you need to navigate to multiple places and if you drag it later the numbers are all reset.
Reusing views typically involves copy and pasting them. These causes issues later when you need to make changes.
Showing and hiding views at certain times is doable, but again leaves your storyboard in an unrealistic state compared to your actual app.
Programmatic Pros
All your code is in one place making it easier to debug or change later.
Subclasses and custom properties are no different from first class views and properties. Your customizations will be easy to manage.
Views that are reused throughout the app only need to be created once.
Merge conflicts are often easy to understand and make decisions.
Dependency Injection is one of the safest ways to instantiate UIViewControllers and ensure necessary information is passed in, its not possible with Storyboards leading to less straight forward and more bug prone code.
Programmatic Cons
The additional complexity can be a stumbling block for beginners.
Writing a few lines of code can take longer than clicking a few checkboxes.
When working with layouts, you'll need to visualize it in your head or run your app to see what your layout looks like as you make changes. This can be difficult or slower for some.
Storyboard exposes checkboxes and buttons for many customizable properties like background color, font, etc. This makes it easy to see at a glance what you can customize. (Though as mentioned above its not everything) In Code, you'll need to look at documentation or headers to understand what you can customize.
Goodmorning all,
In some cases I need to present a lot of alert dialog (overlapped on each other). At the moment i can't find another way to do this because i need to take trace of each user's answer for each question in my dialogs.
So, after 5-6 dialog overlapped i've something like this:
my interface is faded out till to black, there is a way to avoide it?
Thanks all in advance.
That happens because the alert has a slight transparent black background which appears on top of the view. The things is since you add a lot of them, at this point this translucent backgrounds they get combined and you get the non-transparent black one.
One alternative would be to not present the alerts all at once but in sequence. So when the first one is dismissed, you present the next one and so on.
Another alternative would be to write your own custom alerts. Then you could control the background as would be fit your application.
However, it does not seem you are using the alerts for what they are supposed to be used, which is errors or messages the user must know. Maybe there is another solution for you application, maybe using a form or something similar. They are quite an intrusive way to interact with an application, so they should be used accordingly.
Hope this helps and you get to figure out the best solution for your project. Good luck!
For an iOS app i am currently working on, I need to manage the controls displayed on the screen based on the type of device the app is running on.
I will try to explain with a theoretical example (the actual numbers used below are not important, what interests me is best method to achieve the desired result).
Example:
In the case of the app in the screenshots, the button that overlaps the UIImageView should not be displayed at all OR displayed in another place on the screen.
So far I've worked with autolayout , but , from what i could figure, there's no way to say to xcode something like: hey, for a class size "Compact Width / Compact Height" , I want you to hide these buttons...but show them for "Regular Width / Compact Height" .
I also did some googling and saw some people talk about using different storyboards based on the device; I am also thinking, I could add/remove buttons dynamically based on the device type , but I think it's not so pleasant to have to add all of the constraints by hand (programatically that is).
So to resume, I would appreciate a suggestion of a 'best' way to do this , best meaning a combination of 'not so hard' + ' not so long'. Also, some code example (or links) would be highly appreciated.
Thank you all in advance !
I think it all depends how sophisticated it gets what you are doing overall. When you look at developer's code for large app projects very little is actually done in interface builder since the apps are so dynamic it's just too much work in IB.
Using multiple storyboards 'sounds' like a good idea, but often isn't. If you want to update/change one, in most cases you then have to change the other ones as well.
What I think is handy:
Use one storyboard (or multiple but for different parts of you app and not parallel ones) and then put in very 'special' cases multiple ViewControllers of the same class for the different size into the single storyboard. That way you won't forget about updating the second (and third) because they are all right there.
I would only use multiple 'parallel' storyboards for apps that support iPhone and iPad and it makes sense to really split them up..
Also:
I would as fas as possible still use just one representation and derive the other 'versions' from that in code. If you build a structured user interface you can then reuse (or just inherit) the code that 'hides' parts of the first viewController in the next. That way your code AND your IB files won't get cluttered.
Also think about internationalisation (if that is part of your future plans), since multiple IB documents and multiple instances of the same viewController layout really don't help for that ;)