Posts Tagged ‘Objective C’

Step Back From the Mainboard

Great consumer technology is a pretty complicated thing to pull off. Building something great needs a rock solid technological foundation with a beautiful and intuitive user interface.

Working solo on a project puts you in control of both of these processes. The obvious hurdle to overcome is for one person to possess a decent level of skill in both disciplines. But I don’t think this is the biggest issue. As a primarily technical person, I find it all too tempting to go right for the engineering challenge and tack a UI on later. When it comes to design, technical considerations are constantly dictating my design choices and the product ends up crappy.

It’s a new kind of discipline and level of mental agility to look back and forth between the outward facing interface and the code under the hood, but that’s what’s required to step back from the parts and start designing an experience. And it’s a challenging leap to make.

[image via Seattle Times]

Solving the MBProgressHud _WebTryThreadLock Error

MBProgressHud is a really nice bit of plug in code to add fancy status and loading notifications to your iOS app quickly and easily. It looks great! Unfortunately, there’s an irritating error which cost me some time this morning, and hopefully I can save anyone else in the same position some trouble.

The error:

bool _WebTryThreadLock(bool), 0x7b9b5500: Tried to obtain the web lock from a thread other than the main thread or the web thread. This may be a result of calling to UIKit from a secondary thread. Crashing now...

This appears when a method which needs to update a UI component is called directly by the MBProgressHUD object.

The most basic usage of MBProgressHUD is thus:

HUD = [[MBProgressHUD alloc] initWithView:self.view];
[self.view addSubview:HUD];
HUD.delegate = self;
[HUD showWhileExecuting:@selector(fetchNewData) onTarget:self withObject:nil animated:YES];

In which ‘fetchNewData’ is the method which is executed while the progress HUD is on display.

Using this technique, fetchNewData will be called on a secondary thread, which causes the crash error we’ve already experienced. UIKit, which handles all the user interface business, should only be running on the main thread, so when the secondary thread makes a move on a particular UI element, its going to throw the ‘web lock from a thread…’ error. (It should be noticed that you can update some UI components using the standard MBProgressHUD setup detailed above, but in most cases you’ll get the error.)

In the case of this example, ‘fetchNewData’ updates part of the UI, so it needs to be called on the main thread. The quick and dirty workaround I used to force it to execute where I wanted it to was to create an intermediary method which can be called by MBProgressHUD as normal but in turn calls ‘fetchNewData’ specifically on the main thread.

You could, for example, call this method ‘performFetchOnMainThread’:

-(void) performFetchOnMainThread    {
[self performSelectorOnMainThread:@selector(fetchNewData) withObject:nil waitUntilDone:YES];

Instead of directly calling ‘fetchNewData’ from MBProgressHUD, use it to execute ‘performFetchOnMainThread’, which uses the ‘performSelectorOnMainThread’ method to force ‘fetchNewData’ to be executed on the main thread.

This isn’t the most efficient or beautiful way to accomplish this, but it works, so if you’re getting a ‘web lock from a thread…’ error and you need to make sure your code is executed on the main thread, you can use this technique to get the job done quickly.