Learning iCloud Data Management (2014)

Part III: Using the Technologies

11. Using Xcode Workspaces for Shared Development

This book provides a guide to the various data management tools you find in OS X and iOS. It is true that some of them, such as preferences and settings, can affect a single app on a single device, but by and large, when you are talking about iCloud, you are talking about several devices for a single user. And those devices often run different operating systems—iOS and OS X.

That is why in the examples so far in this book, you may find an iOS version of the example and an OS X version of the example. That makes sense: although related and very similar in many ways, they are different operating systems for different types of computers.

If you compare the code for the pairs of examples, you’ll find tremendous similarities. Not to put too fine a point on it, you’ll find a great deal of duplication. That means duplicated code to type twice. Duplicated bugs (no matter how careful you are) to fix twice. The engineers and developers at Apple obviously are aware of this, and they thought about ways to make your life easier.

Xcode 5 (the integrated development environment—IDE—for iOS and OS X) was released in the fall of 2013. It sported many new features—among them a completely redesigned interface that uses the latest UI techniques from Apple along with integration of developer accounts so that provisioning of projects can be done from Xcode. This major change came about just over 2 years after Xcode 4, which, along with a major rearchitecting of the IDE itself, introduced the concept of workspaces. Suggesting that Xcode 4 and its rearchitecting were done solely to address the issue of duplicated code is wrong, but the fact is that, without that rearchitecting, it would have been more difficult to address the issue.

Because Xcode 5 is still new to many developers, workspaces are a new technology in many cases. The uses and benefits of workspaces are particularly important to developers like you who are interested in building apps that use and reuse code (between iOS and OS X versions of an app, for example).

Because of the importance of workspaces for apps that are built for both OSes and because so many developers are not familiar with them, this chapter takes a timeout from the APIs to focus on Xcode and its workspaces. By the end of this chapter, you’ll be back to more or less where you were at the end of the previous chapter. But at the end of this chapter, a single Xcode workspace will contain that iOS app along with the shell of an OS X version of that same app The two app projects will be unified into a single workspace, and the code that is shared between the two app projects will be placed—once—in the workspace to avoid the issue of duplication.

The code that is shared in this chapter is the essential shared code: the managed object subclass that instantiates the data model as well as the data model itself. There is no point duplicating this code in two projects, and doing so is dangerous because in order to properly share the data, the same data model must be used in both the iOS and the OS X project. Sharing a single copy of the source code prevents consistency problems.

Building on the Digital Hub

The launch of a new Apple device attracts crowds to Apple stores around the world as well as to websites and blogs with the latest news and rumors. The debut of a new operating system typically attracts less attention, but it is still greeted with excitement by Apple devotees and attention by technology media and, in many cases, more broadly focused media.

Then there are the long-term projects that can wind up changing people’s lives far more than a new phone, tablet, or computer can. One of these was Apple’s Digital Hub strategy, which Steve Jobs introduced in 2001. In my book about it in 2002, I quoted from Apple’s own description of the Digital Hub: “Apple is the only company that makes the hardware, the operating system, and the software—all completely integrated with Apple’s ease of use. With the help of some select electronics, Mac OS X and applications like iTunes, iMovie2, iDVD2, and iPhoto, Apple makes your digital lifestyle possible.”

As introduced, the Digital Hub had the Mac at its center, and that’s how it remained for a number of years. The architecture was simple enough that new components could be added to the basic design—iPod and iPhone on the hardware side and iTunes on the software side. iPhone OS evolved into iOS, and the connections from the Mac to the devices changed from wired to over-the-air.

With the advent of over-the-air updates, the digital hub could move from the Mac into the cloud—iCloud in many ways is this decade’s digital hub. If you think of the changes that occurred in the decade after the announcement of the Digital Hub at MacWorld in 2001, in retrospect you can see that while there were some blockbuster attention-getting moments (the release of iPod, for example), many small steps moved the architecture forward. How many of these were planned from the start and how many developed as Apple engineers enhanced the broad design of the Digital Hub, we don’t know. What we do know is that a clear vision of an overall architecture helps hardware and software developers as well as user experiences move to a new paradigm of usability.

