This spring, all my projects moved to iOS 4 and Mac OS X 10.6 as the minimum requirements, so I took another pass at learning blocks. This time, however, I could actually use them and read all I could about them. The more I started looking at them, the more I became enamored with them. I started using blocks in my own APIs and just finished rewriting a significant chunk of code using blocks. Using blocks has made my code more readable and has greatly simplified certain aspects of our app.

One of my co-workers cautioned me to not use blocks just because they were the shiny new tool which I admit was what I was looking at doing. However, after using them, we found that using blocks was pretty much vital to making our code more readable.

For developers that aren’t familiar with blocks, I’d suggest learning them. With most iOS apps having a minimum OS of 4.0, there is no reason to avoid them.

When I installed iOS 5 on my iPad 2, I found that iMovie imported more videos than before, but still not ones from my WX9. I made a few minor updates to MovieConverter to get it working better on iOS 5 and pushed it out the door. I got back from vacation the day after iOS 5 got released to the public and quickly updated everything including iMovie. The iMovie 1.2.2 notes said it added support for importing video from additional cameras.

Much to my delight and dismay, the videos from my WX9 imported into iMovie without MovieConverter. I immediately updated the MovieConverter description to say it may longer be needed and dropped the price to free so that no users would be pissed at me for writing a “useless” program.

From an iMovie user point of view, this is great news. I didn’t write MovieConverter for fame or fortune, but it was nice to get a little money from it.

Oh well, now I have to come up with another idea that will have a little more than 2 months on the app store.

The premise is pretty simple, but I think it is a huge help to those that don’t want to travel with a laptop and want to edit video.

While I don’t expect to become a millionaire on this, I do hope to sell enough copies to go out to dinner a few times!

Thanks Apple for the fast turnaround on approving this! Total time less than 9 calendar days from initial submission.

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.

[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.

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.

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.

I’ve been writing handheld software for almost 17 years and been writing Objective-C software for around 10 years which now makes me one of the old timers in this game. In order for Apple to cater to everyone (all 5200 attendees), they have had to dumb down many of the sessions. In addition as indicated in the keynote, WWDC was going to cover Lion, iOS 5 and iCloud. With iOS 5 being released in the fall, it will be a long time before I actually get to use features in iOS 5, so I’ve sat through many sessions containing information about stuff I can’t use for awhile. Typically the apps I write can’t drop support for an operating system for about a year. (There are some cases where we can use newer features, but for the most part, we have to use the same features across all OS versions.) As my products are now requiring iOS 4, I can learn some of the information from last year’s conference.

WWDC has grown each year which caused it to sell out within hours this year. I was on top of things, so I was able to get a ticket. With all of these people clamoring to absorb all the informations they can, attendees end up waiting in lines for each and every session. This gets old quite quickly. Last year Apple put out the WWDC videos pretty soon after the conference and I hope they do that again this year; watching the videos may be as valuable, or even more valuable, then being at the conference.

The real value, for me, was hanging out with my co-workers and meeting other members of my group that I’ve only met by email. This, of course, is invaluable and there is really no substitute for it.

Will I be coming back next year? I’m not sure.

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.

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.