Tag: Programming

One common practice when subclassing a class is to use an application specific prefix so that if Apple adds a similar class in the future, it doesn’t conflict. For ReceiptWallet, I always used RW. One of the classes I subclassed was NSTextView so that I could draw text in gray when no text is entered. This is similar to NSTextFieldCell’s setPlaceHolderString method. I named my member variable placeHolderString and added a property. The code worked fine on Snow Leopard, but when it was run on Lion, we had reports that the placeholder text was drawn twice and blurry.

It appears that Apple added this property to NSTextView in Lion, but didn’t document it. I tried lots of different tactics to fix it, but decided the easiest thing to do was to rename my member variable/property. That worked perfectly and remains backwardly compatible.

So despite my best effort to keep my changes in my own namespace, there was no way for me to anticipate or detect this kind of change.

Lesson learned.

Mac OS X Lion has changed some of the internal workings of various APIs and as I don’t work much on Mac apps, I didn’t care too much. However, one app I work on got bit by this pretty hard. In various places in the NSDocument based app, I called:

[self saveDocument:self];

This, I had assumed, was a synchronous call and then proceeded to make calls after that based on the fact that the call succeeded. Up until OS X Lion, things seemed to work fine. However, with Lion, this call seemed to cause problems and after reading the header file for NSDocument, I instantly realized the issue:

/* The action of the File menu's Save item in a document-based application. The default implementation of this method merely invokes [self saveDocumentWithDelegate:nil didSaveSelector:NULL contextInfo:NULL].
*/
- (IBAction)saveDocument:(id)sender;

So I was tricked into thinking there was a synchronous call and got bit by it. So I’ve fixed the code to use a callback and things seem to be working better. While I should have been using the asynchronous call all along, I don’t recall if it existed in OS X 10.4 when I first wrote the program.

In my quest for information on writing test cases within the confines of unit testing framework, it became evident quite quickly that the tests are synchronous and asynchronous calls will never complete thereby rendering the test case useless. Since all networking code should be asynchronous (in my expert opinion), I had to find a way to handle this.

After a few quick searches, I found that my issue wasn’t uncommon. The most straightforward answer to this question is some code called AssertEventually by a developer named Luke Redpath. Straightforward in that the calling method is not complex; however, there is a big chunk of code behind it that has me a little concerned.

The more I’ve read about this, the more it looks like I have to spin my own run loop during the test such as described on a mailing list like this:

while (!_isDone)
{
	[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1.0]];
}

While this should work, it isn’t the most efficient way to do things, but at this point, I’m not sure there are other options.

Over the years, I’ve read a little about unit testing and heard it talked about at WWDC once or twice, but never thought much of it and didn’t see much of a need for it. Recently I’ve started to look at it again and have done a little research on the concept. I found a reference that seems to sum up the flaws of unit tests.

A test is not a unit test if:

It talks to the database
It communicates across the network
It touches the file system
It can’t run at the same time as any of your other unit tests
You have to do special things to your environment (such as editing config files) to run it.

Of all the projects I’ve worked on over the years, most, if not all, of them have had external dependencies such as network connections, handheld devices, or files on disk and therefore most of the unit tests I’d write adhering to the above rules, would barely exercise the app. If I wrote unit tests to simulate networks, I’d have to hard code in test data which lets us test one path in our app if we assume the data on the network never changes which is quite unlikely.

So, effectively unit tests are useless. I’m sure that someone will argue with me about this point, but if we assume I’m correct in the limited utility of unit tests, can tests be written that are useful?

Of course, we can write tests using the unit test framework (like OCUnit in Xcode 4). The test aren’t unit tests, they’re more like functional or integration tests that have external dependencies. This will let us test error conditions and see how different parts of the code will act in a real world environment.

It appears that Wil Shipley of Delicious Library fame seems to have similar views to me on this topic. However, I’m not opposed to functional or integration tests.

I don’t discount the utility of writing “tests” and will be writing some to test chunks of my code, but for the projects I’ve been on and expect to be on, unit tests have very limited utility and are possibly a poor use of limited resources.

