Xcode - MacRuby: The Definitive Guide - OFPS

9781449380373

_xcode_2.html

Chapter 5

MacRuby: The Definitive Guide

Chapter 6. Xcode

Chapter 7

Chapter 6. Xcode

Apple likes to refer to Xcode as “the hub of your development experience.” Technically, Xcode is a suite of developer tools designed to help developers write Cocoa applications. Most Cocoa developers spend their time in the Xcode IDE.

Xcode IDE

You don’t need to use an IDE to write Cocoa apps. But you will more than likely want to use the tools in place to streamline development and avoid doing a lot of things manually. As of the writing of this chapter, Xcode doesn’t support MacRuby as well as it supports Objective-C, but the key features are supported: MacRuby templates, schemes, and the integration with the Interface Builder suite.

To get acquainted with Xcode, you have the choice of starting a new project or opening an existing one. At this point, I will assume you have never used Xcode and you want to start a new MacRuby project.

Template

Figure 6.1. Xcode 4 template chooser

Start Xcode, click on Create a new Xcode project, select Application under Mac OS X, choose MacRuby Application (Figure 6.1, “Xcode 4 template chooser”), and click the Next button.

You will then be offered a few options, as shown in Figure 6.2, “Xcode MacRuby application template option chooser”:

Figure 6.2. Xcode MacRuby application template option chooser

Product Name: The unique name of your application.
Company Identifier: Your company ID using the reverse domain notation. This starts with the top-level domain, followed by a company or creator name, and then other subdomains, if any. For instance, a department called iosdev.example.com would put com.example.iosdev here.

App Store Category: Optional category you want your application to appear under in the App Store.
Create Document-Based Application: A document-based application is an application (see http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/Documents/Documents.html) revolving around a document workflow. Think about a word processor or spreadsheet application. The user can create, edit, save, and print specific versions of a document. If your application requires this kind of workflow, you will want to enable this option. You will find a lot of information about document-based applications online or in any decent Cocoa book. If enabled, you will be asked to provide a document class name and a document extension. The document class name will be used to create a class representing your document. The document extension is used for reference.
Use Core Data: Core Data is covered more in depth in Chapter 7, Core Data. Enabling the core data option will set up your application with a delegate class that takes care of persistent storage. If you need to store data for your user, you might want to consider enabling this option.
Include a Spotlight Importer: A Spotlight importer should be provided by all applications that support custom document formats. The Spotlight importer parses your document format for relevant information and assigns that information to the appropriate metadata keys, making your files’ info available via Spotlight.

Choose a product name for your application and, after choosing the appropriate options, click Next. To keep things simple, I am going to assume you didn’t enable Document-Based Application or Use Core Data. At this point, you will choose where to save your project and Xcode will automatically create a local git repository for it. Git is a distributed Source Control System that you can use to keep track of your changes, experiment in code branches, and share code with coworkers. You can also use a third-party service such as GitHub to safely save and share your code online.

The Xcode interface is a bit overwhelming at first. You might not know where to start and what to do. Let’s take a few minutes to visit the interface so you can understand the workflow.

The interface, called Workspace window, is broken down into four main areas (Figure 6.3, “Xcode Workspace window”):

Navigator area
Editor area
Debug area
Utility area

Figure 6.3. Xcode Workspace window

Navigator Area

The left part of the UI is called the Navigator area. It contains icons that allow you to switch from one navigator to the other. Seven navigators are available in Xcode 4:

Project navigator: Shows you the files used in your application.
Symbol navigator: Allows you to browse your Objective-C classes and methods (MacRuby isn’t supported yet).
Search navigator: Allows you to search your code or the frameworks you use.
Issue navigator: Logs warning and errors during the build phases.
Debug navigator: Allows you to navigate a debugging session in an Objective-C project (MacRuby isn’t supported yet).
Breakpoint navigator: Keeps track of your breakpoints (breakpoints in MacRuby aren’t currently supported in Xcode).
Log navigator: Allows you to navigate through previously generated logs.

If you look at the project navigator for a brand-new project, you will notice a few files, as shown in Figure 6.4, “Xcode project navigator”. Here is a list of the files you will find in a new project:

