People are complaining and getting confused because UIButton seems to have the interfaces needed to do so cleanly, namely -setLineBreakMode: with UILineBreakModeWordWrap which would affect the title label, and then adjusting -titleRectForContentRect: to manage room to accomodate multi-lines, but happens that both don't do nothing about it, so I'll show how to do it dirtily. Or sort of.

After some time, the best solution I came up with was to add a UILabel as subview to replace the title. I took the long run in order to make this patch work as seamless as possible with existing UIButton API and Interface Builder. I wanted this code to handle both the title and appearance settings that are defined both ways.

Below is the code that should be added into an UIButton subclass. Note that if you don't need/want to subclass you can pull of this exact same code into your button's superview drawing routines, replacing all references to self with the button variable name. Off to what matters.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

#define TITLE_LABEL_TAG 1234
 
- (CGRect)titleRectForContentRect:(CGRect)rect
{   
    // define the desired title inset margins based on the whole rect and its padding
    UIEdgeInsets padding = [self titleEdgeInsets];
    CGRect titleRect = CGRectMake(rect.origin.x    + padding.left, 
                                  rect.origin.x    + padding.top, 
                                  rect.size.width  - (padding.right + padding.left), 
                                  rect.size.height - (padding.bottom + padding].top));
 
    // save the current title view appearance
    NSString *title = [self currentTitle];
    UIColor  *titleColor = [self currentTitleColor];
    UIColor  *titleShadowColor = [self currentTitleShadowColor];
 
    // we only want to add our custom label once; only 1st pass shall return nil
    UILabel  *titleLabel = (UILabel*)[self viewWithTag:TITLE_LABEL_TAG];
 
 
    if (!titleLabel) 
    {
        // no custom label found (1st pass), we will be creating & adding it as subview
        titleLabel = [[UILabel alloc] initWithFrame:titleRect];
        [titleLabel setTag:TITLE_LABEL_TAG];
 
        // make it multi-line
        [titleLabel setNumberOfLines:0];
        [titleLabel setLineBreakMode:UILineBreakModeWordWrap];
 
        // title appearance setup; be at will to modify
        [titleLabel setBackgroundColor:[UIColor clearColor]];
        [titleLabel setFont:[self font]];
        [titleLabel setShadowOffset:CGSizeMake(0, 1)];
        [titleLabel setTextAlignment:UITextAlignmentCenter];
 
        [self addSubview:titleLabel];
        [titleLabel release];
    }
 
    // finally, put our label in original title view's state
    [titleLabel setText:title];
    [titleLabel setTextColor:titleColor];
    [titleLabel setShadowColor:titleShadowColor];
 
    // and return empty rect so that the original title view is hidden
    return CGRectZero;
}

Shortly, what I did there was to save all settings that define the appearance of the original label for a given current state, apply that settings to the custom label, and return an empty frame so that the original title isn't drawn.

As to the decision of putting this code in -titleRectForContentRect:, it is the method which gives me the best way to handle the change of state when the button is pressed. Surprisingly, -drawRect: is only called once.

That's a truck load of code for such basic good, but hey, that's why I set it up here neatly. And you can use the same UIButton API to set the title, title color and title shadow color without being worried about the extra UILabel.

Here's the final result.

You can download the code below.

Sidenote

An alternate way, is to hack the title's view UILabel. By inspecting UIButton.h, one sees the private UILabel *_titleView, but even subclassing UIButton, there's no way to access directly to _titleView.

Though, rembember: UIButton is a UIView subclass—it has subviews and it's possible to iterate over them. Looking carefully into UIButton.h, we can assume there's only one UILabel. I subclassed UIButton and in -drawRect: I hacked the following:

1
2
3
4
5
6
7
8
9
10

- (void)drawRect:(CGRect)rect
{
    // looking for _titleView UILabel (see UIButton.h)
    for (UIView *s in [self subviews])
        if ([s isKindOfClass:[UILabel class]])
            [(UILabel *)s setNumberOfLines:0];
    [self setLineBreakMode:UILineBreakModeWordWrap];    
    [self setTextAlignment:UITextAlignmentCenter];
    // ...
}