Anyone that reads my blog or talks to me professionally knows how much I hate dislike asynchronous network programming. While working on rewriting some networking code, I came across a few more reasons why synchronous networking is a poor decision.

The first issue occurs when a developer abstracts the networking, then forgets that when the call is invoked, it actually makes a network call and does it on the main thread. Synchronous networking should never be done on the main thread. For instance, let us use the following made up example:

- (void) displayUserPreferences
{
	Preferences *prefs = [[Utility sharedInstance] getPreferences];
	if (prefs)
	{
		// Update the user interface
	}
}

- (Preferences *) getPreferences
{
	NSDictionary *dict = nil;
	NSData *result = [Networking queryPreferences];
	if (result)
	{
		dict = [self parseData:result];
	}

	return dict;
}

+ (NSData *) queryPreferences
{
	return [NSURLConnection sendSynchronousRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:@"http://www.something.com/data.json"] returningResponse:nil error:nil];
}

In order to not block the main thread, the developer has to always make sure that displayUserPreferences is called on a secondary thread. While this may sound simple, forgetting to do this is quite easy especially for a developer that didn’t initially write the code. Another developer might think that getPreferences is a local call and doesn’t hit the network and therefore call displayUserPreferences on the main thread. This is, of course, a recipe for disaster.

The second issue isn’t specific to networking, but has to do with threading. In the above example, the “Update the user interface” code under the comment must run on the main thread as user interface calls can/will crash when run on secondary threads. It is far too easy to forget to use performSelectorOnMainThread to run the code on the main thread. Having to keep track of what can and can’t run on a secondary thread just adds confusion and inevitably will lead to mistakes. A simple call like:

[self.tableView reloadData];

run on the secondary thread for networking will cause a crash.

I’ve seen both of these issues in code and there really is no excuse for being lazy in writing networking code. Once you write a good networking class, it can be reused over and over; I’ve used a networking class I wrote a few months ago in 4 or 5 different projects. I wrote it once; tested it extensively and now reusing it is quite simple.

I’m tempted to file a radar bug to ask Apple to deprecate the synchronous call, but I know that they won’t do it. The synchronous networking call screams lazy and should be avoided in my opinion.

When I read a post that John Gruber wrote today about OAuth in native Twitter apps and how much of a poor user experience it is/will be, I had to dig deeper into the article. On first read of the article, I disagreed with him as I thought he missed a very important point about security, but upon re-reading it, he did identify one of the major issues with how OAuth (and other types of service authentication) is done on iOS, in particular.

Developers can alleviate some of the context switching by using an embedded web view inside their native app for the OAuth authentication handshake, but at that point, why not just use xAuth and simply allow the user to enter their username and password in a native dialog box? So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth…

This is something that most users are unaware of when entering their credentials in any iOS app. As long as you are in the app, even if the page says Facebook, Twitter, Dropbox, etc. and you’re not running an app from these companies, the app can capture your username and password. Some companies ship their libraries to developers in a form that doesn’t let the developer modify the source code, but that offers zero protection from a malicious developer that wants to steal usernames and passwords.

I’ve seen one application launch Safari, ask you to login to Facebook and when done, returns you to the app. From a security point of view, this is the ONLY way to ensure that the application doesn’t capture your credentials (provided that you trust that Safari isn’t stealing your credentials). Any embedded web view offers no guarantee that the app isn’t hijacking your credentials as the app can walk the hierarchy of views and grab info; in a kiosk I worked on, we presented web pages, but I modified the web pages before displaying to change the credit card field to a password field to mask the numbers; this type of modification of web data is quite easy when a developer controls the entire app.

Should you be worried? That all depends. Do you use different passwords for every service? If not, consider using 1Passwd. Yes, it may be a pain to enter the random password on a mobile device, but if some app got access to the password you use on all your sites, the risk is great. Are most developers honest? Yes, but bugs in the code could put your password at risk. Also when I tried out apps for Google Voice, I had some strange feelings about an app, so I ran my iPhone’s networking through Charles Proxy to see where the app was connecting; it was connecting to a site that wasn’t Google. I had no idea if my Google Voice password (which is my Google password for email) was going to some lone developer’s server. Based on the developer’s posting in various forums, I didn’t trust his app with my password.