app-name -Info.plist: The application manifest file
MainMenu.xib: The application UI file
rb_main.rb: The application MacRuby main file (loaded by main.m)
AppDelegate.rb: The delegate class that handles the default view’s actions

Figure 6.4. Xcode project navigator

The rb_main.rb file loads the Cocoa framework and all the Ruby files available in your build/scheme and starts the application.

Note

The MacRuby main file globs the resource folder for MacRuby files (compiled or not) and loads them in the order they are found. If you have dependencies within your files, you might want to manually require some specific files in the rb_main.rb file or declare the dependencies at the top of each file (recommended). When the application is built, all the files are moved to the resources folder of the app. That is why the main file uses the NSBundle.mainBundle.resourcePath.fileSystemRepresentation Cocoa API method to look for the MacRuby files there.

The Navigator pane is easy to figure out, so let’s move on to an even more straightforward section: the editor.

Editor Area

The Editor (Figure 6.5, “Xcode Editor”) is the place where you edit your code. You can choose from three editor modes, denoted by icons (Figure 6.6, “Xcode Editor modes”):

Standard editor: Normal code editing pane
Assistant editor: Additional editing panes
Version editor: Diff tool used to see the different versions/changes of a given file

Figure 6.5. Xcode Editor

Figure 6.6. Xcode Editor modes

Note

Because Xcode’s Ruby support isn’t great, I personally use MacVim to edit Ruby code, and I set up the “Open with External Editor” feature to use MacVim from within Xcode.

By default, the line numbers aren’t displayed. If you want to display them, open the Xcode preferences, choose the Text Editing tab, and select “Show Line numbers.”

If you wish to create custom snippets, you will need to go into the Code Snippet Library and create your own. (The Code Snippet Library is available from the Utility area.)

Debug Area

Located at the bottom of the screen, the Debug area displays debug information and the data printed out by the application (Figure 6.7, “Xcode Debug area”).

Figure 6.7. Xcode Debug area

You can print data to the Debug area by using Ruby’s puts or Cocoa’s NSLog:

puts "It is #{Time.now}"
NSLog "It is week number: %s" % Time.now.strftime("%W")

The output is as follows:

It is 2011-03-20 21:04:03 -0700
2011-03-20 21:04:03.774 test App[40827:903] It is week number: 11

As you can see, the NSLog call is timestamped, and the app name is printed along with a reference ID before the string you request? This area of the workspace is really straightforward and shouldn’t cause you any trouble.

Utility Area

The Utility area, located on the right side of the screen, can seem complex at times. The reason is that this area is contextual: in other words, the options will change depending on what you are editing. As you can see in Figure 6.8, “Xcode Utility area when editing a Ruby file”, the Inspector selector bar has only two top tabs, the one we are on (File Inspector) and the Quick Help tab.

Figure 6.8. Xcode Utility area when editing a Ruby file

The bottom part of the Utility area, called the Library pane, on the other hand, has four tabs. The icons in this pane, shown in Figure 6.8, “Xcode Utility area when editing a Ruby file”, from left to right, refer to:

File Template Library (list of file templates)
Code Snippet Library (list of code snippets)
Object Library (list of UI-related objects)
Media Library (list of media to use in your app)

Now, if we were to edit a UI file such as an .xib file, the top menu (Inspector pane) would look quite different (Figure 6.9, “Xcode Utility area when editing an .xib file”).

Figure 6.9. Xcode Utility area when editing an .xib file

This time, in addition to File inspect and Quick Help, we have six more tabs at the very top:

Identity Inspector (overall settings of a given UI element)
Attributes Inspector (attribute details of a given UI element)
Size Inspector (lets you define the size and resizing behaviors of a given UI element)
Connections Inspector (relationships with other objects)
Bindings Inspector (binding details, discussed in the section called “Bindings”)
View Effects Inspector (appearance settings for a given item)

As you can see, the Utility area is useful mainly when editing a UI. As a matter of fact, I hide this area most of the time and display it only when editing my UI. There are two ways to show and hide areas via the View menu and via the workspace buttons (Figure 6.10, “Xcode view selector”).

Figure 6.10. Xcode view selector