Indelible Ink

Manually Loading nib Files

2011-06-15T00:00:00-07:00

Interface Builder is the standard Mac OS and iOS user interface design tool. Layouts are saved as "nib" (NeXT Interface Builder) files. Recent versions of Interface Builder write these files as XML archives using the .xib file extension.

At runtime, nib files are loaded and assigned an "owner" object that forms the basis of the layout's object hierarchy. This "owner" is very often a view controller object. In this article, we'll focus specifically on UIKit and its UIViewController class.

The nib loading process is generally abstracted away as part of the standard UIViewController initialization process. Here's a simple example:

- (id)init
{
    if ((self = [super initWithNibName:@"SomeNib" bundle:nil])) {
        // additional view controller initialization
    }

    return self;
}

-initWithNibName:bundle: handles all of the nib loading and instantiation work. While this is quite convenient, it has one major limitation: the nib file must have been compiled and bundled (in the NSBundle sense) along with the application itself. Fortunately, it is possible to manually load a nib from arbitrary data and associate its contents with a view controller.

The UINib Class

The UINib class provides all of the functionality needed to manually load nib files. One reason to do this is to pre-cache the contents of a nib file in memory, ready for quick deserialization and instantiation later in the application's lifetime. Another reason (and our focus here) is to load the raw nib data from an alternate (non-NSBundle) source.

The UINib class provides two methods for loading nibs:

+nibWithNibName:bundle: - load a bundled nib file
+nibWithData:bundle: - load raw nib data

Once loaded, the nib's objects can be instantiated and assigned an owner using the -instantiateWithOwner:options: instance method.

Manual View Controller Loading

How can the UINib class be used in conjunction with a view controller?

First, the view controller needs to call UIViewController's designated initializer without a nib name. Note that passing nil as the nib name will trigger an automatic lookup for a nib named the same as the view controller class, so take care not to fall into that case unintentionally.

[super initWithNibName:nil bundle:nil]

Because this view controller hasn't loaded a view during initialization, we must implement the -loadView method. This is where all of the manual loading is performed.

- (void)loadView
{
    [super loadView];

    UINib *nib = [UINib nibWithNibName:@"SomeNib" bundle:nil];
    [nib instantiateWithOwner:self options:nil];
}

This code effectively reproduces the standard nib loading process that was previously being handled by -initWithNibName:bundle: itself.

Loading Raw nib Data

At this point, our code is now manually loading the nib's objects, but it's still reading the nib itself from our application bundle. We can go a step further and load arbitrary nib data using the +nibWithData:bundle: method.

- (void)loadView
{
    [super loadView];

    NSData *data = [NSData dataWithContentsOfFile:@"SomeNib.xib.bin"];

    UINib *nib = [UINib nibWithData:data bundle:nil];
    [nib instantiateWithOwner:self options:nil];
}

The nib data can come from pretty much anywhere, such as from a bundled file or a network-fetched resource. The only requirement is that the nib data be compiled. To compile an existing .xib file, use ibtool:

ibtool SomeNib.xib --compile SomeNib.xib.bin

Additional Considerations

Now that the basic approach has been established, there are a few practical considerations to keep in mind. First, we've largely ignored the bundle parameter in the above code examples. This argument instructs the nib loader where to look for dependent resources, such as images. Passing nil implies that the main application bundle ([NSBundle mainBundle]) should be used. There unfortunately doesn't appear to be a way to redirect these lookups to non-bundle locations, however.

Next, the nib data needs to be available by the time the view controller is initialized. All I/O needs to block, and any stalls could result in a poor user experience. Given that, any non-bundled nib data needs to be fetched before the view is loaded.

Lastly, nibs can contain references to "external" objects. One such example is the "owner" object, which is explicitly resolved by the call to -instantiateWithOwner:options:. If the nib references any additional external objects, the loading code must provide those objects via a dictionary mapping passed through the options: interface's UINibExternalObjects key.

Password Composer for iPhone

2009-10-25T00:00:00-07:00

I often use Password Composer (written by Johannes la Poutré) to generate unique, per-site passwords. It does an excellent job because it's simple, unobtrusive, and reliable. The one downside is that you need to have it available in order to (re)generate the password for a given web site, and that isn't always convenient, despite the large number of existing Password Composer implementations.

The main place I find myself missing Password Composer is on my iPhone. The only current solution that works from Mobile Safari is the public web-based interface, and I'm security-conscious enough to avoid using that version whenever possible. I decided the only reasonable solution would be to find a way to run Password Composer locally on my iPhone.

I first considered writing a full-blown native iPhone application. I know a bit of Objective-C and have experimented with the iPhone SDK, but, additional learning opportunities aside, this approach felt like overkill.

I then discovered the option of writing an iPhone-enhanced offline web application. That would let me reuse Password Composer's existing static web form without having to work through the iPhone SDK. I found the early release of Jonathan Stark's Building iPhone Applications with HTML, CSS, and JavaScript and set out to adapt Password Composer to the iPhone.

