Category Archives: Cocoa

Xcode being the vast IDE that it is, it’s sometimes the simplest things that flummox you. It’s rare that I ever want to look at the XML code for any of my interface files, unless I’m copying one from one project to another or hunting down some forgotten outlet that’s throwing a warning. But when I do, I invariably forget how to get back to IB view.

If that’s you, fortunately it’s easy to return to the Interface Builder view from the source code view. Just right-click (aka ‘Control click’) on your nib file in the project navigator sidebar and choose “Open as…” and “Interface Builder XIB Document”. Unlike myself, you’ll remember that for next time, too (me, I’ll be looking for this post again in six months time! 🙂 ).

Like this:

Well, Tim Cook sayssitting is the new cancer…and since I don’t envisage myself in the market for an iWatch, but do need to be reminded to get up and take a break from the desk every 60 minutes, I wrote OSXClock.

I also need a clock for displaying the time on a large screen on occasion when conducting timed-based tests. In the past, I’ve used timeanddate.com for this, but it has a couple of disadvantages: first, you have to be connected to the internet; second, it doesn’t have an alarm or timer.

If you’ve ever looked at trying to compare and evaluate two strings in Objective-C, you’ll find a whole host of methods to help you out. What you won’t find, however, is a method that will actually return the substring (or substrings) that belongs to one but not the other of the two strings you’re comparing.

I spent some time trying to figure out how to do this last week for one of my apps, and finally decided the best way was to break the strings down into arrays and then compare the arrays by removing items that belonged to one not the other.

I chose a fairly simple equivalence test based on length, and then set out to determine which was the longer of the two, before removing all the objects of the shorter one from the longer one. Here’s how I did it:

This method is pretty basic as it stands. For one thing, the length equivalence test will certainly fail under some conditions of change; for another, you’d need to extend it to return items that are in the shorter string but not the longer (though that wouldn’t be that difficult). Nonetheless, the core of the method could be used as a basis for something far more robust. For example, this vastly more complex set of match patch and diff libraries appear to be essentially based on the same principle of breaking strings down into NSMutableArray’s and adding and removing objects, but with a vast army of conditions and other checks built in to improve reliability.

Still, the basic method I’ve posted above is the core idea I’m using in the new system profiler feature coming in the 1.5 release of FastTasks 2 (see the screenshot above), and at least at this stage of beta testing, seems to be doing the job it was designed for quite nicely.

Here’s a little problem and solution I ran into the other day while using UITableView. I wanted to have a master-detail set up in which the UITableView was segued to after an initial home screen.

The problem occurred whenever I added or deleted something in the UITableView, segued back to the home page and then returned to the table view. Sometimes the table would not update. Going out and back into the view a second time, however, would finally reload my data and show me the changes. Why was my app needing to load the view twice before the table would show any changes?

Logging showed me that something even weirder was going on: Every time I segued into the table view, the viewDidLoad method was being called not once, but twice. So basically, to get my updated data to show, I was actually calling viewDidLoad four times!

I worked through a whole bunch of stackexchange posts related to various problems and solutions with the reloadData method — adding delays, removing it from any edit- or insert- methods and so on, calling it on the main thread — but the problem stubbornly remained.

Then I noticed something else. In my awakeFromNib method, the call to super had somehow got pushed to the end of the method, after a bunch of other set up calls. I’m not sure how it got there, but I did remember seeing a WWDC 2014 Swift video pointing out that one difference between Objective-C and Swift was that calls to super need to be made after doing any initial set up in Swift’s case, but before for Objective-C. Since this was an Obj-C project, what was my call to super doing at the end of the method?

And as if by magic, moving [super awakeFromNib] to the beginning of my awakeFromNib method resulted in viewDidLoad only being called once, and my table view updating correctly.

Though I found quite a few threads with people having a similar problem with UITableView’s needing two calls before updating, I haven’t come across this particular solution to (or cause of) the problem. Hopefully, this post will save someone else a few hours of head scratching!