“What’s In A Name?”, quoth Analyze… [#iosdev #objective-c]

An interesting thing happened while doing routine runs of Analyze in Xcode 4.2. I was able to track down and solve all of the memory issues that Analyze was reporting except for one, and for the life of my I couldn’t figure out what was wrong with this code:

        if (![self.newBlahBlahBlah isEqualToString:anotherString])


Then, i happened upon this thread on StackOverflow:

Objective-C – NSString copy property memory management – Stack Overflow

“Figured out what was wrong. I used the property name newFoo which made the compiler think I returned a new object. So note to self: understand cocoa naming conventions.”

…and then it clicked: the property “newBlahBlahBlah” was basically a violation of convention, and was tripping up Analyze, which assumed that the property returned an object with a +1 retain count. It didn’t, in reality.

So what was the solution?

Simply give the property a new name that doesn’t cause problems!

        if (![self.awesomeNewblahBlahBlah isEqualToString:anotherString])

Thankfully this issue, which had baffled me for weeks, was finally put to rest… and with a good lesson learned!

Easy Filename from a Path in Objective-C [#iosdev]

Every once in a while, there’s a feature in Objective-C that I really appreciate — the kind of method that makes you think, “Yes! Of course that should be in there!”, but yet at the same time it is surprising, because because in the past I would pretty much always have to roll my own algorithm for dealing with the particular problem.

The instance of this that I had in mind is with regard to the lastPathComponent method of NSString.

It is so convenient to be able to just get the name of a file from a path just by doing the following:

NSString* fileName = [myPath lastPathComponent];

In the past, on other platforms and languages, I typically had to write a routine that would loop through and find the last path delimiter and grab the final part of the string based on that location.


One method. Awesome.

Which Automated iOS Testing Tool to Use by Stewart Gleadow (@stewgleadow, #iosdev, #tdd)

Just started experimenting with KIF and found this article by Stuart Gleadow, which provides a rundown on UI automation testing tools for iOS:

Which Automated iOS Testing Tool To Use – Stewart Gleadow’s Blog

It seems obvious that Apple really needs to build a tool (something better than UI Automation) that is easy to create & manage tests, which can also be deployed and run in a Continuous Integration environment. In the meantime, KIF looks like an interesting alternative…