The Digital Hub is a good concept to remember. Not only is it a clear predecessor to iCloud today, but as you look back, you can see that it took many years for all of the pieces to fall into place. When it was first announced, the Digital Hub was often derided as nothing more than a marketing gimmick. People said it didn’t work and wouldn’t work. The commitment to the architecture and its evolution was a key part of Apple’s strategy during the first decade of the 21st century.

iCloud is a remarkably similar architecture, and its evolution is playing out in the same way. Just as with the Digital Hub, small changes and improvements often contribute to the evolution of the concept as a whole. So think about this little bit of history, and bear in mind that a change in Xcode (workspaces) fits very neatly into one particular part of the iCloud architecture.

The pattern is being repeated.

Reviewing Xcode File Management

In Xcode, you normally work on projects. A project usually winds up being an app. For example, if you create a new project based on the Xcode iOS Master-Detail Application template for iOS, Figure 11.1 shows you the settings to create the project.

Figure 11.1 Creating a new project

In Figure 11.2, you see the project that is created. Navigate to AppDelegate.h and, in the utility area at the right, choose the file icon at the top.

Figure 11.2 Looking at the project

At the top of the utility area, you see the file name and file type. Below that, you see the location. There are two pieces of information here: how the location is determined and what the file name is. In this case, the location is relative to the group in which the file is located.

Now here is something that you may have known about Xcode projects, but you may very well have never bothered about it. The files shown in the project navigator are grouped together using folder icons. These are not folders on disk. For example, notice in Figure 11.2 that you have a group for CoreDataiOSApp, and, at that same level, groups for CoreDataiOSTests, Frameworks, and Products. Within CoreDataiOSApp, you have a subgroup for Supporting Files. All of these groups are within the project itself in the project navigator at the left of the window.

If you open the CoreDataiOSApp folder created by Xcode after you complete the form in Figure 11.1, you see a CoreDataiOSApp folder alongside a file called CoreDataiOSApp.xcodeproj, which is the project file, as shown in Figure 11.3. Figure 11.3 also shows the files that are inside the CoreDataiOSApp folder in the Finder. Inside Xcode, these are shown in both the CoreDataiOSApp group and within the Supporting Files group. Some of them are not shown in the project navigator. That is because interface files are all inside the base.lproj file in the Finder. Every supported language has its own lproj file.

Figure 11.3 Comparing files and folders in the Finder with files and groups in the project navigator

You can associate a new file on disk with a file in the project. Do so by clicking the small button to the right of the filename in the Location section. That will open the sheet shown in Figure 11.4, which lets you pick a new file on disk for the file in the project.

Figure 11.4 Associating a new disk file with the file in the project navigator

Beneath the location, you see the full path to the file. The small arrow to the right of the path will reveal the file in the Finder, as you see in Figure 11.5.

Figure 11.5 Revealing the file in the Finder

The key points to remember here are that the structure of files in the Finder differs from the structure you see inside a project with files and groups. You can change the way in which the mapping occurs using the File inspector in the Utility area.

Setting Up a Multiproject Workspace

The goal of a multiproject workspace is to use shared files in two projects rather than duplicated files in two projects. You can set up a workspace and then create projects within it. You can also add projects to a workspace. What is shown here is a way to add projects to a workspace in a way that makes the project navigator in the workspace particularly usable.

When you are finished, the files in the workspace window should look like Figure 11.6.

Figure 11.6 Creating a workspace window for two projects and a shared folder as its own group

Within an enclosing folder (CoreDataApp), you can see the workspace file itself. There are three main folders within it:

CoreDataiOSApp is the project as you built it in Chapter 10, “Managing Persistent Storage with Core Data.” This folder is open in Figure 11.6.

CoreDataOSXApp is a companion project for OS X.

CoreDataShared, which is also opened, contains the data model and the two class files. These files will be used by both of the projects without the need for duplication.

