Interface Builder

from Wikipedia, the free encyclopedia
Interface Builder
Basic data

developer Apple
Current  version 4.0 (integrated into Xcode)
(March 22, 2012)
operating system macOS
category GUI builder , software development
License proprietary
German speaking No
developer.apple.com

The Interface Builder is software from Apple that is used to create graphical user interfaces for programs for macOS and iOS .

The Interface Builder was already included in the Developer Tools for NeXTStep . In Project Builder (2001–2003) and Xcode (2003 to today) the Interface Builder was or is an important part of the developer tools. Up to and including Xcode 3.x, the Interface Builder was a stand-alone application, but with Xcode 4.0 it was integrated into the IDE.

The files that the Interface Builder creates have the file extension .nib (by NeXT Interface Builder ; the files are often called "nib files" by developers) or .xib .

The GNUstep project wrote a clone of Interface Builder called Gorm .

history

NeXTStep

The first version of Interface Builder appeared in 1986 and was written in Lisp . The developer of the tool was taken over by NeXT in the same year , and Interface Builder was part of NeXTStep 0.8 as early as 1988. It was the first commercial application that could be used to compose a user interface using a mouse .

Project Builder (2001-2003)

NeXTStep served as the basis for Mac OS X, and when Mac OS X 10.0 came out, Apple also released a new version of the Developer Tools. Part of this was, in addition to a completely rewritten version of Project Builder , also Interface Builder for creating surfaces for Carbon and Cocoa applications (in C ++ or Objective-C .)

ResEdit , which was used to create interfaces under Mac OS 9 and before, could no longer be used under Mac OS X because the new system bundles (code and resources in different files, but together in a folder with a certain structure) instead Code forks and resource forks used.

Xcode (from 2003)

As of Mac OS X Panther , Project Builder was no longer supported, instead Apple relied on the Xcode Tools with Xcode as the IDE. Interface Builder was retained. Since the data format was not changed, programs and NIB files that were created with Panther can also be executed on older systems.

With Panther, the Cocoa Bindings were introduced, which connect UI elements and code with one another.

Interface Builder was improved and expanded with each operating system release so that it supported the new UI elements of a new system version (e.g. the HUD panels in 10.5 .)

With the release of the iPhone SDK 2.0 and Xcode 3.1, the Interface Builder was also updated in order to be able to design interfaces for iPhone apps.

With Xcode 4.0 Interface Builder was integrated directly into Xcode. This offered several advantages: Developers no longer had to have two applications open, they no longer had to save the code to connect it to the UI, and they could drag and drop the UI elements directly to the source code .

functionality

Creating the surface

Objects for a surface are grouped in so-called palettes. In the AppKit framework there is a palette for the UI elements such as windows, buttons, lists, images or text fields specified by the system.

Usually a window ( NSWindow ) or an area ( NSView ) serves as the basic element . Each .nib file is associated with a class that also declares the outlets and actions (see next section); this class is often a subclass of NSWindow or NSView , and more rarely NSObject .

Further elements can then be placed on these surfaces, their properties can be changed and they can be linked to the code.

Connect UI and code

UI elements are connected to the code via outlets. The declaration is made in the respective header file as follows: 

@property (nonatomic, retain) IBOutlet NSButton *readInputButton;

Many objects can send a message to a target when certain actions are taken (e.g. pressed or changed ). The declaration in the header looks like B. looks like this: 

- (IBAction) adjustVolume: (id)sender;

In the actual source code there is a method with the same declaration, which is then executed if necessary. The generic data type id enables the method to be called from different objects, e.g. B. from a button and a slider.

Objects, outlets, actions and targets are connected to one another using drag and drop.

Save and run

The finished file with its connections to the code is saved in a property list file with the file extension .nib (mostly as XML during development , in the finished product as a binary file). When the program is run and the NIB file is "woken up" it is loaded and linked to the binary code.

Interface Builder 3.0 introduced a new file format with the file extension .xib. It has exactly the same functionality as .nib files, but its data structure makes it easier to work with in tools like version control and diff . However, the files are still called nib files by most developers.

Apple recommends packing different windows (unless they belong to one class) in different NIB files. The main reasons for this are clarity and efficiency (it takes longer to load one large file into memory and connect than three small ones.)

Localization

Elements with text can be localized either by code or directly in the Interface Builder. For the localization, folders with the language abbreviation and the extension .lproj are created, in which the localized NIB files are then saved. During the execution, only the file in the folder with the current system language is loaded and executed. The localization by code is done using .strings files and the method NSLocalizableString().

There are also some third-party programs that can be used to locate either the String or NIB files.

Surfaces without an Interface Builder

It is easily possible to write UIs for applications not via Interface Builder but via code. In order to ensure portability, especially with libraries and frameworks, programmatically created views are usually used. Another advantage arises when several developers work on one app. Only minimal changes in .storyboard- or .xib file could void is that the underlying XML file significantly changed, which relatively quickly leads to conflict when the various changes merged to be. This problem does not exist with manually programmed views, since the structure of the class cannot change arbitrarily. In addition, the individual parts of the app are better encapsulated. With a storyboard, the entire user interface of an app is usually in one file; with the programmatic approach, each view is created in its own class.

Programmatically created views are also more efficient, since no additional XML file has to be loaded and parsed from the memory, and much more powerful because, for example, additional properties such as shadows or frames can only be set in the code. The performance loss of the Interface Builder is not only noticeable during runtime, but also during development. Particularly with complex storyboards (here several views are managed in one file) it can take a long time to open the file in the Interface Builder.

The disadvantage is the increased time required to programmatically create the view. On the one hand, it takes longer to write the individual lines of code, on the other hand, it is more difficult to align the elements precisely. Since the graphical result can only be viewed at runtime - and not at compile time as with the Interface Builder - changes are only visible after the app has been compiled and started. Checking every change therefore takes significantly more time than with a WYSIWYG editor such as the Interface Builder. This increased complexity is unsuitable for both newbies and quick prototyping .

Individual evidence

  1. ↑ GNUstep Developer Tools - Gorm . Retrieved May 1, 2012