Note to self: Sadly, this code doesn't work in -awakeFromNib nor -initWithFrame: — Oddly, the latter is never called when the button is created from a NIB. Also, beware this code is messing with UIKit private stuff. Use with advisory. For what it's worth, my experience tells me it doesn't hurt Apple much.

The original title view label is now capable of handling multiple lines and nicely word wraps its content. Only thing left is changing the frame for title. See the code above on -titleRectForContentRect: for how to generate the frame and return it instead of the CGRectZero.

The only problem with this approach—besides messing around private views—is that the title will never be center aligned. Even changing the code that makes the title's label multi-line and center aligned from drawRect: to -titleRectForContentRect: doesn't fix the text alignment problem.

Bottom line: If you can get away with a left aligned multi-line title then you can consider this approach. Otherwise, don't.

You have two possible approaches.

Approach 1: Adding the custom view on top of UIKeyboard view

You can create the custom view you want, position it above the UIKeyboard and animate it the same way UIKeyboard is. This means your code will be constantly listening to the UIKeyboardWillShow and UIKeyboadWillHide notifications in order to show and hide the custom view along with the keyboard. Also you have the hassle of having to write all the animation code for the custom view to mimic the keyboard going up and down.

This approach will work in most situations but my experience tells me that in certain situations when alternating between text fields of a form, the UIKeyboardWillHide and UIKeyboardWillShow notifications are sent so quickly that the UIkeyboard doesn’t go down. Though, our custom view goes down and comes up very quickly. If you, reading this, have any idea how to prevent this behavior, leave it in the comments.

Approach 2: Adding the custom view to the UIKeyboard view itself

Apple keeps its keyboard implementation private for some reason. So, you know, you shouldn’t be modifying UIKeyboard’s inner subviews. Anyway, you shouldn’t doesn’t mean you can’t.

You start with the same custom view you had in the first approach, but you will be adding it to the UIKeyboard subviews instead. This will save you from all the hassle of animating the custom view so that it has a similar behavior to the UIKeyboard’s.

The following block of code describes how to had your custom view to the UIKeyboard.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

/*!
 As of iPhone SDK 2.2.1:
 Keyboard view is in a separated window from our application main window.
 We're digging through the unknown here, but if for some wacky reason this
 code is broke, the only side effect will be that the keyboard dismiss 
 button will not be shown.
 */
- (void)modifyKeyboard:(NSNotification *)notification 
{
    NSValue *v = [[notification userInfo] valueForKey:UIKeyboardBoundsUserInfoKey];
    CGRect kbBounds = [v CGRectValue];
 
    for (UIWindow *keyboardWindow in [[UIApplication sharedApplication] windows]) {
 
        // Now iterating over each subview of the available windows
        for (UIView *keyboard in [keyboardWindow subviews]) {
 
            // Check to see if the description of the view we have referenced is UIKeyboard.
            // If so then we found the keyboard view that we were looking for.
            if([[keyboard description] hasPrefix:@"<UIKeyboard"] == YES) {
 
 
                // Your view specific code for the custom view goes here
                //
                UIView *customView = [self viewForDismissKeyboard:kbBounds];
                //
                // End of custom view code
 
                // Set a tag so that if you want to remove the view later, it is a lot easier.
                [customView setTag:666]; 
 
                // Add the desired subview to the keyboard.
                [keyboard addSubview:customView];
 
                // Unregister as observer if you don't want to change the keyboard again
                // and leave the custom view across the whole application.
                [[NSNotificationCenter defaultCenter] removeObserver:self];
            }
        }
    }
}

Where do you add this code?

Since my application shares the same keyboard type across the whole app, I put this code in application delegate so that the code runs only the first time the keyborad is requested—note that I’m removing the observer in line 36. Be sure to add the following line of code at the end of application delegate applicationDidFinishLaunching:.

