Advertisements

Category Archives: Cocoa

how to sit down safely

osxclock 1

Well, Tim Cook says sitting 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.

Hence, OSXClock was born, Applehelpwriter’s answer to the Apple Watch :p, and considerably cheaper! 😀


Advertisements

return the difference between two strings

FastTasks 2 Profiler
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:

 


-(NSString *)getDifference: (NSString *)aString and:(NSString *)anotherString {

int i = aString.length;
int j = anotherString.length;
NSString *result, *longest, *shortest;

if (i == j) {
result = @"";
return result;
}

if (i > j) {
longest = aString;
shortest = anotherString;
} else {
longest = anotherString;
shortest = aString;
}

NSArray *fa = [longest componentsSeparatedByString: @" " ];
NSArray *sa = [shortest componentsSeparatedByString: @" "];
NSMutableArray *remainder = [NSMutableArray arrayWithArray:fa];
[remainder removeObjectsInArray:sa];
result = [remainder componentsJoinedByString:@" "];
return result;

}

Here’s an example of how to call the method:


NSString *t1 = @"Mary had a little lamb";
NSString *t2 = @"Mary had a little lamb yesterday";

NSString *changes = [self getDifference:t1 and t2];
NSLog(@"%@", changes); //"yesterday"

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.

UITableView doesn’t immediately reload data

awakeFromNib
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!

%d bloggers like this: