Spoiled by broadband or is it a necessity?

For WWDC, I've been staying at the InterContinental Hotel in San Francisco as it is close to Moscone West where the conference is being held. While the conference has WiFi throughout, having access in my hotel room is needed so that I can keep up with work before and after each conference day. Unfortunately with the hotel filled with geeks, the Internet connection goes from bad to worse at times. I've managed to sort of carry on a video chat with my wife twice, but that was when no one was around. The hotel apparently charges $60 for the week (the front desk said it was complimentary when I checked in) which is more than the full monthly bill for my home cable modem connection. My experience isn't unique; my co-workers in the W hotel down the street have been experiencing the same problems. As compensation for the poor experience (after tweeting about it), one co-worker received a cheese plate. Personally I'd rather have a working connection than a cheese plate!

I can understand that WWDC occurs just once a year and the hotel has no interest in paying for excess bandwidth the entire year for the one week there are a bunch of geeks in the hotel. While the room has been fine, the quality of the Internet connection may be the deciding factor for people choosing a hotel.

I feel quite frustrated trying to do work with the slow access which is causing me basically to do nothing; it's a good thing that I'm at a slow point in my project.

Another WWDC

This week, I had the opportunity to attend Apple's Worldwide Developers Conference (WWDC). I've been to a number of other WWDCs with the last one being in 2008. Things have changed significantly in the past years as the popularity of iOS (iPhone and iPad OS) increases. Unfortunately, I don't think that the changes are for the better.

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.

Trust in business

This week I've seen a number of "leaks" showing Lion and iOS 5 as well as people Tweeting about some of the information contained in WWDC sessions. Everyone that attends WWDC has to agree to an NDA (non-disclosure agreement for those not in the loop) and Apple stated everywhere that with the exception of the keynote, the content of the sessions was confidential and subject to the NDA. So, all these leaks are violations of the NDA. Besides what I've read on the web, the most flagrant violation I saw was someone taking a picture of the slide that said something on the bottom to the effect that photography was not permitted!

As Jason Snell tweeted a few days ago:

And with that, I declare the NDA completely dead. RT @daringfireball iOS 5 Screenshots and Tidbits at Engadget: df4.us/hqy

There are, unfortunately, no consequences to these NDA violations as Apple wouldn't accomplish anything by suing the small developer. However, that is no reason to violate it as it won't help any developer get ahead (I doubt the sites that have published information have paid the developers).

The first point of the Scout Law is "A scout is trustworthy". I always try to live by this and this includes everything I have done in every aspect of my life including business and work. I wish that more people, especially those in my field, would take trust seriously.

More pitfalls to synchronous networking

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.