1
2
3
4

    [[NSNotificationCenter defaultCenter] addObserver:self
                                             selector:@selector(modifyKeyboard:) 
                                                 name:UIKeyboardWillShowNotification
                                               object:nil];

But if your application uses, let’s say a numeric and a text keyboard, and you want to add a decimal point just to the numeric keyboard, you will want to put this code in the view controller or view that holds the numeric text field. Then, after leaving the view, you shall make sure that you remove the view (controller) as an observer for the UIKeyboardWillShow and UIKeyboardWillHide notifications so that it does not affect other keyboard types. I suggest you to see UIViewController viewWillAppear and viewWillDisappear methods add/remove the custom view and unregister for UIKeyboardWillShow and UIKeyboardWillHide notifications.

If you need further help adapting this code to your application, be at will to contact me.

I spent most of my time crafting code, either in Xcode, IntelliJ IDEA or TextMate, and, oh boy, I like to do it classy. Hence, to date, I’ve ported CSSEdit’s color theme to XCode and IntelliJ IDEA, and now I’m sharing the love here with you.

Below is how it looks on Xcode (go to Flickr to see the full size version).

So without further ado, download the color themes with the links below.

As a note, IntelliJ IDEA version supports Java, Java Properties, PHP, XML, HTML, XPath, CSS, JavaScript, Groovy, JSP, SQL and Diff. Both themes use Monaco 11pt. You can obviously use the typeface of your choice. If you don’t have the Monaco typeface you can download it here. Additionally, you can get a good compilation of programming fonts here.

I also started a repository in GitHub hoping more themes and editors will join. Explore it here, grab it, play with it and be at will to contact me if you want to contribute with more themes and editors.

I never really gave it much credit as something useful or witty until I came across this beautiful work by the gifted Louie Mantia. I immediately liked the background artwork of the pictures but I wasn’t convinced to use them until I realized how well the subtle (PRODUCT) RED letterings would work together with the mentioned feature.

Now, I’m wondering where can I find more desktop pictures bundles like this one. I’d also love to see you sharing some ideas for new pictures in the comments .

Below, is my System Preferences settings for the desktop picture.

Just for the record. It’s Sunday afternoon and I just had one of those two-hours-long lunches. I open my laptop to find that it salutes me with a bold SAVO(RED)—apologies to british pundits—. Well, I don’t know about you, but this sure made me chuckle for the day. I already can imagine myself working late into night and seeing my desktop wallpaper displaying TI(RED) or HAMME(RED).

Sidenote: Now it’s displaying INSPI(RED) but something along the lines of BO(RED) would be more accurate.

I’ve been dragging the start of this blog for about a year now because neither time nor proper motivation haven’t been on my side. I have this day job, you know, just like you probably do. Problem is, I’m still finishing college. And this pretty much sucks up most of my time.

Truth be told, I’ve been neglecting almost all parts of my online social presence for the last couple of years—read blog, Twitter, Facebook, LinkedIn, and pretty much everything else, for that matter—.

Well, but this year, I’m off to a new start. New year, new life, new resolutions and now I’m really committed to this.

What will I blog about?

This will be an attempt to put into words my opinions, ideas, rants and occasionally to talk about and detail what I’ve been up to. While spelling out code, dangling on software development process and rambling on user experience/interface design for the web, desktop and mobile platforms, I guess something worth putting up here will come up.

Particularly, since lately I’ve been fully immersed with iPhone development, I’ll share some bits now and then around here on Objective-C, UIKit and the App Store.

Though, let me advise you. One could say I’m biased and annoyingly opinionated. That would come up totally true, but heck, that’s the way I’ve been getting along all my life, so you may expect this to reflect here.

So, here I go. I’m blogging now. Hope you’ll like it. Be at will to subscribe the syndicate feed.

Disclaimer: Here I’ll express my own opinions, which are not endorsed in any way by my employer, nor anyone else, for that matter.

The product, also known as TeleMB, was recently re-branded to MB Phone. I recommend you to give it a spin using the direct link to the App Store (Portuguese only) below.