It can show up to 5 icons and if there’s not enough space left, the last one is replaced with the “More …” item. When clicked, it shows the nice view with the list of all available options that didn’t fit into the tab bar. UITabBarController delegates the job to the UINavigationController. Now why I tell all this?

By default, the UINavigationController uses that standard blue top bar, but what if I want it to be Black as in the rest of my app?

First, let’s change the style of the “More …” page top bar. It’s all pretty straight forward as you can see. Just get the navigation controller and set the style of its bar:

Finally, let’s change the style of the bar on the “More …” / Edit page (that says “Configure” by the way). It appears that you can’t drill down into the object model like above, but have to catch the moment when the editor is about to come out and do the magic. For this to happen, you needthe tab bar delegate (UITabBarControllerDelegate protocol) and use the tabBarController:willBeginCustomizingViewControllers: callback to nail it:

and later:

In the above 3-liner, you can see that we do the trick to actually find the navigation bar. It works nicely on iPhone 3.0, but may change in the future, so be careful.

Don’t forget that you can always subclass UITabBarController and hide all this customization logic inside to stay on the clean design side. In my work, I do that and used the tabBarController here to clearly state what model we operate on.

That’s all, folks. Hope it helped someone to save a couple of hours.

During the last few weeks I tried several iPhone dictionaries and surprisingly all of them ( I mean ALL ) are coded in a strange way. The one of the most important parts — word entry — is implemented in a totally unimaginative straightforward way where it either looks up whatever you enter against their huge databases after every new letter or does that periodically. Both versions block the search box every now and then and don’t let you enter your searches quickly.

No finger pointing here certainly, but you guys know who you are. I tried to contact authors and share this bit of knowledge, but it’s either http://localhost/ as the support link or no link at all, so… the least I can do is to share it here. Hope it’ll be of some help.

Here’s the part of a XYZViewController:

Where SearchOperation is a subclass of NSOperation and its main method looks something like this:

The idea is that when the user types a letter, the searchBar:textDidChange: is called, but it doesn’t do the search right away. Instead it creates an instance of the SearchOperation which represents a lengthy dictionary lookup and queues it. Each SearchOperation sleeps 1/4 seconds before it starts doing any work. In fact, before the actual start it checks if it was canceled and does that periodically during the search.

So when it can be canceled? That’s why we have the cancelAllOperations call in the queuing code. If the user types, every next letter results in the cancellation of previous search operations and none of them will complete or even start. Moreover, the user interface will never be blocked and your users can type away freely and only if they stop, the GUI will follow and show the results.

You see? Simple.