There are several ways to set this up. The steps that follow are those that I prefer to use. At the end of this section, I’ll show you another way of doing this.

Creating a Multiproject Workspace

The following steps work when you have one or more projects that you want to add to a workspace:

1. Create a new folder in the Finder for the combined project—in this case, it’s called CoreDataApp.

2. Drag two existing projects into the folder. You can drag both CoreDataiOSApp (from Chapter 10) as well as a new CocoaDataOSSXApp, if you want.

3. Launch Xcode and create a new workspace from File, New, Workspace.

4. Place it inside the CoreDataApp folder, as shown in Figure 11.7.

Figure 11.7 Placing the two projects in the same folder

5. Now that the two projects are in the same Finder folder, it’s time to put them both in the same Xcode workspace. Control-click in the workspace window to bring up the shortcut menu, as shown in Figure 11.8. Choose Add Files to CoreDataApp.

Figure 11.8 Using the workspace window shortcut menu

6. As shown in Figure 11.9, select one of the xcodeproj files from one of the projects that you placed inside CoreDataApp. (Do not use the checkbox to copy files into the destination.) Then click Add.

Figure 11.9 Adding a project to the workspace

7. Repeat for the xcodeproj file in the other project.

Your workspace window now has both projects in it, and each project’s files are in their own folder in the Finder. Figure 11.10 shows the workspace window now.

Figure 11.10 Both projects are in a single workspace

8. Inside the combined project folder in the Finder, create a new folder called CoreDataShared.

9. Move the Observation.h and Observation.m files as well as the data model from CoreDataiOSApp into this new folder. Because the data model file is actually a file package, dragging it in the Finder may not work, so compress it to a zip file and drag it into the combined project folder, as shown in Figure 11.11.

Figure 11.11 Moving the shared files into the shared folder

10. Unzip the data model file and manually remove the uncompressed file from the original location in CoreDataiOSApp. (This is necessary because the data model is a file package.) You can get rid of the zip file. You may want to reorganize your projects in the workspace so that a group in each one contains the shared files.

11. In the project navigator for CoreDataiOSApp, Observation file names are now shown in red because they don’t exist in their old locations (inside the CoreDataiOSApp folder). Reconnect them to the files in the CoreDataShared folder. Use the technique illustrated earlier in Figure 11.4.Figure 11.12 shows how that will look with the files in this project.

Figure 11.12 Adding the files to the project

You should now be able to build and run the CoreDataiOSApp from the workspace: you’re back where you were at the end of the last chapter in terms of code, but you have the common workspace as a way to move on to your shared code base. This will be completed in Chapter 18, “Completing the Round Trip.”

Chapter Summary

This chapter showed you how to convert two separate projects that duplicate a data model and other files to a unified project that shares the duplicated code. This is done by using the workspace functionality that was first released in Xcode 4. These shared workspaces can rely in part on the ability to use Xcode’s file references so that files can be anywhere. (And remember that those folder-like icons in the project navigator are definitely not Finder folders.) Creating a shared workspace like this can reduce the amount of code you need to maintain and debug. In addition, it can make the structure of your apps clearer.

Shared code and workspaces are not the cure-all for everything. Most of the Xcode templates at this time do not use workspaces, and they’re not necessary if you know that you’re writing an app that will not need to run on both iOX and OS X. However, if you know you’ll need this structure, it’s good to set it up from the start.

Nevertheless, the steps in this chapter help you convert separate projects to a shared project using a workspace. That can make your implementation of iCloud on both OSes much easier as you proceed.

Exercise

1. When you adopt this style of file and code structuring, you may need to rethink the way you store your files on disk. Keeping a shared workspace’s files organized in a logical way will pay off for you. How you do it depends on the kind of work you’re doing, whether you’re sharing files with colleagues on the project, and what kinds of backups and shared disks you have available. Devote time—perhaps even a few hours—to organizing your files. And if you haven’t been using Git or Subversion for source code control, take that step now. (Both are integrated with Xcode, but the Git integration is more powerful.)