Should users be inconvenienced by having an app launch Safari, enter credentials and then go back to the app? Personally, as someone a bit paranoid about security, I think it is worth the one time inconvenience (per app). The average user may not think this way. However, if the user was better educated in the app indicating that for security purposes Safari will be launched, that may mitigate the issue.

I’ve now spent a few days working on a new project that has all the source control in git. Knowing that I was going to be assigned to this project at some point, I spent parts of the last few months learning git. Now I actually have to put the knowledge to use. While I have read/write permissions to the main repository, I am choosing to submit pull requests and let another developer accept my changes until I’m more comfortable with git.

I’m getting used to certain aspects of git, have done some branches, committed changes, and submitted pull requests. For the most part everything has been going fine. I am starting to like the concept of creating branches for various changes and being able to park them and work on something else, switch back to what I was working on and then merge everything back in. However, the merging is one part that is kind of confusing to me, still. Apparently there is an auto merge, but I’m not exactly sure how to fix things if that fails.

I committed a change to my local repository today and realized I committed it while working on the wrong branch. So, I was easily able to revert the entire commit and then set a new branch off the commit and then I can work off that. I found that to be pretty cool. I haven’t merged my new branch back in, but that will be the next test. Also, I like how git handles renaming of files; it is smart enough to handle the moves and the git log command with –follow will show the entire history of the file; I had to use that in order to figure out who to blame on some code that is never used, but was never removed.

After I made a bunch of moves, I committed everything and issued my pull request. The developer that handles the pull requests said that I left out 11 files. Strange, the files were on my local file system, my repository was just pulled from the upstream repository and git didn’t say that any files were untracked. I nuked the files locally, re-did the pull and got the files back after the other developer put them back. It seems that some things in git are a bit confusing; it may be quite powerful, but with that comes confusion, at least on my part, on how to use it.

In order to make my life easier, I’ve been using Tower as a GUI for git. I’ve also been working a little with the command line.

Either I’m a bit thickheaded about learning git or it is a tool that does so much that learning it takes an entire course. Hopefully after a few more weeks with it, I’ll be more comfortable. At the same time, I hope the other developers on my project don’t bite off my head when I commit strange branches left and right!

I’ve been assigned to a new project where one of my tasks is to start refactoring and cleaning up the code to make it more readable and maintainable. I’ve ranted in the past about poorly written code, but some of what I’ve seen is unfathomable. Writing iOS software isn’t that hard; writing good iOS software that someone else will maintain is much harder. Apparently the second half is where developers fall flat on their faces.

For instance, I saw code that checked to see if the device was an iPhone 4 in order to use 2x graphics. It’s understandable that this check was needed for this case, but the code specifically checked for a GSM iPhone 4. This means that the check fails on a Verizon iPhone 4. Instead of doing the proper check for the scale of the screen, it became a bug that no one discovered until I hit it today. I also saw instances where after loading an loading from the network, it was converted into a UIImage and then set in an NSDictionary. Problem was, no check was ever made to ensure that the UIImage was non-nil and then when it was added to the NSDictionary, it blew up. Lovely.

Unless your company is named __MyCompanyName__, you shouldn’t have this in the header of any file. Change it!

Another task that I took on was rearranging the project as files were strewn everywhere. No one else wanted to do this, so I took on this grunt task. It’s definitely not fun, but neither is hunting through hundreds of files placed all over the place. Resources (images, xib, plists) DO NOT belong in the source folder; they belong in Resources. This is especially important for localization to make sure that you have all the right files. In addition, with all your images in one place, you can identify which images don’t have 2x counterparts for the retina display.

I think that this goes back to what I’ve said before; anyone that hires an outside developer (or even uses their own staff) needs to find a trusted and experience developer to at least look at the code.

I’m sure that the more I dig into this, the more disgusted I’ll be, but so far, the work isn’t really difficult, just time consuming. With all the cool parts of writing code, developers do have to take on the icky parts.