After a recent upgrade of Xcode (6.1) I am no longer able to see the properties of objects in the debug area. Does anyone know how to return this functionality to Xcode?
Xcode has never shown properties per se in the Variables view. If the property had a backing ivar, and there was debug information for the backing ivar, then that would be shown. But to present the correct property view it would have to call the property accessor for every property of all the disclosed objects, and that's too expensive.
It happened to me before. Turn out, it was just because a tiny mistake.
So, I think you need to check two things:
Whether the break points you are setting are able to discover your properties. It's all about the scope problem.
To check whether you filter it out accidentally.
Related
Background:
I'm experimenting with ui level testing in iOS 9.0 with XCode GM.
Question:
Is there a command in XCode GM that will allow you to see a 'tree' of accessible elements and their relationships? Something similar to the 'page' command in Appium?
Ideally I would be able to run a command in the debugger that would give me a list of elements available for selection/manipulation. Currently you can use debugDescription on a single XCUIElement but that only gives you info for that element.
Set a break point where you would like to see the tree... in the debugger type:
po print(XCUIApplication().debugDescription)
That prints out everything XCUITesting has access to. You can also just throw that in to your test:
func testTreeExample() {
XCUIApplication().buttons["login"].tap()
print(XCUIApplication().debugDescription)
XCUIApplication().buttons["next"].tap()
print(XCUIApplication().debugDescription)
}
Thta way if you are having trouble finding something you can have it automatically print out what the app sees right after you do something.
This isn't exactly what you're asking for, but Xcode’s Accessibility Inspector makes it much easier to look at your view hierarchy in terms of what elements are accessible via Identifiers. (N.B. It's not the "Label" in IB's Accessibility panel that matters, it's the "Identifier" field.):
In Xcode 7.2, open Xcode->Open Developer Tool->Accessibility Inspector. (You may need to give the app permission to run in System Preferences.) Then launch your iOS app from Xcode and hover over any UI element in the SIMULATOR. You’ll see comprehensive information about the element type, description, hierarchy, etc.
Anytime you record UI actions and the output doesn't look right, use the tool to figure out what accessibility descriptions need to be added, changed, or removed. (I spent a couple days trying to get a deeply embedded UISegmentedControl to change via the UI Test harness, and the problem became obvious once I figured out how to use the Accessibility Inspector tool.)
Thanks to the folks at shinobicontrols.com for the great tip!
I would suggest choosing from the menu bar: Debug > View Debugging > Capture View Hierarchy when running in debug. Not only do you a way of visually representing the views but also the left-side debug navigator shows the hierarchy. This may not be one-for-one with UI Testing's perspective but it can be very helpful. Hope that helps.
The way Appium does this is using Facebook WebdriverAgent.
As far as I can tell, the way they do it, essentially, is starting from the root application element and collecting information about each child, then recursing.
What about http://fbidb.io?
With idb ui describe-all command you get the accessibility information of all the elements on screen (not the entire app) https://fbidb.io/docs/commands#accessibility-info
Put a breakpoint in any of your tests then just do: po XCUIApplication() and that will print out the whole app's accessibility hierarchy in easy to read tree format.
I have a custom UITableView subclass in which I override +accessInstanceVariablesDirectly to return NO in order to ensure attributes with no setter cannot be set using KVC.
When removing this table view from the view hierarchy, the app crashes - sometimes - and now for the weird part: only if Accessibility is enabled! (i.e. the Accessibility Inspector is visible, or you have Accessibility enabled on a physical device)
If I do not override +accessInstanceVariablesDirectly, everything works fine. I figured maybe UITableView relies on accessing some instance variables directly - but then what is the point of this method, if I can break superclasses by using it? Is there a way to specify this behavior per-attribute, like +automaticallyNotifiesObserversForKey:? However I am baffled by the fact that this issue only exists when Accessibility is enabled.
I tried analyzing the project with various Instruments, but without success.
You can find a minimal project reproducing the issue here. I would greatly appreciate any pointers on why this is happening or how to achieve what I want nonetheless.
This issue appears to be fixed in iOS 9.
I was scratching my head wondering why my rvc was set to nil when watching it while debugging through Xcode and thinking there must be something wrong with my project. So I created a project from scratch using the Xcode single view app template and then the only change I made was to add the following lines to didFinishLaunchingWithOptions:
Now look at what Xcode is displaying for the value of rvc in the watch window:
What's going on, why is it reporting rvc is nil?
Its not actually nil, but Xcode's watch window is reporting it as such. Is this a known issue with Xcode?
I found out the problem - its the positioning of the breakpoint, position it a line higher and rvc is not nil.
If you look at the watch window you can see rvc is light text when the other variables are bold text.
So my conclusion is at that point Xcode is reporting that rvc has gone out of scope and been deallocated, yet as the return statement has not yet executed at that point then rvc should not yet have gone out of scope.
Is it some Objective-C optimization thing going on resulting in this in Xcode or is it a defect with Xcode?
Either way its wasted a few hours of my time thinking I had a problem when there wasn't. In the future I need to make sure never to position breakpoints on a return statement again that contains local variables.
I'm setting an attribute called target with Interface Builder.
This works fine on the simulator. However when I change the destination to my iPhone and run the app, the value does not get picked up. I get (null) when I try and access the target attribute. What could be the issue?
I'm trying to access the value in viewDidLoad method of my view controller.
It was a memory management issue. While defining the target property in the class, I had defined the storage as weak. Changing it to strong fixed this.
I've got a custom button class which subclasses UIControl, and I can successfully add instances of it into my XIBs using Xcode 4. I can also use "User Defined Runtime Attributes" in the Identity Inspector to give the buttons titles and font sizes, etc.
However, this seems to only be supported in iOS 5.0 and later, and I would like to support iOS 4.3. Is there some other way to either assign custom properties to these objects in the GUI? Obviously I can put them in my code, but that is undesirable for hopefully obvious reasons.
Failing that, is there some best practice for maintaining view properties like this?
Unfortunately, user defined properties in the nib file are not supported prior to iOS 5.0. A good way to check what kind of nib support you have is to change the nib's target deployment to your desired target deployment. In this instance, you'll get an error right away if you change the nib target deployment to 4.3 that these properties aren't supported in iOS 4.
Unfortunately, you'll have to do this in code or use something like a property file if you're targeting 4.x.