Basic Application

The basic application started as a single HTML file containing a form and some JavaScript.

    <html>
    <head>
        <title>Password Composer</title>
    </head>
    <body>

    <script type="text/javascript">
    // Password Composer JavaScript
    </script>

    <h1>Password Composer</h1>

    <form>
    <table>
    <tr>
        <td>Master Key:</td>
        <td><input type="password" id="masterpwd1" onkeyup="mpwd_generate()"
            onchange="mpwd_generate()"/></td>
    </tr>
    <tr>
        <td>Domain:</td>
        <td><input type="text" id="domain1" onkeyup="mpwd_generate()"
            onchange="mpwd_generate()"/></td>
    </tr>
    <tr>
        <td>Password:</td>
        <td><input type="text" id="genpwd1" onkeyup="mpwd_generate()"
            onchange="mpwd_generate()"/></td>
    </tr>
    </table>
    </form>

    </body>
    </html>

The JavaScript and form were copied directly from Password Composer's public web-based interface and worked just fine in Mobile Safari.

Styling the Application

Next, I set about styling the look and feel of the page to more closely resemble an iPhone application. I started by adding a stylesheet file. I could have used inline CSS, and maybe I'll merge the styles back into the main page at some point in the future, but using a separate file keeps things more manageable for the time being.

    body {
        background-color: #ddd;
        color: #222;
        font-family: Helvetica; 
        font-size: 14px;
        margin: 0;
        padding: 0;
    }

    h1 {
        background-image: -webkit-gradient(linear, left top, left bottom,
                                           from(#ccc), to(#aaa));
        background-color: #ccc;
        border-bottom: 1px solid #666;
        color: #222;
        font-size: 20px;
        font-weight: bold;
        padding: 10px 0;
        text-align: center;
        text-decoration: none;
        text-shadow: 0px 1px 0px #ddd;
    }

    form {
        background-color: #FFFFFF;
        border: 1px solid #999999;
        color: #222222;
        font-size: 15px;
        padding: 12px 10px;
        margin: 10px;
        -webkit-border-radius: 8px;
    }

    td, input {
        font-size: 14px;
    }

Most of these styles are influenced by examples from Jonathan Stark's book.

Viewport Definition

The next change is the addition of a viewport meta tag:

    <meta name="viewport" content="user-scalable=no, width=device-width" />

This viewport definition convinces Mobile Safari not to rescale the HTML content as though it were a "normal" 980px-wide web page.

Input Field Types

I was also interested in configuring the form's <input> fields to pop up the most appropriate type of on-screen keyboard on the iPhone. Master Key was already being recognized as a password field (type=password), but I wanted the Domain field to use the iPhone's special URL keyboard.

A little research indicated that Mobile Safari recognizes a small subset of the HTML5 input types, including the url type.

    <input type="url" id="domain1">

Custom Icon

Because I want Password Composer to feel like a natural, first-class iPhone application, it deserves to get a real icon. This icon is used when a link to the application is saved to the user's home screen. Home screen icons are 57×57 pixel PNG images.

There are two ways for a web application to specify its home screen icon:

Provide a file named apple-touch-icon.png in the site's root.
Add a <link rel="apple-touch-icon" href="icon.png" /> tag to the page's <head> block.

I chose the second approach because I wasn't planning on using an entire domain to serve the Password Composer application. It also feels like better encapsulation for a single-page web application.

Offline Application Cache

The last bit of work adds support for the iPhone's offline application cache. This cache allows the files used by a web-based applications to be stored locally on the iPhone so that they can still be accessed when the phone doesn't have an active network connection. This "offline mode" is described quite well in Stark's book: Chapter 6: Going Offline.

Briefly, all that's required is the creation of a "manifest" file, as specified by HTML5. My manifest file is named pwdcomposer.manifest:

CACHE MANIFEST
index.html
iphone.css
icon.png

The manifest lists all of the files used by the web application. Manifest files can be much more involved than this example. They can specify fallback images for use when network-based files are inaccessible, for example. But for my current purposes, the simple manifest above works great.

Manifest files must be served using the text/cache-manifest MIME type. For Apache-like web servers, this can be configured using a directive like:

    AddType text/cache-manifest .manifest

Lastly, the web page needs to specify its associated manifest file using the manifest attribute of the <html> element:

    <html manifest="pwdcomposer.manifest">

Deployment

All that is left to do is deploy the application. Simply serve up the source files using a web server, and iPhone users can choose to bookmark the application's link just like they would for any other web page. The offline application caching system will work automatically. When the iPhone is connected to a network, Mobile Safari will attempt to fetch the original manifest file to check for updates, but the application will otherwise be running entirely from the cache, essentially making it a local iPhone application.

My version is deployed here: http://www.indelible.org/pwdcomposer/

The complete source code is available on GitHub.