CITS4211: Artificial Intelligence Getting Jiggy with Xcode

Aim This exercise sheet introduces you to Java development using the integrated develop- ment environment (IDE) Xcode.

Getting Started with Xcode Starting Xcode In the dock at the bottom of the screen you should see this symbol for launching Xcode. If you don’t see it, locate it in the Finder under Developer/Applications and drag it onto the Dock.

Click on the launcher.

Creating, Compiling and Running a New Project Follow the instructions (with the exceptions below) at The Java Tutorial’s “Hello World for Mac OS X” page at: http://bioportal.weizmann.ac.il/course/prog2/tutorial/getStarted/cupojava/mac.html

The latest version of Xcode has changed a little so you will notice a few differences. In particular there are a couple of things you should know.

Create a Source File

When you create a new application you should choose the “Java Tool” option, which su- percedes the “Ant-based Jar Application” option shown in the tutorial.

When you select the Java Tool, a window will open to select where you want to save the project. The project name will be the same as the directory name. Navigate to your CITS4211 directory (created in the previous lab) - to make this easier click the down tri- angle beside the “Save As” field. Click New Folder to create a subdirectory, and call the subdirectory Lab00. Select that subdirectory, then type in the project name (“Hel- loWorldApp”).

Compile and Run

The console window no longer pops up by default. To see the output of your program se- lect Run|Console. The quick tutorial takes you through the basics of creating an Ant-based jar application (more on this later), and building and running it. You should now have your first working application in Xcode!

Customising Xcode In the above tutorial you are asked to edit the program in a little editor pane that you pull up from the bottom of the project window. This is constraining in practice and you will want to be able to use multiple editor windows.

You can open an editor window for your hello world app by double clicking it in the file list, or by clicking the triangle next to ‘src’ and double clicking your java file in the result- ing list.

In the top right corner of the editor window that opens, you will see an icon that says “Ungrouped” or “Grouped”. Grouped opens subsequent files in the same window, whereas ungrouped will open subsequent files in new windows. The former may be useful if you have very limited screen space, for example on a small laptop, but in general can seem confusing as files “disappear”. Set this to “Ungrouped”.

There are many other preferences you can set, including a couple of useful ones that you should do now. Go to Xcode Preferences | Indentation. Deselect “Insert tabs instead of spaces” (this will help if you later wish to edit the file with another editor). Set Tab width and Indent width to 2. Also check “Syntax aware indenting”, and set “Tab indents” to “Always”. Then hit “Apply” or “OK”.

Now return to your hello world java program. Place the cursor on the word “void” in the first line of the main method. Hit C-f (-f) - notice how those “emacs” commands you learnt also work in Xcode! Hold C-f until the cursor is at the start of the next line of code. Now press ‘tab’. You should notice the code adjusted so that it is indented two spaces from the line above. The editor is “context aware” - it knows that the main method is subordinate to the class statement and should be indented. Now press ‘tab’ again. If you have followed the above instructions correctly you should notice no change - the editor knows that it is not appropriate to indent any further. Similarly place the cursor after the ‘{’ and press ‘return’ - the next line should automatically be indented to the right place. (This can be a useful early debugging feature - if the editor doesn’t indent a line to where you expected, chances are you missed out a closing bracket or similar.)

Compile Error Highlighting Before we leave Xcode lets take a quick look at an example facility Xcode provides to help with debugging. First go to the Xcode preferences and choose the “Building” pane. Under “Build Results Window” set “Open during builds” to “On Errors or Warnings” and click “Apply”. Then go to the “Text Editing” pane and tick “Show line numbers”, and click “OK”.

Now open your hello world java file and change the word void to vod. Pretend you weren’t tipped off by the change of colour of the word, and click “Build and Go” again. (You may notice the code still executes correctly. This is a good reminder that you should always save your code before building. You can quickly save it by hitting Command-s.)

Notice that a build results window opens listing two errors in red. Click on “cannot find symbol”. You should see your java file open with the erroneous line highlighted, ready for you to fix. You can also access the build results window by clicking the red cross that ap- pears when there are build errors.

It is these kinds of conveniences that make GUI development environments nice to use (in fact there are many more debugging facilities at your disposal). Remember though that the same basic functionality can be achieved in different ways, including from the Unix command line. A simple example of this follows.

Behind the Magic: Part I We will look in more detail later at how Ant-based builds work in Xcode and how you can tailor them to your needs. Before we go on, however, have a look at the Xcode project tree using Finder to see where the various files are located.

You will see that the directory your project is in contains the project file, with extension ‘.xcodeproj’, as well as the file build.xml and a resources directory containing the file Manifest. We will see what these do later. If you click on the src (short for “source”) directory, you will see it contains the java sources for your project. Now click on the bin (traditionally short for “binaries”, tho in this case they are actually byte codes) directory. This directory is where the java executables or class files are placed when you build your project from the sources. Finally, have a look in the dist (short for “distribution”) direc- tory. This is where the final product of the build is placed (ready for distribution to your clients). In this case the final product is a jar file (short for “java archive” - a compressed archive of the class files). You can also run the product from this directory.

Now open up a new shell (Terminal window - see the MacOSX lab sheet) and change di- rectory to the project directory, and then to the dist directory. List the contents and you will see HelloWorldApp.jar. Have a look at the contents of the jar file with the com- mand:

% jar -tf HelloWorldApp.jar

To see what the ‘t’ and ‘f’ flags stand for, have a look at the jar command’s man page (see the MacOSX lab sheet). You should see a manifest, and the class files (in this case just one). Now run your program using:

% java -jar “HelloWorldApp.jar”

Once again, take a look at the man page for the “java” command to see where this incan- tation came from. In fact, this is the same command Xcode uses to run your code! (In the next lab sheet we will look at how executables are defined in Xcode.)

The moral: in a Unix-based system, you can usually look behind the “magic” of the GUI to understand what is really happening at the operating system level.

Continuing on.. Later you may wish to continue on for the rest of the trail in the Java Tutorial from above. You will find that it refreshes some of your Java knowledge, and finishes with some self- test questions and answers. Behind the Magic: Part II One reason that development environments are useful for working on larger software pro- jects is because they handle many of the other tasks that are required in addition to sim- ply compiling a program, such as creating directories, placing the right build products in the right places, creating deliverables for development and production builds, cleaning up, etc. In many development environments the way in which this is done is hidden from the user, who is required to tailor the process by setting various parameters.

Long before the advent of integrated development environments, these same tasks were necessary, but were done using scripts - the most widely used being a utility known as make. A more recent version, developed specifically for Java, is the Apache opens source Ant tool. Have a read through the description of Ant (and the inherent evils of Makefiles). One of the nice things about the Xcode projects we are using is that they are transparent - the build is simply handled by calling Ant.

The tasks carried out by Ant are specified by an XML file called build.xml. Find this file in your own project and double click to open it up. You will find that its fairly self- explanatory or “human-readable”. You can find out exactly what commands are available and what they do by looking at the Manual at the Ant website.

You can specify exactly what should be done on a build (for example when you hit Xcode’s Build and Go button) simply by modifying the build file. Try modifying your own build file so that when you build, in addition to compiling your code, it also automatically (re)generates the javadoc documentation for your code, and places it in a directory in your project called “doc”. (The build should also create the directory if it doesn’t already exist.)

Of course one advantage of Xcode using Ant builds is that you can take a copy of your project home and work on it, even if you don’t have Xcode. You just need to ensure Ant is installed on your machine and run Ant directly.

Cara MacNish CSSE @ UWA