iCloud for Developers

Automatically Sync Your iOS Data, Everywhere, All the Time

by Cesare Rocchi

Version: P1.0 (July 2013)

Copyright © 2013 The Pragmatic Programmers, LLC. This book is licensed to the individual who purchased it. We don't copy-protect it because that would limit your ability to use it for your own purposes. Please don't break this trust—you can use this across all of your devices but please do not share this copy with other members of your team, with friends, or via file sharing services. Thanks.

—Dave & Andy.

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC.

Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein.

Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://pragprog.com.

Table of Contents

Acknowledgments

Preface

Who Should Read This Book?

What’s in This Book?

How to Read This Book

Notes on Formatting

Online Resources

Requirements

Moving On

1.

Preparing Your Application for iCloud

1.1

What Is iCloud?

1.2

What’s Behind iCloud

1.3

Introducing the Grocery Application

1.4

Enabling Your Application for iCloud

1.5

Checking for iCloud Availability

1.6

Moving On

2.

Working with Key-Value Data

2.1

iCloud Storage Types

2.2

Using Key-Value Pairs with iCloud

2.3

Using Key-Value Pairs in Grocery

2.4

Reacting to Changes in iCloud

2.5

Key-Value Storage Limitations

2.6

Moving On

3.

Working with Documents

3.1

Interacting with iCloud

3.2

Extending the UIDocument Class

3.3

Modeling a Grocery Item as a UIDocument

3.4

Displaying a Grocery Item

3.5

Moving On

4.

Managing Multiple Files and iCloud Notifications

4.1

Creating and Managing Multiple Files

4.2

Creating and Managing Multiple Grocery Items

4.3

Managing Updates While an Application Is Running

4.4

Editing Grocery Item Content

4.5

Moving On

5.

Wrapping Items in a Single File

5.1

Working with File Packages

5.2

Packaging Grocery Items

5.3

Updating the User Interface

5.4

Moving On

6.

Handling Nontextual Information in a Data Model

6.1

Working with Data in Packages

6.2

Associating Images with Names

6.3

Updating the User Interface

6.4

Moving On

7.

Handling Conflicts

7.1

Working with Document States and Notifications

7.2

Preventing Conflicts Between Grocery Items

7.3

Resolving Conflicts Between Grocery Items

7.4

Moving On

8.

Working with Core Data and iCloud

8.1

The Relational Model of the Grocery List

8.2

Initializing a Core Data Stack for iCloud

8.3

Handling Conflicts

8.4

Moving On

8.5

Conclusion

A1.

Bibliography

Copyright © 2013, The Pragmatic Bookshelf.

Early Praise for iCloud for Developers

Cesare does an excellent job demonstrating how iCloud works and how you can work best within its expectations. His style is easy to follow, and he breaks it down into simple steps, but he doesn’t hold back and pretend that the complexity isn’t there. You’ll be building useful apps on iCloud in no time. Don’t hesitate to buy this book.

→

Jonathan Penn, http://cocoamanifest.net/

iCloud for Developers guides you through the three core features of iCloud: key-value store, documents, and CoreData. Each section has great examples to help you learn how to use the feature to its full potential. Buy this book if you want to learn about iCloud!

→

Matt Galloway

The cloud can be a confusing topic, but Cesare makes it easy. He shows you how to add iCloud into a real app step-by-step, covering all the juicy bits you’ll want to know along the way. If you want to use iCloud in your apps, this is the book for you!

→

Ray Wenderlich, http://raywenderlich.com

Acknowledgments

When a book shows just one author name on the cover, we tend to think it’s the result of a single-person effort. That’s far from the truth. Without the help of the many people who surrounded me (though just virtually) during the writing, this book would not have seen the light. I am happy to thank Andy and Dave for the opportunity to publish this book. John Osborn, the editor, deserves a special mention because he helped me throughout all the phases of the writing, from organizing the content to tweaking obscure sentences. Finally, I’d like to thank all the awesome technical reviewers who provided feedback on all the chapters and the code attached to this book.

- Jeff Holland

- Matt Galloway ( http://www.galloway.me.uk )

- Felipe Laso Marsetti ( http://ife.li/ )

- Marcio Valenzuela ( http://www.santiapps.com )

- Bear Cahill ( http://www.brainwashinc.com )

- Tony Dahbura ( http://www.fullmoonmanor.net/FullMoonManor/Welcome.html )

- Jonathan Penn ( http://cocoamanifest.net )

Copyright © 2013, The Pragmatic Bookshelf.

Preface

You are an iOS developer with a successful application to your credit, but your customers want more and pepper you with questions: How do I back up my data? How can I replicate on my iPad the data that I’ve created on my iPhone? If I buy a new iPhone, will I lose the data in my apps when I switch devices?

You’d like to support your users, but you don’t have the skills or time to build a back-end system that could provide the safe and reliable backups your customers say they want. Moreover, the thought of synchronizing data across multiple devices gives you a headache.

If any of this applies to you, iCloud is a good candidate for solving your problems and giving your users the features they’ve requested. This book will teach you how to work with iCloud, hook up with its APIs, work with its different storage solutions, and make your application shine.

Who Should Read This Book?

If you are an iOS developer looking to integrate your application with iCloud and to enhance it with data synchronization and backup, this book is for you. This book is also for those who simply want to know more about iCloud and the features it provides to client applications.

Before digging in, you should already know the basics of programming iOS, including proficiency in coding with Objective-C 2.0, working with view controllers, and using common data structures such as arrays and dictionaries. If you don’t normally use them, I also suggest you refresh your knowledge of Notification Center[1] and Grand Central Dispatch,[2] both of which are used extensively throughout the book.

What’s in This Book?

This book is an introduction to iCloud and how to use its APIs to add synchronization and data backup in your applications. We’ll cover the three main technologies that iCloud supports: key-value storage, document-based storage, and Core Data storage. I will illustrate the use of these APIs by showing how to build a Universal iOS app, Grocery, that keeps track of a shopping list.

How to Read This Book

The book starts with the simplest approach to synchronizing data with iCloud, key-value storage, and ends with the most advanced, Core Data. Unless you have previous experience with iCloud APIs, I suggest you read the book from start to finish and take the time to understand the concepts and techniques of iCloud development as they are introduced. Throughout the book, you will be invited to build and run the Grocery application as it is being developed. You should consider these as “conceptual check points”—opportunities to ask yourself whether you have a clear understanding of what’s been described in the previous sections.

Notes on Formatting

Objective-C is a verbose language. You will find snippets in this book that do not appear to be conventionally formatted, in the way you would expect them to appear in Xcode. That’s because of the lengths of many of the names used in iCloud programming, such as those for the various notifications the service provides. Some of these are lengthy and cannot be broken on two different lines. I have tried as much as possible to preserve Cocoa conventions, but sometimes the size of the page rules.

Online Resources

This book has a companion website at http://www.icloudfordevelopers.com and a mailing list in which news will be announced.

Requirements

In this book we are going to build a real application. You will learn how to set it up and configure it correctly. But it’s not possible to test an iCloud-enabled application on the Device Simulator. This means that to get the most out of the book, you’ll need a pair of real devices, such as an iPhone and an iPad, both with iOS 6 installed and with iCloud correctly configured and enabled.

To test whether your devices are correctly configured for iCloud, fire up the Apple-provided Calendar app, make an entry, and verify that synchronization happens correctly between the devices. Also access http://www.icloud.com to see whether your entry has been propagated to the central iCloud servers.

To develop the application used throughout the book, you will need a Mac with Xcode 4.6.2 installed and updated to develop applications that target iOS 6. We assume that you already have an active developer account and are acquainted with iOS development, Objective-C, Xcode, and Core Data. In case you need some introduction to iOS development, check out iOS SDK Development [AD12] or find plenty of material at the iOS Dev Center: https://developer.apple.com/devcenter/ios/index.action .

Moving On

Now that you have all the pieces, let’s get started. We are going to start slowly, by first introducing the basics of iCloud and showing you how to take advantage of its features in your application. To prepare for work on the Grocery app, you’ll also learn how to prepare the Xcode project for iCloud. Ready, set, go!

Footnotes

[1]

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Notifications/Introduction/introNotifications.html#//apple_ref/doc/uid/10000043-SW1

[2]

https://developer.apple.com/library/mac/#documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html

Copyright © 2013, The Pragmatic Bookshelf.

Chapter 1

Preparing Your Application for iCloud

You have created an attractive application that friends and families can use to jointly manage their shopping lists, to-do lists, and other types of lists. Your customers say they like it, but it lacks two features they’d like to see: backup and synchronization.

If you haven’t yet received such feedback, chances are you will. Apple users expect more from their applications these days because Calendar, Contacts, and many other Apple applications that ship with the latest iPhones, iPads, and Macs can both store their data in the cloud and sync it across multiple devices.

Take Calendar, Apple’s appointment application, for example. If you own two or more Apple devices—an iPhone or iPad or two—and they all run iOS 6 or greater, open Calendar on one of them and enter a new appointment for today. Now, switch to another device, open Calendar, and go to your entries for today. Provided that you have activated iCloud on both devices, you’ll find the very same appointment on the second device that you just entered on the first.

Here’s what happened. When you entered it, your iPhone or iPad pushed the appointment to servers operated by Apple. The Calendar application on the second device was listening for changes to the calendar, found yours, and updated itself. You’ll have the same experience whenever you enter a new contact, save a photo, buy music, and more.[3]

Naturally, you’d like to provide features like this to your own users. Fortunately, Apple has not kept iCloud to itself but opened it to app developers like you and me. Now when you write an iOS application, you’ll be able to use the information in this book to add iCloud support that works on all of Apple’s devices running iOS 5 or greater.[4] Users who install the application on each of their iOS devices will be able to store their data and keep it in sync. And we are talking about any kind of data: properties, configurations, documents, binary files, and even information in a relational database.

In this chapter, you will get acquainted with iCloud, learn how it works, and go over the steps to take to prepare an app to use the service. You’ll learn about the following:

- What iCloud provides and how you can take advantage of it

- How iCloud handles data and synchronizes updates

- How to prepare an iOS project for iCloud

We will also introduce and start work on Grocery, the application that we’re going to build together in this book to flex and show off iCloud’s features (Section 1.3, Introducing the Grocery Application).

By the end of this chapter you will have a clearer idea of the scenarios iCloud supports and the steps needed to start building an iCloud-enabled application. Let’s begin by describing what iCloud does and how it works.

1.1 What Is iCloud?

iCloud is a cloud-based tool that can store data for an application at a central server and synchronize updates served up by the iPhones, iPads, or Macs that use it. For both developers and users, iCloud solves two problems: backup and data synchronization.

For backup, data for an application need only be made to adhere to certain formats and specifications and stored in one or more special folders that iCloud provides. For data synchronization, the application has to listen for iCloud notifications indicating changes have occurred and then, when one is received, resolve any conflicts that exist and update the local data store. You will learn to handle both cases in this book, but in order to understand how iCloud handles its data, you first need to understand how it works under the hood.

1.2 What’s Behind iCloud

From an application’s perspective, iCloud consists of one or more “special folders” whose contents iCloud synchronizes with files stored at a central location. This special folder is called a ubiquity container . An application can have one or more ubiquity containers, each of which is assigned its own unique container ID when you enable an application to use the service. As a user adds or modifies application data, iCloud pushes the changes to a central server, which in turn pushes them to other devices that have signed up to share it. An application doesn’t need to query iCloud for updates to its ubiquity containers but instead simply queues itself as an observer. When notified of new content, the application takes steps to integrate it into its local data stores.

To make this mechanism perform efficiently, the contents of files in a container are broken into chunks . Whenever you change a file in a ubiquity container, the synchronization mechanism pushes the bits that have changed, not the entire file. The same thing happens when an application is notified of changes made on other devices: the application running on your device receives only the bits that have changed and integrates them into the files in its ubiquity container.

The synchronization of data across devices is managed by a background process on each device known as the daemon . The daemon is not under the control of the developer, who is responsible for managing the main thread of a program. The daemon is an independent process, whose job is to detect changes to a resource (for example, a document or database) and send these changes to a central iCloud server. The daemon acts as a sort of middle man to the file system on a device. This is summarized in Figure 1, Architecture of iCloud, which diagrams the flow of data between an application, its containers, and iCloud.

Figure 1. Architecture of iCloud. Each device has a daemon in charge of pushing and receiving changes to and from iCloud. Each application has one or more ubiquity containers.

It will be up to you to write the code that opens and closes a file used by an iCloud-enabled application. Those operations will in turn trigger the read or write procedure that is managed by the daemon. Although this might seem inflexible, such an architecture relieves you of having to manage concurrency. Without the daemon, you would need to implement thread-safe procedures to read, write, and push changes to the cloud, not to mention managing file updates. iCloud takes care of these tasks as well as two others: bandwidth management and conflict resolution.

To optimize its consumption of bandwidth, especially on mobile devices that are battery powered most of the time, iCloud makes use of metadata . When a change occurs on a device, the first thing pushed to iCloud is metadata that describes it. This information includes, for example, the size of the file and the date and time it was modified. Metadata is also sent to iCloud when you work with media such as pictures, videos, or audio recordings. As soon as a save operation completes on such a resource file, a 1KB element pops up on the cloud to serve as a placeholder while the actual file is uploaded.

iCloud also breaks down files into chunks to simplify their push to the cloud when they are updated. Only the modified chunks are sent to iCloud, which saves bandwidth and also makes it easier to resolve conflicts. To detect conflicts between updates, only the modified chunks of a file need to be compared. Changes that don’t conflict are merged with the existing iCloud file, while those that do will trigger notifications so the developer can implement policies to resolve them, which could include asking the user to pick the “right” version.

Changes to the contents of an iCloud-enabled application file are pushed to iCloud as quickly as possible. Such a policy keeps the data on the server fresh. But the way iOS pulls changes from iCloud depends on the characteristics of the host device, such as the quality of the connection (3G, LTE, Wi-Fi) and the status of its battery. In general, changes are pulled when they are “appropriate” and won’t degrade performance. On devices, such as phones with limited battery life, iOS pulls changes only when it needs to, such as when you open or close a document. The use of metadata, however, guarantees that the devices that share the application are synchronized and that an iPad or iPhone are “on the same page,” even if one of them has yet to integrate the most recent changes made to an application file.

To sum up, when you create or change an application file on a device, its metadata (name, creation date, and so on) is pushed immediately to iCloud. When you run the application on another mobile device, that device will be “aware” that new content is available, but the changes will be replicated there only when

- you open the file or

- the daemon decides that downloading the file will not impact the performance of the OS.

Although it’s important to be aware of such policies, you will not need to write “special” code to address them, since the daemon does all the work. If a file is unchanged (for example, it was created on the current device or it was pulled recently from iCloud), its contents will be displayed without delay when you open it. If changes have occurred, the daemon will start downloading the file and notify you when it’s done. We will look more closely at this behavior as we develop our Grocery application.

1.3 Introducing the Grocery Application

To show what’s possible with iCloud, we’re going to build a real application that uses it. I’ll name the app Grocery. Grocery will allow users to share a common grocery list between their devices. Each item in the list will have a name, will include an image (so we can show how to store binary files), and will be assigned to one or more categories (to show how we can work with relational data). When a user creates or modifies an item on one device, it will be replicated on any others that are connected to the same iCloud account.

The application will have two views, as shown in Figure 2, Two views of the Grocery application. The first is a table view that displays the list of grocery items to be bought. This view also lets users add and delete items. The second view will appear whenever the user taps an item in the first view and will display some pertinent details about it, such as its name and an image of the item.

Figure 2. Two views of the Grocery application. The first view shows a list of items, and the second shows a detailed view of a single item.

As we move through the book, we’re going to encounter slightly different versions of this application, but its core will remain the same: two views, one to display the list and one to show the details of each item.

While the Grocery application is a simple one, it’s complex enough for us to learn some important iCloud skills, such as building a data model, reacting to update notifications, detecting and resolving conflicts, and working with relational data.

In the next section, we will focus on the very first steps you’ll need to get started with iCloud.

1.4 Enabling Your Application for iCloud

For any iOS applications, the steps you take to set it up are always pretty much the same: create an application ID, create a provisioning profile, and create an Xcode project. Prior to that, of course, you must have joined Apple’s developer program, paid your fee, and received a developer certificate. To set up a project for iCloud, the steps are the same but with a twist: the application ID must be enabled for iCloud, and the Xcode project must be “entitled” to use iCloud and configured to use one or more ubiquity containers.

Let’s walk through each of these steps using the Grocery app.

Create an iCloud-Enabled Application ID

Every application must have an application ID, whether you want to publish it or simply debug it on a real device, so this is always a mandatory step.

Log in to the iOS provisioning portal as you would for any other application.[5] In the iOS Apps section you’ll find a handy menu you can use to navigate its different parts. To create a new application identifier, click Identifiers and then click the + sign at the top right.

I have entered Grocery as the App ID description, checked the iCloud option, left Team ID selected, and entered com.studiomagnolia.grocery as a bundle ID. I’ve used my own reverse domain identifier, which is mine and personal, so if you try to use it, it will tell you it’s already in use. You will have to create your own ID to run and debug the application on your devices. Once you have entered all the data and checked the iCloud option (as in Figure 3, Configuring the application ID for iCloud), click the Continue button at the bottom.

Figure 3. Configuring the application ID for iCloud. Enter a description for the app ID, check iCloud in the services, keep the team ID as it is, and enter the app ID.

Now that you have an application ID that’s enabled for iCloud, you can use it to create a provisioning profile in order to enable the application to run on your devices.

Create a Provisioning Profile

While you are still in the provisioning portal, create a provisioning profile for our application. You need this in order to couple the application ID with the list of devices entitled to run the application as you develop and test it.

Click Provisioning Profiles in the left sidebar, click Development, then click the + sign at the top left. From the list of options, choose iOS App Development and click the Continue button at the bottom. On the next screen (Figure 4, Creating a provisioning profile), select the application ID that you created in the previous step and click Continue. For the next step, select the certificate to be included in the provisioning profile and click Continue.[6] Finally, select the list of devices on which you want to test the application. Remember that you’ll need at least two to explore iCloud. I’ve added some devices owned by colleagues; be sure to add your own.

Figure 4. Creating a provisioning profile. Here you specify the list of devices on which the application can run.

As a last step, enter a name for the profile and click Generate. This will show you a recap of the provisioning profile. Click the Download button to obtain the profile generated, and double-click it to import it into Xcode. Xcode will fire up, and the profile should appear as one of the provisioning profiles now listed in the Xcode Organizer, as shown in Figure 5, The profile imported in Xcode's organizer.

Figure 5. The profile imported in Xcode’s organizer. When the profile is correctly imported, there is a green icon in the Status column.

Configure a Project for iCloud

Now you are ready to create a project for the Grocery application and get to work. If you haven’t done so already, open Xcode and create a new project using the Master-Detail project template. Name it Grocery, set Device Family to Universal so it will run on all iOS devices, enable automatic reference counting (ARC),[7] and disable all the other options, as in Figure 6, Creating an iCloud-enabled Xcode project.

Figure 6. Creating an iCloud-enabled Xcode project. The configuration of our first project.

To work with iCloud, an application needs to be entitled. Select the project root on the left and then the target, and scroll to the bottom of the summary tab, where you will need to set the iCloud details. Once you enable Entitlements, the fields will be autofilled with your application ID.

Entitlements include information about what the application is entitled to do. As shown in Figure 7, Configuring a project for iCloud, entitlements for an iCloud-enabled application include entries for the following:

Key-value store

Represents the identifier of the key-value store in iCloud. Note that the identifier is the same as the one we’re using for the Grocery ubiquity container. You will learn about key-value data in Chapter 2, Working with Key-Value Data.

Ubiquity containers

Specifies the identifiers of the ubiquity containers whose files can be read from or written to by the application. The container can be shared by more than one application, provided the applications are created by the same team.

Keychain groups

Specifies the keys needed to access keychain data, in case an application manages them. We will not cover this topic in the book.

You can edit any of these entries also by opening the file for the project, which is named grocery.entitlements and is listed in the project root.

Figure 7. Configuring a project for iCloud. Here we define the application’s entitlement to use iCloud.

Now the Grocery project is iCloud-ready. But that’s not quite enough. Unless your users have also enabled their devices for iCloud, the Grocery application won’t be able to use iCloud on them. For that reason, when an application such as Grocery starts up, it’s always best to have it check whether iCloud is available. You will see how that’s done in the next section.

Tip 1

If you have already published an application in the App Store and you want to enhance it by adding iCloud support, I recommend you regenerate the provisioning profile instead of activating iCloud in the existing one. In my experience, synchronization does not work when you just switch iCloud on in an existing profile.

1.5 Checking for iCloud Availability

The first step that an iCloud-enabled application must take on startup is to check whether iCloud is turned on for the host device. The user might not have enabled iCloud, in which case it is important to detect this condition and act to prevent unexpected behaviors or crashes. The code to do this is pretty simple and is usually added to the application:didFinishLaunchingWithOptions: method of the application delegate, as shown in the following snippet:

- (BOOL)application:(UIApplication *)application

didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

{

[self.window makeKeyAndVisible];

id currentToken = [[NSFileManager defaultManager]

ubiquityIdentityToken];

if (currentToken) {

NSLog(@"iCloud access on %@", currentToken);

} else {

NSLog(@"No iCloud access");

}

return YES;

}

Here the key element is the ubiquityIdentityToken method, which returns the token associated with the container ID that we previously set up in the project’s entitlements. A returned value that is not nil means the user has activated iCloud on the device. If iCloud is enabled, when you run the project, the console will print the following:

iCloud access on <e3660e9f 2f283084 c4f5af91 29f707df 6bfb5c7e>

Tip 2

Remember, to test iCloud, you must run the project on a device, not in the simulator.

Once we have verified that iCloud is correctly configured and up and running, we are all set for the next step in developing our application: building a model for the data that the application will use and then storing and retrieving it from iCloud.

1.6 Moving On

In this first chapter, you saw what iCloud can do and how it works under the hood. iCloud uses special ubiquity folders to store data for each application on a device. Developers can read and write to these folders, but it is the responsibility of a background process on the device, known as a daemon, to make sure the contents are in sync.

You were also introduced to the Grocery application that you will develop in the remaining chapters of this book and learned the steps you must take to equip an application for iCloud, which include creating an iCloud-enabled application ID and provisioning profile and then entitling the application to use it. You also learned how to check whether users have enabled iCloud for their devices, a necessary prerequisite to running your app.

As a reference, I have put the Xcode project related to this chapter in the repository attached to this book. It’s in the folder named Grocery-chp1.

In the next chapter, you will learn about the different types of storage iCloud supports and then learn how to store and retrieve data of the simplest kind: key-value pairs.

Storage Guidelines

As of iOS 5, data stored in the Documents folder is automatically backed up on iCloud as part of your application even if the app is not iCloud enabled. Apple suggests to store in Documents only data that is really needed, like the data created by the app that cannot be reproduced.

There is an edge case: you need some files to be permanent on the device, even when storage is low, and you don’t need them to be backed up on iCloud. In this case, you should mark those files with the no-backup flag. Further details are available at https://developer.apple.com/library/ios/#qa/qa1719/ .

Footnotes

[3]

For an overview of how Apple uses iCloud in its own applications, see http://www.apple.com/icloud/features/ . The example of the Calendar app is used just to show a familiar scenario where data synchronization happens. Although I am not sure, it is likely the Calendar app in iOS and Mac OS is not using iCloud API to synchronize.

[4]

While it’s possible to add iCloud support to versions of your application that run on a Mac, we will not cover that topic in this book.

[5]

https://developer.apple.com/account/overview.action

[6]

If you have developed application in the past, you’ll have one certificate for development and one for distribution. Select the one for development. If you don’t have a certificate, you can create one in the Certificates section. If you need more details about certificates, you can check out this page at Apple’s support: https://developer.apple.com/support/technical/certificates/ .

[7]

ARC enables automated memory management at compile time. To know more, see http://developer.apple.com/library/mac/#releasenotes/Objective-C/RN-TransitioningToARC/Introduction/Introduction.html%23//apple_ref/doc/uid/TP40011226 .

Copyright © 2013, The Pragmatic Bookshelf.

Chapter 2

Working with Key-Value Data

In the previous chapter, you learned how to configure an application and its entitlements to work with iCloud and to confirm that a given iOS device is ready for iCloud.

In this chapter, you will learn about the three types of storage that iCloud supports and then learn to use the simplest: key-value storage. To show how key-value pairs can be synced via iCloud, we will build a working prototype of the Grocery application introduced in the previous chapter and use it to store, retrieve, and update its grocery list.

Let’s begin with a quick look at the types of storage supported by iCloud.

2.1 iCloud Storage Types

iCloud provides developers with three ways to store data: key-value storage, document-based storage, and Core Data storage. Document-based storage is the most intuitive. User-generated content—documents, pictures, or other media—is stored in files located in the ubiquity container. The only limit to this kind of storage is the one set by a user’s iCloud account.[8] Day One,[9] a journaling application, uses this approach to replicate a user’s entries on multiple devices. We will explore this approach in Chapter 3, Working with Documents.

Key-value storage is even simpler. You can think of it as a sort of hash table in the cloud, where you can store data, such as preferences, meant to be shared across devices. Interacting with such data is easy: given a key, it’s a matter of getting or setting its corresponding value. An application can store up to 1MB f data in its key-value store. For example, the weather application bundled in iOS exploits this approach to ensure the list of locations on all of a user’s devices is the same.

Core Data is a framework used to model and manage relational data and has been iCloud enabled since the release of iOS 5. With Core Data you can replicate a relational database in the cloud and on other devices. Changes to the database are stored in transaction logs and are propagated to the cloud. As with a document-based scheme, there is no explicit limit to the storage except the one specified in the user’s account. Using iCloud with Core Data is the subject of Chapter 8, Working with Core Data and iCloud.

Given its limit in size, key-value storage is ideal for the synchronization of small data (for example, values in the settings of an application) that would propagate quickly across devices. Whenever you work with files, such as documents or pictures, document-based storage is the best option. If you are dealing with relational data, you can give iCloud-enabled Core Data a shot.

In this chapter, you will explore the use of key-value storage. You will learn how to store items created by users of the Grocery application in a hash table--like structure that is stored locally and then pushed to iCloud. You will see how to store and retrieve such items and how to make the application react to changes in that data as it is broadcast by iCloud.

2.2 Using Key-Value Pairs with iCloud

Dealing with the main class used to interact with iCloud’s key-value storage is similar to working with the NSMutableDictionary class. Both even share some of the same methods, such as setObject:forKey: , which says, in effect, “insert this object and use this key as a reference for future retrieval.” An even more closely related component is the NSUserDefaults class, which you might have used in other applications to persist data on disk. You can think of key-value storage as NSUserDefaults on steroids, where data is both persisted on disk and pushed to iCloud, where it is available for use on your other devices.

The class to use for storing and retrieving key-value pairs for iCloud is the NSUbiquitousKeyValueStore class. Whenever we want to store a key-value pair, we first create a reference to it and then call the setObject:ForKey: method to pass it a key and its value, like so:

NSUbiquitousKeyValueStore* store =

[NSUbiquitousKeyValueStore defaultStore];

[store setObject:someObject forKey:somekey];

To retrieve a key-value pair, we pass the same key to the objectForKey: method.

[store objectForKey:someKey];

Finally, to explicitly save in-memory data to disk and propagate it to iCloud, we call the synchronize method.

[store synchronize];

That’s it. These are the three operations you need to know to use key-value data with iCloud. You don’t need to call synchronize every time you add or change an item. Instead, you can wait until application launch. A call to the method synchronize does not guarantee that changes are pushed to iCloud; it is rather a hint to iCloud that new keys or updated values are available to be synchronized. This means you should not expect new keys or values to be immediately available on other devices right after you call synchronize .

Let’s put this knowledge to work in our Grocery project.

2.3 Using Key-Value Pairs in Grocery

In Chapter 1, Preparing Your Application for iCloud, we designed the Grocery project and wrote code to check whether iCloud is turned on for its host device. Now we are going to use iCloud’s key-value storage to store and retrieve information about the application.[10] As you read through the following example code, notice the repeated use of the NSUbiquitousKeyValueStore class. It’s key to the use of key-value storage but embedded in code that’s needed to manipulate and display the contents of its objects.

But first things first. Although the documentation says to call synchronize when an app launches, I think it’s a good idea to place a call also when the application goes to background. As I said, the method is just a clue, and providing more clues to iCloud does not harm our applications. So, I am going to call this method in applicationDidEnterBackground: . This is triggered whenever a user taps the home button on a device. Since the user closes the application, we can safely assume that the user is not about to enter more information at that moment. It’s a good time to tap on iCloud’s shoulder. Here’s the code to add to the application delegate:

Grocery-chp2/Grocery/SMAppDelegate.m

- (void)applicationDidEnterBackground:(UIApplication *)application

{

NSUbiquitousKeyValueStore* store =

[NSUbiquitousKeyValueStore defaultStore];

[store synchronize];

}

Now let’s work on the code needed to retrieve a grocery list and display it to a user.

As specified in Chapter 1, Preparing Your Application for iCloud, the application will provide users with two views of its data: the first displays a list of grocery items, and the second displays a single item from that list, with the ability to edit the entry.[11]

The quickest way to get started is to use the Xcode Master-Detail project template to generate the starting project: a master view controller to display the grocery list and a detail view controller to display a single item. The template also generates boilerplate code that we can tweak to meet the particular needs of our project. If you like, you can reuse the project generated during the previous chapter. In this chapter, we will focus on the master view controller, since we’re interested only in displaying a list for now; we’ll need the detail view controller in later chapters.

Let’s open the SMMasterViewController.m file. We will put the code to build an array ( _objects ) to populate the table view in the viewDidLoad method. The key-value store includes a handy method called dictionaryRepresentation that returns its contents in the form of a dictionary. To populate our array, we use the keys of that dictionary, as follows:

- (void)viewDidLoad {

[super viewDidLoad];

NSUbiquitousKeyValueStore* store =

[NSUbiquitousKeyValueStore defaultStore];

NSDictionary *d = [store dictionaryRepresentation];

_objects = [NSMutableArray arrayWithArray:[d allKeys]];

UIBarButtonItem *addButton =

[[UIBarButtonItem alloc]

initWithBarButtonSystemItem:UIBarButtonSystemItemAdd

target:self

action:@selector(insertNewObject:)];

self.navigationItem.rightBarButtonItem = addButton;

}

The boilerplate code includes also an add (+) button, which appears in the upper-right corner of the screen shown in Figure 8, Displaying key-value storage items in a list, to allow the insertion of new elements. Each time the button is tapped, a new item is created. Here’s the code for the selector associated with the button:

Grocery-chp2/Grocery/SMMasterViewController.m

- (void)insertNewObject:(id)sender {

NSUUID *itemId = [NSUUID UUID];

NSString *itemIdString = [itemId UUIDString];

NSUbiquitousKeyValueStore* store = [NSUbiquitousKeyValueStore defaultStore];

[store setString:@"Untitled" forKey:itemIdString];

[store synchronize];

NSDictionary *d = [store dictionaryRepresentation];

_objects = [NSMutableArray arrayWithArray:[d allKeys]];

[self.tableView reloadData];

}

When invoked, the insertNewObject: method creates a new item, assigns it a unique identifier, and sets its default value to Untitled. Then it saves the new item, repopulates the array, and triggers a refresh of the table view.[12]

Now we need to write the code to populate each cell of the table view. This happens in tableView:cellForRowAtIndexPath: , as follows:

Grocery-chp2/Grocery/SMMasterViewController.m

- (UITableViewCell *)tableView:(UITableView *)tableView

cellForRowAtIndexPath:(NSIndexPath *)indexPath {

static NSString *CellIdentifier = @"Cell";

NSString *itemKey = [_objects objectAtIndex:indexPath.row];

NSUbiquitousKeyValueStore* store =

[NSUbiquitousKeyValueStore defaultStore];

NSString *item = [store objectForKey:itemKey];

UITableViewCell *cell =

[tableView dequeueReusableCellWithIdentifier:CellIdentifier];

if (cell == nil) {

cell = [[UITableViewCell alloc]

initWithStyle:UITableViewCellStyleSubtitle

reuseIdentifier:CellIdentifier];

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;

}

}

cell.textLabel.text = item;

cell.detailTextLabel.text = itemKey;

return cell;

}

In the preceding code, we extract the key corresponding to each cell from the list of objects populating the table view, and we use it to retrieve the value of the item it references. Then we display the key-value pair. Notice that we are using a cell of style UITableViewCellStyleSubtitle so that we can show both the key and the value in the cell.

We can now run the application to see whether it works correctly. This is the first time we’ll see something working on iCloud outside of the console. Compile and run the application on one of your devices and add a few items by tapping the + button. You should see something like in Figure 8, Displaying key-value storage items in a list.

Figure 8. Displaying key-value storage items in a list. The items in the list displayed here are first saved in key-value storage and then retrieved for display in a table view.

Now connect the other device to the Mac and compile and run the application. You won’t see any of the items we entered on the first device. Why not? Because although iCloud is trying to tell you there is something new in the list, you are not listening. In the next section, we will fix this.

2.4 Reacting to Changes in iCloud

One of the most important features of iCloud is notifications , messages sent to observing objects that provide information about an event. You can code any iOS application to listen for such messages, and that’s what you need to do to know when something in the key-value store of an application has changed.

Each type of iCloud storage provides its own notifications. In the case of key-value storage, the one to observe is NSUbiquitousKeyValueStoreDidChangeExternallyNotification. This notification is triggered whenever the server side of iCloud has some news for us. To hook up with that, you use the NSNotificationCenter class[13] and specifically its addObserver:selector:name:object: method, as follows:

[[NSNotificationCenter defaultCenter] addObserver:self

selector:@selector(kvsDidChange:)

name:NSUbiquitousKeyValueStoreDidChangeExternallyNotification

object:nil];

[store synchronize];

Here what this code says: “Whenever you are notified of a change in the key-value storage from iCloud, trigger the selector kvsDidChange: .” After setting up the observer, you should call synchronize to detect whether yet another application has made changes to the key-value store.

These modifications require you to refactor the viewDidLoad as follows:

Grocery-chp2/Grocery/SMMasterViewController.m

- (void)viewDidLoad

{

[super viewDidLoad];

NSUbiquitousKeyValueStore* store = [NSUbiquitousKeyValueStore defaultStore];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(kvsDidChange:)

name:NSUbiquitousKeyValueStoreDidChangeExternallyNotification

object:nil];

[store synchronize];

NSDictionary *d = [store dictionaryRepresentation];

NSLog(@"d is %@", d);

_objects = [NSMutableArray arrayWithArray:[d allKeys]];

UIBarButtonItem *addButton =

[[UIBarButtonItem alloc]

initWithBarButtonSystemItem:UIBarButtonSystemItemAdd

target:self

action:@selector(insertNewObject:)];

self.navigationItem.rightBarButtonItem = addButton;

}

The selector, kvsDidChange: , has two tasks to perform: first to update the current list of items and then to refresh the table view.

Grocery-chp2/Grocery/SMMasterViewController.m

- (void) kvsDidChange:(NSNotification *) notification {

NSDictionary *userInfo = [notification userInfo];

NSLog(@"userInfo %@", userInfo)

NSArray *changedKeys =

[userInfo objectForKey:NSUbiquitousKeyValueStoreChangedKeysKey];

NSLog(@"kvs changed remotely %@", changedKeys);

NSUbiquitousKeyValueStore* store = [NSUbiquitousKeyValueStore defaultStore];

NSDictionary *d = [store dictionaryRepresentation];

NSLog(@"d is %@", d);

_objects = [NSMutableArray arrayWithArray:[d allKeys]];

[self.tableView reloadData];

}

This method extracts the list of changed keys from the userInfo attached to the notification object, reinitializes the array _objects that populates the table view, and then triggers a reload of the view to display updated information.

Now let’s test the completed application. Run it on one device and tap the + button to add a few items. Tap the home button on your device to put the application in background state and trigger synchronization of its key-value store with iCloud.

Now run the app on another device. You should find the same items that you created on the first device in the table view of the second. Congratulations! You have built your first iCloud-enabled application.

Other Key-Value Storage Notifications

We explained the single most essential notification that you need in order to build a simple key-value application. If you are interested in exploiting all of the key-value storage support that iCloud provides, there are other notifications worth mentioning. For example, NSUbiquitousKeyValueStoreQuotaViolationChange tells you when you have exceeded the quota assigned to your app. You can listen for it to gracefully warn the user about that. Other notifications include NSUbiquitousKeyValueStoreInitialSyncChange and NSUbiquitousKeyValueStoreServerChange. To know more, you can check out the documentation of NSUbiquitousKeyValueStore here: http://developer.apple.com/library/ios/#documentation/Foundation/Reference/NSUbiquitousKeyValueStore_class/Reference/Reference.html#//apple_ref/occ/cl/NSUbiquitousKeyValueStore .

2.5 Key-Value Storage Limitations

Key-value storage is the simplest way to get started with iCloud; with only a few lines of code, you have been able to propagate content between devices. But, key-value storage has its limitations. For example, each application has a limit of 1MB of storage, or a maximum of 1,024 pairs. A key-value store is an appropriate means to share small amounts of data for your app, especially data that does not change frequently, such as preference settings. For example, if you allow users to choose their own background colors, you can reasonably expect that value to change only rarely. For that, a key-value store is the perfect solution.

As for data types, key-value storage supports only five: NSNumber NSString, NSData, NSDate, NSArray, and NSDictionary. If your application stores a large amount of data or complex/custom types, you should turn to one of the other two types of iCloud storage: document-based or Core Data.

2.6 Moving On

In this chapter, I introduced the three types of storage that iCloud supports: key-value storage, document storage, and Core Data.

I focused on the simplest of these, key-value storage, and showed how to build an application where data is propagated across devices as it is created or changed. You learned how to work with the NSUbiquitousKeyValueStore class and its related NSUbiquitousKeyValueStoreDidChangeExternallyNotification notification method. The key steps to take in responding to a notification message are first to listen for one and then, in its associated selector, perform the tasks necessary to update the local key-value storage.[14]

While handy for small amounts of data that change infrequently, key-value storage is not fit for complex data types. It is time to move on to the next level, where you will learn how to store potentially large amounts of data using iCloud’s document-based storage.

Footnotes

[8]

Each user has 5GB for free by default but can upgrade to bigger plans.

[9]

http://dayoneapp.com/

[10]

You’ll find the code for the version used in this chapter in the Grocery-00 folder for the book.

[11]

In Chapter 6, Handling Nontextual Information in a Data Model, you will learn how to add an image to an item.

[12]

You could call synchronize just once, when you close the application or it goes in background. That would work, but to make the propagation of changes faster and avoid data losses, I prefer to save as often as possible. Remember that calling this method does not guarantee the propagation to trigger, because that is up to the operating system.

[13]

If you are not familiar with notifications in Objective-C, here is a “Getting Started” guide from Apple: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Notifications/Introduction/introNotifications.html#//apple_ref/doc/uid/10000043i . I encourage you to read and understand it thoroughly, because notifications are key to working with iCloud and to the examples in this book.

[14]

The code for this chapter is available in the folder named Grocery-chp2.

Copyright © 2013, The Pragmatic Bookshelf.

Chapter 3

Working with Documents

As useful as synchronized key-value pairs can be, most applications must work with text, photos, video, music, or other data that is stored in files (or in Apple’s terminology, documents ).

To support document data, iCloud provides a second type of storage known as document storage. Unlike key-value data, the amount of document storage available to a user is limited only by the quota associated with the user’s iCloud account, and documents can be used to store any type of data an application might require, even Core Data, as we’ll see in Chapter 8, Working with Core Data and iCloud.

In this chapter, we are going to take a close look at the document-based approach to data storage. First you will learn how the interaction between your application files and iCloud is handled by means of a daemon, the background process we explained in Chapter 1, Preparing Your Application for iCloud. Then you will learn how to work with UIDocument, the class that provides an easy way to store and retrieve files so changes are propagated seamlessly to other devices via iCloud. And finally, you’ll modify the Grocery application to store its shopping list items in single files. You’ll start with a single item (in one file) in this chapter. In the following chapter, you’ll see how to use a collection of files to implement a list with more than one item.

3.1 Interacting with iCloud

Building a document-based application means manipulating files in a way that the background process—the daemon —will know how to send and retrieve changes to their content to and from iCloud. As a programmer, you’ll never interact directly with the daemon, and you’ll never have to write code to tell it, say, to “synchronize now.” Instead, whenever your application must read or write to a document, you simply open or close the file using appropriate methods. The daemon handles the locking of the file and determines when it is safe to read or write to it. As the developer, your only tasks are to open and close the file as needed and to declare how to encode or decode its data. These operations are facilitated by document storage’s double queue architecture, shown in Figure 9, The double queue architecture for the open operation.

The queues are threads that run on each device. The first queue is the main thread of the application, the one you can pilot via code and that draws the user interface. The second is the daemon, the background queue operated by iOS, which does all the read, write, and sync operations. This architecture is shared by all three types of iCloud data storage described in Section 2.1, iCloud Storage Types.

To store the grocery items generated by the user as plain files in the ubiquity container, you must learn how to extend the UIDocument class. UIDocument is handy because it already implements most of the functionality you need to interact with iCloud, leaving you with the tasks of mapping document contents into in-memory data structures when the file is opened and “dumping” them when the document is saved. Let’s see what’s required to extend UIDocument.

3.2 Extending the UIDocument Class

The easiest way to get started with document-based storage is to use UIDocument, a class meant to be extended to handle documents. A document is simply a collection of data that can be written to local storage as a single file or package of files (explained in Chapter 5, Wrapping Items in a Single File). UIDocument provides two methods for reading data from a file via the daemon: openWithCompletionHandler and loadFromContents.

To read a file named doc that is an instance of UIDocument, here is the code you write:

[doc openWithCompletionHandler:^(BOOL success) {

// code executed when the open has completed

}]

This simple call triggers a read operation on the background queue, the app’s first point of contact with the daemon. You don’t need to know whether the file is local (already pulled from iCloud) or still on the servers. All this is managed by the daemon, which notifies the main thread when it’s done by calling the code in the block that you specify in openWithCompletionHandler: . As a result, the main thread is never blocked, and the user can continue working with the application while data in the file is retrieved. Of course, if that file is a resource that the application needs to continue, you can block further interaction with the user and display a spinner while the application waits for the file to be loaded.

Once the read operation is complete, the data contained in the file is loaded into the application. This is where you have an opportunity to code your own custom behavior to specify how data contained in a file is to be decoded. The method to override is loadFromContents:ofType:error: , which belongs to UIDocument.

- (BOOL) loadFromContents:(id)contents

ofType:(NSString *)typeName

error:(NSError **)outError {

// decode data here

return YES;

}

loadFromContents:ofType:error: is called when the daemon has completed the read operation in the background.[15] One of its key parameters is contents, which is usually of type NSData; it contains the actual information you need to create your data within the application. This is the place where you decode data and save it in a local variable for future use. This method is called before the completion block specified in openWithCompletionHandler: . Figure 9, The double queue architecture for the open operation shows a diagram of this flow over time.

Figure 9. The double queue architecture for the open operation. This diagram shows the sequence of actions that occur under the hood when you open a file stored in the ubiquity container. The job of the daemon is illustrated in the background queue.

The write procedure is pretty similar, and it is based on the same double queue architecture. The key difference when writing is that you have to convert your document’s contents to NSData. In essence, you have to provide a “snapshot” of the current situation of your document. To explicitly save a document, you can call saveToURL:forSaveOperation:completionHandler: , like so:

[doc  saveToURL:[NSURL ...]

forSaveOperation:UIDocumentChangeDone

completionHandler:^(BOOL success) {

// code run when saving is done

}];

Like the read operation, there is a completion block, triggered to notify that the operation has been completed. When the write is triggered on the background queue, the daemon will ask for a snapshot of the document by calling contentsForType:error: . This is the place where you need to encode the information stored in your local variables and return them, usually as an instance of NSData.

- (id) contentsForType:(NSString *)typeName

error:(NSError **)outError {

// encode data here and return them, usually as NSData

}

Figure 10, The double queue architecture for the save operation shows the flow when saving an instance of UIDocument.

Figure 10. The double queue architecture for the save operation. This diagram shows the sequence of actions that occur under the hood when you save a file stored in the ubiquity container. The job of the daemon is illustrated in the background queue.

You can also work with a collection of files by storing them in a file package. Like an app file, used to wrap iOS and Mac OS applications, a package is a directory that contains one or more files but is treated as a single file. I will provide more details in Section 5.1, Working with File Packages, where I’ll use a package to store the grocery items.

In iCloud-enabled applications there is no need to explicitly call a save method, because UIDocument implements a save-less model. This means that the operating system saves data automatically at intervals. There is a method of UIDocument called hasUnsavedChanges , which returns whether an instance has been modified. When the return value is YES, the save procedure is triggered. There are two ways to influence the return value of this method.

- Explicitly call updateChangeCount:

- Use the undo manager , which enables quickly implementing undo and redo changes on a document

Undo Manager

UIDocument has a built-in undo manager. This enables to you implement undo and redo functionality when, for example, a user edits a document. You can access the undo manager of a UIDocument via the property undoManager . This returns an instance of NSUndoManager, which has helper methods to allow the implementation of undo and redo functionalities. If you use an undo manager, you do not need to call updateChangeCount: . For more details about the undo manager, visit this link: http://developer.apple.com/library/ios/#documentation/DataManagement/Conceptual/DocumentBasedAppPGiOS/ChangeTrackingUndo/ChangeTrackingUndo.html#//apple_ref/doc/uid/TP40011149-CH5-SW1 .

Either method will tell the daemon that something has changed and that it should start the save procedure.

Notice that in either case, data may not be pushed immediately to iCloud and in turn to other devices. The calls to these methods are just “hints” to the background queue. The daemon tries to push metadata as soon as possible, whereas actual data is pulled by the cloud when appropriate, depending, for example, on the type of device and the quality of the connection.

Summing up, when we subclass UIDocument, we need to override the following two methods:

- loadFromContents:ofType:error:

- contentsForType:error:

The first method is called when the file is opened and allows the developer to “decode” the information and store it in an object or a property. The second is called when the file is saved and requires the developer to create a sort of “screenshot” of the current information held in the object to be written in the iCloud container.

Now that you’ve mastered the basics of extending a UIDocument, let’s move on to learn how to model a single grocery item, which will become the building block of our Grocery application.

3.3 Modeling a Grocery Item as a UIDocument

I’ll begin by creating the grocery list item. The data model for the item consists of its name and nothing else. To implement the model, I will create a UIDocument with a single property of type NSString to store the item name (lettuce, paper towels, and so on) as a string.

Let’s start building the model grocery item, which I’ll name SMGroceryItem. First open Xcode and create a new project using the Master-Detail project template. Name it Grocery. Choose Universal as the device family, and be sure to enable ARC. Assign the project your ID, and configure it for iCloud as explained in Section 1.4, Enabling Your Application for iCloud. Add code to check iCloud availability (Section 1.5, Checking for iCloud Availability) in the application:didFinishLaunchingWithOptions: method.[16]

Now add a subclass of UIDocument to the project and name it SMGroceryItem. Add a single itemName property of type NSString to the class, which will be used to store a textual description of the item. Here’s the completed header file, SMGroceryItem.h:

Grocery-chp3/Grocery/SMGroceryItem.h

@interface SMGroceryItem : UIDocument

@property (nonatomic, strong) NSString* itemName;

@end

Now open the implementation file named SMGroceryItem.m and override the two UIDocument methods, as we discussed in the previous section. Here’s the code:

Grocery-chp3/Grocery/SMGroceryItem.m

#import "SMGroceryItem.h"

@implementation SMGroceryItem

// called when the application reads data from the file

- (BOOL) loadFromContents:(id)contents

ofType:(NSString *)typeName

error:(NSError **)outError {

if ([contents length] > 0) {

self.itemName = [[NSString alloc] initWithBytes:[contents bytes]

length:[contents length]

encoding:NSUTF8StringEncoding];

} else {

self.itemName = @"Unnamed item";

}

return YES;

}

// called when the app (auto)saves the content to the file

- (id) contentsForType:(NSString *)typeName

error:(NSError **)outError {

if ([self.itemName length] == 0) {

self.itemName = @"Unnamed item";

}

return [NSData dataWithBytes:[self.itemName UTF8String]

length:[self.itemName length]];

}

@end

In the first method, loadFromContents:ofType:error: , where data is read, I transform the contents received by the daemon into a string, which I’ll save in the instance variable self.itemName. This essentially maps the contents stored in the file to an in-memory data structure, a property of a class in this case.

In the second method, contentsForType:error: , where data is saved, the string is converted to an NSData object. In either case, I check whether the variable is empty and I assign a default value, which might be needed when the document is created the first time. This is all you need to create a model for a grocery item. Crazy simple, huh?

Summing up, there is a simple data structure in the form of a string. Whenever you read, you update the value of the string. Whenever you save, you dump the string into an NSData instance that iCloud will store in the ubiquity container.

You should now feel comfortable with the simple data model for our Grocery app. Let’s now move on to the next phase: displaying a grocery item’s content in a table view.

3.4 Displaying a Grocery Item

With the Grocery project still open, you can now add the ability to open a file and show its contents in a user interface, in particular in the SMMasterViewController. There is quite a lot of code to write and illustrate. So far, we have just a model that allows us to encode and decode information, but we still don’t know how to look for a file in the ubiquity container and show its content in the user interface. To keep things simple, I will show how to build an application that can handle just one grocery item, stored in a single file. I will explain how to extend it by adding multiple items and different resources (for example images) in Chapter 5, Wrapping Items in a Single File. The flow of the application is as follows:

1. Set up a query in viewDidLoad to look for a specific file and add a notification observer.

2. Manage the notification, stop the query, and call the method to load data.

3. Cycle through the returned data and build corresponding instances of SMGroceryItem (just one in this case). If the item does not exist, create it (with the static name grocery.gro defined earlier) and then open it. When the file is open, add the item to the array populating the table view and call reloadData .

All this code will be added to SMMasterViewController. Let’s build what we need one step at a time.

Set Up a Query

Import SMGroceryItem.h and add a new property of class NSMetadataQuery. This is the class that enables looking for files. After these additions, the header file will look like this:

Grocery-chp3/Grocery/SMMasterViewController.h

#import <UIKit/UIKit.h>

#import "SMGroceryItem.h"

@class SMDetailViewController;

@interface SMMasterViewController : UITableViewController

@property (strong, nonatomic) SMDetailViewController *detailViewController;

- (void) loadGrocery;

@end

In the corresponding implementation file, define a constant for the filename grocery.gro,[17] and add a helper method called loadData: to load information from the query.

Grocery-chp3/Grocery/SMMasterViewController.m

#import "SMMasterViewController.h"

#import "SMDetailViewController.h"

#define kFILENAME @"grocery.gro"

@interface SMMasterViewController () {

NSMutableArray *_objects;

NSMetadataQuery *_query;

}

- (void) loadData:(NSMetadataQuery *)query;

@end

@implementation SMMasterViewController

In viewDidLoad , we add two lines to initialize the array of objects populating the table, and we call loadGrocery .

Grocery-chp3/Grocery/SMMasterViewController.m

- (void)viewDidLoad

{

[super viewDidLoad];

UIBarButtonItem *addButton =

[[UIBarButtonItem alloc]

initWithBarButtonSystemItem:UIBarButtonSystemItemAdd

target:self

action:@selector(insertNewObject:)];

self.navigationItem.rightBarButtonItem = addButton;

_objects = [[NSMutableArray alloc] init];

[self loadGrocery];

}

Let’s take a closer look at the definition of loadGrocery . An instance of NSMetadataQuery is our discovery tool, which allows us to define the scope of a search (in our case within the ubiquity container) and the criteria to match. If you have ever worked with the Spotlight API on Mac OS X, you’ll be familiar with this code.[18] Each query contains a predicate, which defines what we are looking for. In our case, we will look for a filename. Before running the query, we set up a notification to receive a message when the query returns its results, as shown in the following method definition:

Grocery-chp3/Grocery/SMMasterViewController.m

- (void) loadGrocery {

_query = [[NSMetadataQuery alloc] init];

[_query setSearchScopes:[NSArray arrayWithObject:

NSMetadataQueryUbiquitousDocumentsScope]];

NSPredicate *pred = [NSPredicate predicateWithFormat:@"%K == %@",

NSMetadataItemFSNameKey,

kFILENAME];

[_query setPredicate:pred];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(queryDidFinishGathering:)

name:NSMetadataQueryDidFinishGatheringNotification

object:_query];

[_query startQuery];

}

The first step in loadGrocery is to initialize the query and set its scope. In this case, we are looking at NSMetadataQueryUbiquitousDocumentsScope , which points to the ubiquity container of the Grocery application. Next we define a predicate to describe the matching criterion of the search. In this case, we are looking for the exact name of a file, so we use the equality operator (==). [19]

Then we set up an observer to receive a notification when the search operation has been completed. As a last step, we run the query.

When we run the application, this code will initialize the query and run it against the ubiquity container. Once the gathering operation has completed, queryDidFinishGathering: will be triggered. Let’s see how it is defined in the next section.

Manage the Query Notification

The selector queryDidFinishGathering: , called when the query returns its results, is defined as follows:

Grocery-chp3/Grocery/SMMasterViewController.m

- (void) queryDidFinishGathering:(NSNotification *) notification {

NSMetadataQuery *query = [notification object];

[query disableUpdates];

[query stopQuery];

[[NSNotificationCenter defaultCenter]

removeObserver:self

name:NSMetadataQueryDidFinishGatheringNotification

object:query];

_query = nil;

[self loadData:query];

}

First, we stop the query; otherwise, it runs indefinitely through the cycle of the application. This step is also important; because of live updates, the result of a query can change while you are processing it. To be specific, disableUpdates prevents live updates, and stopQuery quits the process preserving results already loaded. Second, we remove the observer and trigger the actual loading of the results.

Now we have a query returning results from the ubiquity container. The next step is to write some code to unpack the results of the query and read the content of the returned grocery item.

Load the File’s Contents

The method loadData: will load results as follows:

Grocery-chp3/Grocery/SMMasterViewController.m

- (void) loadData:(NSMetadataQuery *)query {

SMGroceryItem *groceryItem;

if ([query resultCount] == 1) {

NSMetadataItem *queryItem = [query resultAtIndex:0];

NSURL *itemUrl = [queryItem valueForAttribute:NSMetadataItemURLKey];

groceryItem = [[SMGroceryItem alloc] initWithFileURL:itemUrl];

[_objects addObject:groceryItem];

[groceryItem openWithCompletionHandler:^(BOOL success) {

if (success) {

NSLog(@"item opened");

[self.tableView reloadData];

} else {

NSLog(@"failed opening item");

}

}];

}

else {

// Getting iCloud container

NSURL *ubiqContainer = [[NSFileManager defaultManager]

URLForUbiquityContainerIdentifier:nil];

// Building the URL for the new item

NSURL *newItemUrl = [[ubiqContainer

URLByAppendingPathComponent:@"Documents"]

URLByAppendingPathComponent:kFILENAME];

// Creating the new item

groceryItem = [[SMGroceryItem alloc] initWithFileURL:newItemUrl];

// Saving the new item

[groceryItem saveToURL:[groceryItem fileURL]

forSaveOperation:UIDocumentSaveForCreating

completionHandler:^(BOOL success) {

if (success) {

NSLog(@"new item created");

// Opening the new item

[groceryItem openWithCompletionHandler:^(BOOL success) {

NSLog(@"New item opened");

[self.tableView reloadData];

}];

}

}];

[_objects addObject:groceryItem];

}

The query instance is essentially an array of NSMetadataItem instances. Each instance carries a property NSMetadataItemURLKey, which is the URL of our file stored in iCloud. I use that URL to create a new instance of the grocery item and add it to the table’s array. If we do not open the item, we won’t be able to access its properties, such as to display its name in the table view. So, we call openWithCompletionHandler: , and we reload table view data when the item is opened successfully.

If we had just the if part of the method, we won’t see anything showing up in the table view. This is because there is no code creating a file named grocery.gro. That’s why there is an else statement: when the query result has no elements, we create one using the ubiquity container and the constant, and we save it and open it.

Run the App

Now at last we are ready to run our first iCloud-enabled application! Connect the iPhone to your workstation and run it. The first time you run the app, you will notice that the file is created, opened, and shown in the table, as follows:

Figure 11. The Grocery application showing the content of the grocery.gro file. The table view shows the content of the grocery.gro file loaded from iCloud.

Each subsequent time you run it, the file is simply loaded, and its name is displayed in the table view. If you now connect the iPad and run the application, the file will be loaded from the iCloud container and there is no need to create it. To double-check that everything works as planned, you can visit the storage manager on one of your devices. Open the Settings applications and go to iCloud→Storage & Backup. In the Documents & Data section, you will see an item named grocery, as shown in Figure 12, The storage manager. That is exactly the file that has been created in the application.

Figure 12. The storage manager. On each device you can view the content generated by each iCloud-enabled application.

Testing Applications

When you test an application, it’s always best to start “clean.” Delete all data from its iCloud container (go to Settings→iCloud→Documents & Data on your device) and uninstall the app on all of your devices. In our simple example, the item is so small that the propagation to other devices through iCloud servers is almost immediate. In other cases, depending on the size of data to be transferred, you might need to wait a bit more (even a few minutes) before seeing data propagated from one device to the other.

3.5 Moving On

In this chapter, you learned about the double queue architecture on which iCloud is based and how to get started with a document-based application by extending UIDocument. In particular, you learned that UIDocument subclasses need to override two methods: - (BOOL) loadFromContents:ofType:error: and contentsForType:error: . Finally, you learned how to look for a file in the ubiquity container by name, listen for a notification when the search is over, and process the returned data to be shown in a table view. The project for this chapter is in the repository under the name Grocery-chp3.

Now you are acquainted with the way iCloud works and in particular with the document-based approach, which allows you to enrich your applications with the ability to store contents that are kept in sync with iCloud and other devices.

So far, the application can manage just one file but provides no way to edit or delete it. In the next chapter, you will learn how to manage multiple files and see how you can empower the user to create, edit, and delete them.

Footnotes

[15]

The ofType: parameter allows you to specify the uniform type identifier (UTI) . As you will see in Chapter 5, Wrapping Items in a Single File, you can create a custom document file type.

[16]

If you like, you can reuse the project created in Chapter 1, Preparing Your Application for iCloud.

[17]

This is a constant because in this chapter we will deal with just one file, so we store its name right in the code.

[18]

http://developer.apple.com/library/mac/#documentation/Carbon/Conceptual/SpotlightQuery/Concepts/Introduction.html

[19]

If you are not familiar with predicate formats, you can check out Apple’s documentation at https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html .

Copyright © 2013, The Pragmatic Bookshelf.

Chapter 4

Managing Multiple Files and iCloud Notifications

In the previous chapter, you learned how to build a simple document-based iCloud application by extending UIDocument to create a single file and then using NSMetadataQuery to find the file in the ubiquity container and display its content.

But an application that consists of a single file is far from most common, real-world scenarios. Users of the Grocery application, for example, will want to add many items to their lists, and they will want those items to remain up-to-date across all of their devices.

In this chapter, we will explore some simple techniques for creating and managing multiple files and using iCloud notifications to keep them up-to-date. Once you’re familiar with the key features of this approach, I’ll show you how to modify our Grocery app, giving it the ability to handle an open-ended list of items and respond to changes entered by users on different devices. Let’s get started.

4.1 Creating and Managing Multiple Files

For an application to manage multiple files, it must be able to find the ones in the ubiquity container that belong to it and then pull individual files from the collection as needed. A simple technique for accomplishing that is to give every filename the same prefix, such as Item_ and then append to it a unique, randomly generated number. With the addition of a path to the filename, you can create the URL you need in order to find any particular file in the ubiquity container of your application.

You can search for collections of files as well as individual ones using the NSMetadataQuery class that we introduced previously. The technique is based on a search predicate for NSMetadataQuery that makes use of regular expressions to specify the filenames in which you’re interested. I’ll use this method later in the chapter.

To handle additions or deletions to documents or spot changes to individual files, iCloud provides a number of useful notifications. These include NSMetadataQueryDidUpdateNotification and UIDocumentStateChangedNotification. The former is useful for detecting changes to all the files in the ubiquity container of a device, while the latter is a means to detect changes to individual files. I’ll make use of both notifications in this chapter. The basic technique for either one is the same. I first set up an observer to listen for the notification I want to follow. Then I write a selector to respond to a change notice when it arrives.

It’s time to return to the Grocery application for a look at how these various techniques can be used to handle a list of items and to keep them up-to-date regardless of where or when changes occur on a user’s devices.

4.2 Creating and Managing Multiple Grocery Items

In the previous chapter, we built a version of Grocery that can store a single item in its list. In this section, we will modify Grocery to manage an unlimited number of items. We will store each one in a dedicated UIDocument-based file, and to avoid conflicts, we will give each a unique name.

We will start by tweaking the implementation of SMGroceryItem to generate the unique filenames we need. Next we’ll add code to search for filenames by pattern. Finally, we will implement a view to display and edit an item’s details.

When we are finished, the modified application will provide two views, one for the grocery list and one for its items, as shown in Figure 13, Grocery list and grocery item displays.

Figure 13. Grocery list and grocery item displays. The screen on the left lists the items of a grocery list, with each item stored in a separate file. The screen on the right shows detailed information about a single item in the list, in this case, its name: Zucchini.

To implement the next version of the application, you can start from the project created during the previous chapter.

Generating a Unique Filename

In the previous chapter, we used the constant grocery.gro to refer to the single file of a one-item grocery list. Since we now want to manage multiple filenames, we need a unique name for each of them. We are going to generate filenames that consist of two parts: a prefix (Item_), which remains the same for every file and which we will use to restrict a search to a particular set of files, and a name that is unique.

We could use a timestamp for the unique part, but this does not cover the case in which two different items are created at the same moment on two different devices. To avoid such a conflict, we are going to exploit the CFUUIDCreate() function, which will always generate a unique ID.[20] We will put this new functionality in a static method of SMGroceryItem. So, we redefine its header by adding two helper methods: createNewItem and buildUUID .

Grocery-chp4/Grocery/SMGroceryItem.h

@interface SMGroceryItem : UIDocument

@property (nonatomic, strong) NSString* itemName;

+ (SMGroceryItem *) createNewItem;

+ (NSString *)buildUUID;

@end

NSString* const groceryItemUpdated;

Then we implement the two helper methods like this:

Grocery-chp4/Grocery/SMGroceryItem.m

+ (SMGroceryItem *) createNewItem {

NSString *fileName = [NSString stringWithFormat:@"Item_%@",

[SMGroceryItem buildUUID]];

NSURL *ubiqContainer = [[NSFileManager defaultManager]

URLForUbiquityContainerIdentifier:nil];

NSURL *newItemUrl = [[ubiqContainer

URLByAppendingPathComponent:@"Documents"]

URLByAppendingPathComponent:fileName];

return [[SMGroceryItem alloc] initWithFileURL:newItemUrl];

}

+ (NSString *)buildUUID {

CFUUIDRef theUUID = CFUUIDCreate(NULL);

NSString *uuidString =

(__bridge_transfer NSString *)CFUUIDCreateString(NULL, theUUID);

CFRelease(theUUID);

return uuidString;

}

For each new item added to the grocery list, a URL is needed. For the URL to be unique, it has to have a unique filename. The method createNewItem concatenates Item_, the fixed part of the string, with a dynamically generated ID. A filename built this way might look like this: Item_610C4FC7-4EFA-4A49-9440-CD9FCCCBEBCD. This format allows us to search for “all files whose names start with Item_” (as explained in Searching for Grocery Items by Name and Pattern) and to guarantee that each filename is unique.

To create a URL that links to the new item, I concatenate the unique filename with the path to the Documents folder in the ubiquity container. I will pass the URL to the createNewItem method when a new item is created.

Now I have a handy static method that I can call every time we need to create a new item. It’s time to revisit the implementation of SMMasterViewController to create a new item each time the user taps the add button.

Creating a New Grocery Item

The Master-Detail project template that we used to create the project already includes some handy boilerplate code that we can use for creating new items, in particular a method named insertNewObject: that is already associated to the + button implemented by SMMasterViewController. I will refactor this method to create a new item, add it to the list, and display it in the table view. Here’s the code:

Grocery-chp4/Grocery/SMMasterViewController.m

- (void)insertNewObject:(id)sender

{

if (!_objects) {

_objects = [[NSMutableArray alloc] init];

}

SMGroceryItem *groceryItem = [SMGroceryItem createNewItem];

[groceryItem saveToURL:[groceryItem fileURL]

forSaveOperation:UIDocumentSaveForCreating

completionHandler:^(BOOL success) {

if (success) {

NSLog(@"new item created");

// Opening the new item

[groceryItem openWithCompletionHandler:^(BOOL success) {

NSLog(@"New item opened");

[self.tableView reloadData];

}];

}

}];

[_objects addObject:groceryItem];

}

We call createNewItem (as defined in Generating a Unique Filename) to build a new instance of a grocery item. We save it by means of saveToURL:forSaveOperation:completionHandler: and add it to the list of objects populating the table view. In the completion block, we trigger the open operation on the file, and once the file is opened, we refresh the list by calling table’s reloadData .

Run the Application

Now we’re ready to test this bit of code. As before, it’s best to start with a clean slate by first uninstalling the application from each of your devices. When you run the application, you’ll find the single “static” file of the previous chapter is created and appears as the first item in the grocery list. Tapping the add button should now add new items.

After you’ve added some items to the list, restart the application. Notice that none of the new items appears. Only the “static” file remains. This is because the loadGrocery method is coded to look for the grocery.gro file and no others. We need to rewrite the method to look for files whose names start with Item_. That’s the topic of the next section.

Searching for Grocery Items by Name and Pattern

Now that a user can add multiple items to a grocery list, we need a way to find them in the ubiquity container. All that’s required is to modify the search predicate to look for files matching a regular expression. The new implementation of the NSPredicate is as follows:

Grocery-chp4/Grocery/SMMasterViewController.m

NSPredicate *pred = [NSPredicate predicateWithFormat:@"%K like 'Item_*'",

NSMetadataItemFSNameKey];

The new predicate—and, in particular, the regular expression @"%K like ’Item_*’"——tells the query to look for files whose names start with the substring Item_, a simple modification that solves our problem. Now we can search for multiple files. Once the files have been gathered, the queryDidFinishGathering: method get called. We now want to refactor it so that it loads the returned data and restarts the query. The goal is to watch for changes in the ubiquity container and update the list of items accordingly when there is a change. This is the new implementation:

Grocery-chp4/Grocery/SMMasterViewController.m

- (void) queryDidFinishGathering:(NSNotification *) notification {

NSLog(@"queryDidFinishGathering");

[_query stopQuery];

[[NSNotificationCenter defaultCenter]

removeObserver:self

name:NSMetadataQueryDidFinishGatheringNotification

object:_query];

[self loadData:_query];

[_query startQuery];

}

With the queryDidFinishGathering method, we temporarily stop the query, remove the observer (because we need this notification only when the view controller is loaded for the first time), load the returned data, and restart the query again. We will explain why we restart the query in Section 4.3, Managing Updates While an Application Is Running.

The implementation of loadData: from the previous chapter is no longer suitable because it can manage only a single item, whereas the new project must manage a list of items. We can refactor the method to create the new items returned by the query and then push them to the array used to populate the list, as follows:

Grocery-chp4/Grocery/SMMasterViewController.m

- (void) loadData:(NSMetadataQuery *)query {

[_objects removeAllObjects];

NSArray *res = [query results];

for (NSMetadataItem *item in res) {

NSURL *url = [item valueForAttribute:NSMetadataItemURLKey];

SMGroceryItem *groceryItem = [[SMGroceryItem alloc] initWithFileURL:url];

[_objects addObject:groceryItem];

[groceryItem openWithCompletionHandler:^(BOOL success) {

if (success) {

[self.tableView reloadData];

} else {

NSLog(@"failed to open item %@ from iCloud", url);

}

}];

}

}

First we remove all the elements previously shown in the list. Then we cycle over the array of results returned by the query instance, extract the URL, and use it to build the corresponding SMGroceryItem. Finally we call its openWithCompletionHandler: method. Each time a file is opened, the table view is refreshed with the new contents loaded.[21]

Run the App

Now let’s run the application again. Uninstall the app from all the devices, clean the iCloud storage from Settings, connect the device to your Mac, and run the application. The list should be empty. Add a few items. Install and run the application on a second device and wait for a while; the list of items added to the first device should pop up on the second. To double-check that everything is working, check also the storage manager, which should appear as shown in Figure 14, Items in the storage manager.

Figure 14. Items in the storage manager. Each item in the grocery list has a file associated in the ubiquity container.

You’ve taken another step toward developing an application capable of handling a list of items. Now it’s time to make the application more user friendly. Users shouldn’t have to restart the application whenever they want to update their copy of a list. We want to do the work for them by making changes to the list while the application is running. You’ll see how that’s done in the next section.

4.3 Managing Updates While an Application Is Running

In its current state, the Grocery application is limited by the fact that the freshest versions of its items are loaded only when users start it up from scratch. We could add a Refresh button and let the user decide when to update a list, but that shouldn’t be necessary. Plus, what we are aiming for is a seamless user experience, where updates flow between devices without the need for explicit action by users. If a user updates a list on one device, the changes should appear on all of the devices running the application. To achieve this result, we are going to exploit the NSMetadataQueryDidUpdateNotification notification, which is triggered any time the daemon detects a change in the ubiquity container.

Let’s see how we can integrate it into existing code.

Managing Notification Changes Continuously

The first step is to modify loadGrocery so it listens for a notification of type NSMetadataQueryDidUpdateNotification .

Grocery-chp4/Grocery/SMMasterViewController.m

- (void) loadGrocery {

_query = [[NSMetadataQuery alloc] init];

[_query setSearchScopes:[NSArray arrayWithObject:

NSMetadataQueryUbiquitousDocumentsScope]];

NSPredicate *pred = [NSPredicate predicateWithFormat:@"%K like 'Item_*'",

NSMetadataItemFSNameKey];

[_query setPredicate:pred];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(queryDidFinishGathering:)

name:NSMetadataQueryDidFinishGatheringNotification

object:_query];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(queryDidFinishUpdating:)

name:NSMetadataQueryDidUpdateNotification

object:_query];

[_query startQuery];

}

Add a new selector to respond to the notification and name it queryDidFinishUpdating: , defined as follows:

Grocery-chp4/Grocery/SMMasterViewController.m

- (void) queryDidFinishUpdating:(NSNotification *) notification {

NSLog(@"======= queryDidFinishUpdating");

NSMetadataQuery *q = [notification object];

[_query stopQuery];

[self loadData:q];

[_query startQuery];

}

The implementation of the queryDidFinishUpdating: selector is pretty similar to that for the queryDidFinishGathering selector of the previous section: stop the query, load data, and then restart it.

Run the Application

As usual, clean the iCloud storage on each device and uninstall previous versions of the app.

Now add a new item to the list on one of the devices. Wait for a bit, and you should see that item appear on the second device.

Now add an item to the list on the second device and watch for it to appear on the first.

With these few modifications, we have now taken a giant step in the development of the Grocery application. Now, while the application is running, we can display updates as soon as iCloud notifies us there has been a change. However, it’s important to note that in the current implementation the most recently updated version of an item will “win” over others. In other words, if you create an item in the morning on one device and then update it on another in the evening, the evening version (being the most recent one, chronologically) overwrites the contents of the morning version. At the moment, this policy is OK. We will explore this topic in greater detail in Chapter 7, Handling Conflicts.

Still, something is missing from the application. Only the master view listens for iCloud notifications and updates itself accordingly. What happens if the daemon notifies of a change to an item document while the user is displaying and editing it? The answer? Nothing, and I will show you how to manage this case in the next section.

4.4 Editing Grocery Item Content

Throughout this chapter I have focused on the list of grocery items displayed by the master view of the application. But we want the application to provide a detail view as well, one that shows the fields of an item and lets the user edit them. It’s not there yet. In this section, we will build a simple version that shows the content of an item in a text field that the user can edit. While we’re at it, I’ll describe how to code the view to respond to updates made by users on other devices.

Adding a Text Field

To add a text field to the detail view controller (as shown in Figure 13, Grocery list and grocery item displays), we can either edit the XIB file or write some code. We will go for the latter. We will create an instance of UITextField, set its position in the view, and hook it up with some code to read and set its content.

The project wizard has already created some boilerplate code for the SMDetailViewController class that we’ll use, but we need to refactor it a bit. First let’s open SMDetailViewController_iPhone.xib and delete the label automatically placed by the wizard; we don’t need it since it does not allow editing. Do the same in SMDetailViewController_iPad.xib.

Next open SMDetailViewController.h to add a text field and change the type of detailItem to SMGroceryItem. Here’s the result:

Grocery-chp4/Grocery/SMDetailViewController.h

#import <UIKit/UIKit.h>

#import "SMGroceryItem.h"

@interface SMDetailViewController : UIViewController

<UISplitViewControllerDelegate, UITextFieldDelegate>

@property (strong, nonatomic) SMGroceryItem *detailItem;

@property (strong, nonatomic) UITextField *itemNameField;

@end

Now let’s open SMDetailViewController.m to configure the view’s appearance. The method viewDidLoad will be changed to do the following:

- Add a button on the top right to save edits

- Create and configure a text field

- Call the method configureView to set the value of the text field (if any)

Here is the final implementation of viewDidLoad :

Grocery-chp4/Grocery/SMDetailViewController.m

- (void)viewDidLoad

{

[super viewDidLoad];

UIBarButtonItem *saveButton =

[[UIBarButtonItem alloc]

initWithBarButtonSystemItem:UIBarButtonSystemItemSave

target:self

action:@selector(saveItem:)];

self.navigationItem.rightBarButtonItem = saveButton;

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

self.itemNameField = [[UITextField alloc]

initWithFrame:CGRectMake(20, 20, 280, 31)];

} else {

self.itemNameField = [[UITextField alloc]

initWithFrame:CGRectMake(20, 20, 340, 31)];

}

self.itemNameField.borderStyle = UITextBorderStyleRoundedRect;

self.itemNameField.clearButtonMode = UITextFieldViewModeWhileEditing;

self.itemNameField.delegate = self;

[self.view addSubview:self.itemNameField];

[self configureView];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(itemHasChanged:)

name:UIDocumentStateChangedNotification // When a doc is modified

object:nil];

}

The method configureView simply fills the value of the text field with the name of the grocery item.

Grocery-chp4/Grocery/SMDetailViewController.m

- (void)configureView

{

self.itemNameField.text = self.detailItem.itemName;

}

Finally, to avoid potential crashes, let’s define an empty implementation of itemHasChanged: .

- (void) itemHasChanged:(id)sender {

}

Let’s give it a try.

Run the Application

Fire up the application on one of your devices. Tap an item on the list, and a detail view like the one shown in Figure 15, Detail view with text field should appear, with a text field whose value is the string “Unnamed Item.”

Figure 15. Detail view with text field. As the detail view appears, it fills the text field with the content of the document and displays the keyboard.

Inspect another item by tapping the “Grocery list” button at the left of the detail view and then choosing a new item from the list. If you tap the Save button in the detail view, however, the application will crash because we have not yet defined the saveItem: method. We’ll do that in the next section.

Saving Changes to an Item

You already saw how to save the contents of a document in some previous code. The method to call for saving is saveToURL:forSaveOperation:completionHandler: . In this particular case, we need first to set the value of the item with the string, possibly edited by the user, of the text field. Here is the final implementation of the method:

Grocery-chp4/Grocery/SMDetailViewController.m

- (void) saveItem:(id) sender {

self.detailItem.itemName = self.itemNameField.text;

[self.detailItem saveToURL:self.detailItem.fileURL

forSaveOperation:UIDocumentSaveForOverwriting

completionHandler:^(BOOL success) {

if (success) {

NSLog(@"item saved ");

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

[self.navigationController popViewControllerAnimated:YES];

}

}

}];

}

In the first line, we overwrite the old content of the item with the one in the text field. Then we save the item using the UIDocumentSaveForOverwriting constant to overwrite the previous file contents.

Run the Application

We are ready for a fresh run of the application. First, install the latest version on both your test devices. Leave the list of items on display on one of them. On the other, select an item, change its name, and tap the Save button. After a brief wait, the change will appear on the first device, and the list will be refreshed accordingly.

One final step remains. To make the application completely responsive to user changes reported by iCloud, we need to modify the detail view to listen for update notifications and to update the text fields of items when they occur. We’ll deal with that functionality in the next section.

Managing Changes in the Detail View

There is no need for queries to hunt for changes to a single item of the application. iCloud provides a ready-made notification for that purpose: UIDocumentStateChangedNotification. iCloud posts this notification whenever the state of a document changes, and we’ll use it to update the view in the detail controller.

A document can have many states, and I’ll explain them in greater in Section 7.1, Working with Document States and Notifications. For now, we can use UIDocumentStateChangedNotification to tell when an item’s content has changed. The approach to handling iCloud notifications should be familiar to you by now: add an observer and then specify a callback method. We already did that in the viewDidLoad method.

What’s missing is the implementation of the itemHasChanged: selector, as follows:

Grocery-chp4/Grocery/SMDetailViewController.m

- (void) itemHasChanged:(id) sender {

NSLog(@"itemHasChanged");

if (self.detailItem) {

self.detailItem = [sender object];

[self configureView];

}

}

The object delivered by the notification is of class SMGroceryItem, so we simply set it as the new detail item to be displayed and call configureView , which will update the text field.

The final step is to block weird behavior, such as having a value in a document change before our eyes as we are editing it. This could happen with our application because, while a user is editing an item name, it’s entirely possible for a notification to arrive from iCloud and override the value currently being entered by the user. We have already prepared the detail view controller to be a delegate of the UITextField component. To solve the problem, we just add one more method, the textFieldDidBeginEditing: method, defined as follows:

Grocery-chp4/Grocery/SMDetailViewController.m

- (void)textFieldDidBeginEditing:(UITextField *)textField {

[[NSNotificationCenter defaultCenter]

removeObserver:self

name:UIDocumentStateChangedNotification

object:nil];

}

This is called whenever the user starts editing the text field; it suspends any notifications received while the user is actively changing an item’s name and prevents the text field from being updated.

Run the Application

Now the application is really ready for its final test. First, repeat all the tests of the previous section. Then, try the following:

1. Open the application on one device and tap a single item in its list to display it. Don’t tap the field to enter the editing mode.

2. On a second device, open the same item, change the item name, and save it.

3. After a while, you will see the change propagate to the first device.

The Grocery application is now iCloud aware. Both the master and detail views of our list can handle changes that occur while the application is running. Thanks to the rich collection of notifications that iCloud provides, our users can be assured that what they see of any document on any one of their devices is always the latest version.

4.5 Moving On

In this chapter, you learned how to manage multiple items and keep them in sync across devices. The trick to manage a collection of files is to create a unique name for each and to store it in a dedicated file within the ubiquity container. You also learned how to listen for iCloud notifications (in particular NSMetadataQueryDidFinishGatheringNotification and UIDocumentStateChangedNotification) and use them to update either the master or detail view while an application is running. The code for the project is in the repository, located under the folder Grocery-chp4.

Now it’s time to add new kinds of content that a user can store in a grocery list. What about a picture, for example? As we’ll see, that’s easily done. But first we have to look at some new ways to model and store documents. That’s the subject of the next chapter.

Footnotes

[20]

If you are going to target iOS 6+, then you can use the NSUUID class: http://developer.apple.com/library/mac/#documentation/Foundation/Reference/NSUUID_Class/Reference/Reference.html .

[21]

If your table view contains many items, you might want to consider refreshing only part of it. Instead of using reloadData , you could use reloadRowsAtIndexPaths:withRowAnimation: . I am using reloadData to keep the focus on iCloud-related code.

Copyright © 2013, The Pragmatic Bookshelf.

Chapter 5

Wrapping Items in a Single File

In this chapter, I will introduce a new way of managing files. Besides creating one file per item, there is an alternative approach: using a file package. The application that we have developed so far has in fact an issue. As the number of items grows, storing each item in a file of its own clutters the ubiquity container. If you add thirty or more items to the latest version of the Grocery app and then browse its container, you will see what I mean. When the number of items is potentially large, it is good practice to wrap them in a package. Package is the nickname Apple uses for the NSFileWrapper class, an iCloud tool that allows you to create a document bundle. Technically it is a directory. You can store multiple items within an NSFileWrapper and they will appear as a single file in the ubiquity container. You can think of it as a sort of archive file, where content is still separated in items. Much like an archive, one file wrapper can be nested in another, allowing you to create hierarchies of packages as you would files in a file system.

In this chapter, you will learn how to work with the NSFileWrapper class to create a package that contains all the items generated by an application. You will see how to integrate this new component into our architecture and make the changes needed to encode and decode items when they are wrapped and unwrapped.

We will update the Grocery application to adopt this new approach. We’ll package all of the grocery items in a single wrapper, which will appear in the ubiquity container and in the Documents & Data section on the device as a single file.

Before we can implement this plan, we’ll need to rework the data model. We are going to keep all the items created by users in an in-memory array that we can wrap or unwrap whenever we want to write or read data. The array will be in a new class that will implement a different way of encoding and decoding data, because the data model will no longer be a simple string but an array of items. Although the user interface developed in the previous chapter remains unchanged (see Figure 13, Grocery list and grocery item displays), the change to our data model requires us to change the way we load and display data in the user interface. We will do this in the second part of the chapter, Section 5.3, Updating the User Interface.

First you need to learn how to work with packages and the NSFileWrapper class.

5.1 Working with File Packages

A file package is a directory on the file system that is treated as a single document to the final user. Adopting a file package has some advantages. The first is that we don’t need to put sparse data in a single “blob file.” The second has to do with performance: only the changes to chunks of a single file (and not the whole package) are pushed onto iCloud. This means less traffic over the network and a speedier save action. The third has to do with organization. Since packages can be nested, we can keep our data organized in different folders and, to favor even more the speed in read and write actions, keep data that is updated frequently separate from data that is usually more static.

NSFileWrapper is a class meant to work with files and particularly with their attributes. We will use this class to encapsulate in a single file a buffer of data generated by an array, which includes all the items of the application. This is just one way of achieving the goal of having a package containing all the items. An alternative solution is to create a wrapper for each file and, since wrappers can be nested, group them all in a root file wrapper. In our case, we will put two wrappers in the root wrapper: one to store items and one to store images, which we will deal with in Chapter 6, Handling Nontextual Information in a Data Model. The methods to be changed will be contentsForType: error: and loadFromContents:ofType:error: as usual, but first let’s see how to re-model a grocery item.

5.2 Packaging Grocery Items

The basic bricks of the Grocery application are items. Instead of using a single file for each item, we will keep them stored in memory by means of an array and manipulate the array each time an item changes. The new model is illustrated in Figure 16, The structure of the package for the Grocery application.

Figure 16. The structure of the package for the Grocery application. The new data model has now a root document that has a reference to each item of the Grocery application.

Unlike the previous implementation of the application, we need two classes to manage the data model: one to store information about a single item and one to collect items as a list and interact with iCloud. For the first, we will reuse SMGroceryItem, but we will reimplement it, as described in the next section.

New Data Model for Grocery Item

SMGroceryItem will no longer extend UIDocument because it will now be used just to hold data, without directly implementing methods to interact with iCloud. It will become a simple class just to model a single item. Objects in memory cannot be stored directly on disk. Whether you are using iCloud or not, a class that wants to persist data on disk has to implement the NSCoding protocol, which is the basis of serializing objects on disk. The class stores an item’s name as an instance string variable.

Grocery-chp5/Grocery/SMGroceryItem.h

#import <UIKit/UIKit.h>

@interface SMGroceryItem : NSObject <NSCoding>

@property (nonatomic, strong) NSString* itemName;

@end

NSString* const groceryItemUpdated;

The NSCoding protocol requires the implementation of two methods, initWithCoder: and encodeWithCoder: , the first to decode information when deserializing the object and the second to encode data before storing it on disk. The corresponding implementation is as follows:

Grocery-chp5/Grocery/SMGroceryItem.m

#import "SMGroceryItem.h"

NSString* const groceryItemUpdated = @"com.studiomagnolia.grocery.itemUpdated";

@implementation SMGroceryItem

- (id)initWithCoder:(NSCoder *)aDecoder {

if (self = [super init]) {

_itemName = [aDecoder decodeObjectForKey:@"itemName"];

}

return self;

}

- (void)encodeWithCoder:(NSCoder *)aCoder {

[aCoder encodeObject:self.itemName

forKey:@"itemName"];

}

@end

This is all we need at the moment. We will get back to the implementation of SMGroceryItem when we enhance our data model with additional elements, in Chapter 6, Handling Nontextual Information in a Data Model. Let’s move on to the next step: building a class that keeps track of the grocery items, wraps them, and communicates with iCloud.

Managing Grocery Items in a UIDocument

We are adopting a solution where items are stored in-memory in an array and, when needed, encoded and decoded so that the final result is a single file that wraps all the items.

The purpose of our new data model is twofold: keeping a list of all the items (and implementing helper functions to add or remove an item) and dealing with encoding/decoding for iCloud. To implement both features, I will create a new class, called SMGroceryDocument, that will extend UIDocument. Moreover, it will have an instance variable named items and implement a few helpers to manage the array of items. I also set up a notification, which will be needed later, when an item gets modified. Here is the header file:

Grocery-chp5/Grocery/SMGroceryDocument.h

#import <UIKit/UIKit.h>

#import "SMGroceryItem.h"

@interface SMGroceryDocument : UIDocument

@property (nonatomic, strong) NSMutableArray *items;

- (void) addItem:(SMGroceryItem *) groceryitem;

- (void) removeItem:(SMGroceryItem *) groceryitem;

- (NSInteger ) count;

- (SMGroceryItem *)entryAtIndex:(NSUInteger)index;

@end

extern NSString *const SMItemModifiedNotification;

extern NSString *const SMModificationSavedNotification;

Before implementing the class, we also define two names for the notifications that will be needed afterward to update the user interface. We also add two other constants to have a unique reference to the keys needed to encode and decode data in file wrappers. They are defined in the implementation file as follows:

Grocery-chp5/Grocery/SMGroceryDocument.m

#define kItemsKey @"items"

#define kItemsWrapperKey @"items.wra"

NSString *const SMItemModifiedNotification =

@"com.studiomagnolia.itemModified";

NSString *const SMModificationSavedNotification =

@"com.studiomagnolia.modificationSaved";

Still in the implementation file, now we override the initWithFileURL: method to initialize the array and set up the notification.

Grocery-chp5/Grocery/SMGroceryDocument.m

- (id)initWithFileURL:(NSURL *)url {

if ((self = [super initWithFileURL:url])) {

_items = [[NSMutableArray alloc] init];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(itemModified:)

name:SMItemModifiedNotification

object:nil];

}

return self;

}

The notification is needed because each time we modify an item, for example change its name, we will save the modification. This notification will be posted by the class SMDetailViewController, whenever the user taps the Save button. This action will trigger the selector itemModified: , which is defined as follows:

Grocery-chp5/Grocery/SMGroceryDocument.m

- (void) itemModified:(NSNotification *) notification {

[self saveToURL:[self fileURL]

forSaveOperation:UIDocumentSaveForOverwriting

completionHandler:^(BOOL success) {

if (success) {

[[NSNotificationCenter defaultCenter]

postNotificationName:SMModificationSavedNotification

object:nil];

}

}];

}

Here we simply save the current document, overwriting previous values. When the save operation is successful, we post another notification that will update all the items listed in SMMasterViewController.

Wrapping the GroceryItems Array

Now we’ve reached the heart of the class. The last step is to define two methods to encode and decode the wrapper and store information on iCloud. In the previous versions of the application, we have always stored a simple string. In this case, we have an array of SMGroceryItem instances. Let’s start by the encoding phase, overriding the contentsForType:error: method. Here we need to use a class called NSKeyedArchiver, which allows converting objects implementing the NSCoding protocol into NSData. Dollowing are the the steps to encode a wrapper:

1. Create a buffer of data.

2. Initialize an instance of an archiver with the buffer.

3. Use the method encodeObject:forKey: to encode items in a format ready to be stored in a file.

Here is the corresponding code:

Grocery-chp5/Grocery/SMGroceryDocument.m

// create buffer of data

NSMutableData *data = [NSMutableData data];

// initialized archiver

NSKeyedArchiver *arch =

[[NSKeyedArchiver alloc] initForWritingWithMutableData:data]; // encoding

[arch encodeObject:_items forKey:kItemsKey];

[arch finishEncoding];

Now that we have dumped objects in memory into a data buffer, we are ready to create a package and wrap them, which we’ll do using the initRegularFileWithContents: method. We are going to build a root wrapper and then add a child wrapper to store the grocery items. We need this nested structure because in Chapter 6, Handling Nontextual Information in a Data Model we are going to add images to the application and we want to store them in a separate wrapper. Here is the implementation of the method:

Grocery-chp5/Grocery/SMGroceryDocument.m

- (id)contentsForType:(NSString *)typeName error:(NSError **)outError {

NSMutableDictionary *wrappers = [NSMutableDictionary dictionary];

// create buffer of data

NSMutableData *data = [NSMutableData data];

// initialized archiver

NSKeyedArchiver *arch =

[[NSKeyedArchiver alloc] initForWritingWithMutableData:data]; // encoding

[arch encodeObject:_items forKey:kItemsKey];

[arch finishEncoding];

NSFileWrapper *entriesWrapper =

[[NSFileWrapper alloc] initRegularFileWithContents:data];

[wrappers setObject:entriesWrapper

forKey:kItemsWrapperKey];

// here you could add another wrapper for other resources,

// like images

NSFileWrapper *rootWrapper =

[[NSFileWrapper alloc] initDirectoryWithFileWrappers:wrappers];

return rootWrapper;

}

We have created a dictionary to hold all the child wrappers, just one at the moment. We have encoded the items in the array, created a wrapper of the items, added that to the dictionary, and used the dictionary to create the root wrapper.

The decoding phase works the same way but in reverse. From the root wrapper we have to extract the child corresponding to the items (encoded with the key items.wra), extract the data from the wrapper, and use the class NSKeyedUnarchiver to actually unarchive the data. The final method is shown in the following code:

Grocery-chp5/Grocery/SMGroceryDocument.m

- (BOOL)loadFromContents:(id)contents

ofType:(NSString *)typeName

error:(NSError **)outError {

NSFileWrapper *rootWrapper = (NSFileWrapper *)contents;

NSDictionary *children = [rootWrapper fileWrappers];

NSFileWrapper *itemsWrapper = [children objectForKey:kItemsWrapperKey];

NSData *data = [itemsWrapper regularFileContents];

NSKeyedUnarchiver *arch = [[NSKeyedUnarchiver alloc]

initForReadingWithData:data];

_items = [arch decodeObjectForKey:kItemsKey];

return YES;

}

Adding and removing items in SMGroceryDocument will be performed respectively by the methods addItem: and removeItem: . When we populate the table view, we will also need to access items by position, and for this purpose we need the entryAtIndex: . Finally, the table view will need to know the number of items in the array, provided by count . All these four methods are defined as follows:

Grocery-chp5/Grocery/SMGroceryDocument.m

- (void) addItem:(SMGroceryItem *) groceryitem {

[_items addObject:groceryitem];

[self saveToURL:[self fileURL]

forSaveOperation:UIDocumentSaveForOverwriting

completionHandler:^(BOOL success) {

if (success) {

NSLog(@"new item added");

}

}];

}

- (void) removeItem:(SMGroceryItem *) groceryitem {

[_items removeObject:groceryitem];

[self saveToURL:[self fileURL]

forSaveOperation:UIDocumentSaveForOverwriting

completionHandler:^(BOOL success) {

if (success) {

NSLog(@"item deleted");

}

}];

}

- (SMGroceryItem *)entryAtIndex:(NSUInteger)index {

if (index < _items.count) {

return [_items objectAtIndex:index];

} else {

return nil;

}

}

- (NSInteger ) count {

return self.items.count;

}

The new data model is ready. The next step is to update the view controllers to deal with the new model. First we have to configure the new type of document we have created.

Configuring the Grocery Document

A file wrapper is essentially a custom document. To make it work, it is not enough to define the way data is encoded and decoded. We also need to provide some metadata in the project; otherwise, the application won’t work. In this section, we will define a uniform type identifier (UTI) for the Grocery application. Much like a jpg or a doc, our UTI, whose extension is gro, defines a type of file that our application can deal with.

To define a UTI, open the file Grocery-Info.plist under the Supporting Files folder. This already contains a list of metadata related to the application, such as ID, icon, and so on. Add a few more specifiers. With your mouse, hover over the last item on the list and click the add (+) button. This will cause a text field with a drop-down menu of features to appear. Select “Document types,” as shown in Figure 17, The document types specified in info.plist.

Figure 17. The document types specified in info.plist. The autocompletion field shows possible alternatives. Here we chose “Document types.”

Click the arrow to the left to expand the items. An array of dictionaries should display, with only one entry. Open that entry, and you will see two elements: “Document Type Name” and “Handler rank”. The first is a simple descriptor of the UTI, so we can enter Grocery Package and set the second to Owner. Next, we add two more descriptors: “Document is a package or bundle” and “Document Content Type UTIs.” The first is a boolean value set to YES, and the second is an array including the identifiers of the UTIs supported by our application. In this case, we need just one, and I enter com.studiomagnolia.grocery.package, whereas you will use yours. The final result will look like that shown in Figure 18, Declaration of UTI for our NSFileWrapper.

Figure 18. Declaration of UTI for our NSFileWrapper. Structure of the descriptors added to the -info.plist file to declare a UTI.

Declaring a UTI is not enough. We also need to export it. So, we add a new descriptor at the root of the plist file called Exported Type UTIs whose structure is illustrated in Figure 19, Exported UTIs.

Figure 19. Exported UTIs. Structure of the descriptor to declare Grocery’s exported UTIs.

The implementation and configuration of the new data model are now complete. It’s time to update the view controllers to handle data modeled in the new way. This is the topic of the next section.

5.3 Updating the User Interface

Whenever you update a data model, there are almost always changes to be made on the user interface side. Although we did not add any new properties and the data model is “conceptually” the same, the changes made to the storage solution require to tweak the way you access and display data. The changes are needed because you are now working with data temporary stored in memory (the array) and you need to refer to that, instead of a UIDocument, to retrieve and display the content of an item.

The previous implementation was in fact based on a one-file-per-item model, while the new version exploits the functionalities of NSFileWrapper. First we’ll have to review the class SMMasterViewController, which handles the loading of data, in particular loadGrocery and loadData . Then we’ll need to change a few details in the methods related to the table view, particularly:

- tableView:numberOfRowsInSection:

- tableView:cellForRowAtIndexPath:

- tableView:commitEditingStyle:forRowAtIndexPath:

Finally we’ll tweak a few methods in the class SMDetailViewController. Let’s get started with the loading of the new data model.

Loading the New Data Model

Unlike the implementation in Chapter 4, Managing Multiple Files and iCloud Notifications, the list of items is now managed by SMGroceryDocument, so we need to create a variable in SMMasterViewController to hold an instance of that. I call it itemsDocument . This is the modified version of the header file:

Grocery-chp5/Grocery/SMMasterViewController.h

#import <UIKit/UIKit.h>

#import "SMGroceryDocument.h"

@class SMDetailViewController;

@interface SMMasterViewController : UITableViewController

@property (strong, nonatomic) SMDetailViewController *detailViewController;

@property (strong, nonatomic) SMGroceryDocument *itemsDocument;

- (void) loadGrocery;

@end

In the implementation file we add a constant to refer to the wrapper filename, grocery.gro .

Grocery-chp5/Grocery/SMMasterViewController.m

#define kFILENAME @"grocery.gro"

The next step is to change a few details in loadGrocery . In particular, we update the predicate to look for one file, not a collection, and we add a listener for the notification kModificationSaved . This is posted by the document class (as defined in Managing Grocery Items in a UIDocument) each time a save operation is successful, and it is needed to refresh the list of items in the table view. Here is the final implementation of loadGrocery :

Grocery-chp5/Grocery/SMMasterViewController.m

- (void) loadGrocery {

_query = [[NSMetadataQuery alloc] init];

[_query setSearchScopes:[NSArray arrayWithObject:

NSMetadataQueryUbiquitousDocumentsScope]];

NSPredicate *pred = [NSPredicate predicateWithFormat:@"%K == %@",

NSMetadataItemFSNameKey,

kFILENAME];

[_query setPredicate:pred];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(queryDidFinishGathering:)

name:NSMetadataQueryDidFinishGatheringNotification

object:_query];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(queryDidFinishUpdating:)

name:NSMetadataQueryDidUpdateNotification

object:_query];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(modificationSaved)

name:SMModificationSavedNotification

object:nil];

[_query startQuery];

}

The modificationSaved selector simply triggers a reload of the table view, and it is defined as follows:

Grocery-chp5/Grocery/SMMasterViewController.m

- (void) modificationSaved { [_query enableUpdates];

[self.tableView reloadData];

}

Now it’s time to update loadData , the method that actually loads items into the table view. As in the first version of the application, I expect just one result. Here is the partial implementation:

Grocery-chp5/Grocery/SMMasterViewController.m

- (void) loadData:(NSMetadataQuery *)query {

if ([query resultCount] == 1) {

NSMetadataItem *item = [query resultAtIndex:0];

NSURL *url = [item valueForAttribute:NSMetadataItemURLKey];

if (!self.itemsDocument) {

self.itemsDocument = [[SMGroceryDocument alloc] initWithFileURL:url];

}

[self.itemsDocument openWithCompletionHandler:^ (BOOL success) {

if (success) {

NSLog(@"loadData - doc opened from cloud %i", self.itemsDocument.count);

[self.tableView reloadData];

[self.itemsDocument closeWithCompletionHandler:^(BOOL success) {

NSLog(@"doc closed");

}

];

} else {

NSLog(@"failed to open");

} }];

I retrieve the result of the query, extract its URL, and use it to initialize the instance of itemsDocument . Once the instance is created, I open the document. When the opening is successful, I reload the table view and close the document.

If the result of the query is empty, it means the application is run for the first time, so I initialize a new document using the constant defined previously and save it to iCloud. Here is the final implementation of loadData :

Grocery-chp5/Grocery/SMMasterViewController.m

- (void) loadData:(NSMetadataQuery *)query {

if ([query resultCount] == 1) {

NSMetadataItem *item = [query resultAtIndex:0];

NSURL *url = [item valueForAttribute:NSMetadataItemURLKey];

if (!self.itemsDocument) {

self.itemsDocument = [[SMGroceryDocument alloc] initWithFileURL:url];

}

[self.itemsDocument openWithCompletionHandler:^ (BOOL success) {

if (success) {

NSLog(@"loadData - doc opened from cloud %i", self.itemsDocument.count);

[self.tableView reloadData];

[self.itemsDocument closeWithCompletionHandler:^(BOOL success) {

NSLog(@"doc closed");

}

];

} else {

NSLog(@"failed to open");

} }];

} else { // No notes in iCloud

NSURL *ubiqContainer = [[NSFileManager defaultManager]

URLForUbiquityContainerIdentifier:nil];

NSURL *ubiquitousPackage = [[ubiqContainer

URLByAppendingPathComponent:@"Documents"]

URLByAppendingPathComponent:kFILENAME];

SMGroceryDocument *doc = [[SMGroceryDocument alloc]

initWithFileURL:ubiquitousPackage];

self.itemsDocument = doc;

[doc saveToURL:[doc fileURL]

forSaveOperation:UIDocumentSaveForCreating

completionHandler:

^(BOOL success) {

NSLog(@"new document saved to iCloud");

}];

}

}

Data loading is now compatible with the new data model based on a file wrapper. We are not yet ready for a full test because we still need to update the way new items are created and added to the list. This is the topic of the next section.

Creating New Instances of Items

Unlike the previous implementation, an item is no longer stored in a single file but in an array, as follows:

Grocery-chp5/Grocery/SMMasterViewController.m

- (void)insertNewObject:(id)sender {

SMGroceryItem *groceryItem = [[SMGroceryItem alloc] init];

groceryItem.itemName = @"Untitled";

[self.itemsDocument addItem:groceryItem];

[self.tableView reloadData];

}

The new implementation of insertNewObject: creates an empty instance of SMGroceryItem and adds it to the list of items in the SMGroceryDocument document. As a last step, reloadData triggers a reload of the table view.

The table view methods from the previous implementation are still using the old data model, and we need to update them. We will do that in the next section.

Updating the Table View Methods

In this section, we will update all the methods that were previously using the old model and tweak them to correctly display information according to the new data model.

The first step is to tell the table to read the number of items from the array contained in itemsDocument .

Grocery-chp5/Grocery/SMMasterViewController.m

- (NSInteger)tableView:(UITableView *)tableView

numberOfRowsInSection:(NSInteger)section {

return self.itemsDocument.count;

}

Then we change the way that values of labels in cells are set. Here we exploit the method defined previously, called entryAtIndex: :

Grocery-chp5/Grocery/SMMasterViewController.m

- (UITableViewCell *)tableView:(UITableView *)tableView

cellForRowAtIndexPath:(NSIndexPath *)indexPath {

static NSString *CellIdentifier = @"Cell";

UITableViewCell *cell = [tableView

dequeueReusableCellWithIdentifier:CellIdentifier];

if (cell == nil) {

cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault

reuseIdentifier:CellIdentifier];

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;

}

}

SMGroceryItem *groceryItem = [self.itemsDocument entryAtIndex:indexPath.row];

cell.textLabel.text = groceryItem.itemName;

return cell;

}

- (BOOL)tableView:(UITableView *)tableView

canEditRowAtIndexPath:(NSIndexPath *)indexPath

{

// Return NO if you do not want the specified item to be editable.

return NO;

}

- (void)tableView:(UITableView *)tableView

didSelectRowAtIndexPath:(NSIndexPath *)indexPath {

SMGroceryItem *object = [self.itemsDocument entryAtIndex:indexPath.row];

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

self.detailViewController = [[SMDetailViewController alloc]

initWithNibName:@"SMDetailViewController_iPhone"

bundle:nil];

self.detailViewController.detailItem = object;

[self.navigationController pushViewController:self.detailViewController

animated:YES];

} else {

self.detailViewController.detailItem = object;

}

[_query disableUpdates];

}

- (void)tableView:(UITableView *)tableView

commitEditingStyle:(UITableViewCellEditingStyle)editingStyle

forRowAtIndexPath:(NSIndexPath *)indexPath {

if (editingStyle == UITableViewCellEditingStyleDelete) {

SMGroceryItem *i = [self.itemsDocument entryAtIndex:indexPath.row];

if (self.detailViewController.detailItem == i) {

self.detailViewController.detailItem = nil;

}

[self.itemsDocument removeItem:i];

[tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath]

withRowAnimation:UITableViewRowAnimationFade];

}

}

@end

When an item is deleted from the list, we use another helper method, called removeItem: , to update the array and then refresh the table view.

Grocery-chp5/Grocery/SMMasterViewController.m

- (void)tableView:(UITableView *)tableView

commitEditingStyle:(UITableViewCellEditingStyle)editingStyle

forRowAtIndexPath:(NSIndexPath *)indexPath {

if (editingStyle == UITableViewCellEditingStyleDelete) {

SMGroceryItem *i = [self.itemsDocument entryAtIndex:indexPath.row];

if (self.detailViewController.detailItem == i) {

self.detailViewController.detailItem = nil;

}

[self.itemsDocument removeItem:i];

[tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath]

withRowAnimation:UITableViewRowAnimationFade];

}

}

Finally, when an item is selected from the list, we show its details. In this case, we also suspend query updates.

Grocery-chp5/Grocery/SMMasterViewController.m

- (void)tableView:(UITableView *)tableView

didSelectRowAtIndexPath:(NSIndexPath *)indexPath {

SMGroceryItem *object = [self.itemsDocument entryAtIndex:indexPath.row];

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

self.detailViewController = [[SMDetailViewController alloc]

initWithNibName:@"SMDetailViewController_iPhone"

bundle:nil];

self.detailViewController.detailItem = object;

[self.navigationController pushViewController:self.detailViewController

animated:YES];

} else {

self.detailViewController.detailItem = object;

}

[_query disableUpdates];

}

Now you are ready at last to test this new version of our application. You need to just temporarily delete the implementation of saveItem: in SMDetailViewController. Run it on an iPhone to confirm that the file wrapper is created as expected. You should see it logged in the console. To double-check, you can also browse the ubiquity container, where you should see a display like the one shown in Figure 20, File wrapper displayed in the storage manager.

Figure 20. File wrapper displayed in the storage manager. The .2KB grocery file shown on the Documents & Data screen is the one that wraps all the grocery items managed by the application.

Now you can run the application on an iPad and put it through the usual tests. Add items on the list, and watch the changes propagate between your two devices. Don’t try to change the names of the items in the list because that feature is not yet compatible with the new data model. We are going to fix that in the next section.

Updating the Detail View

The last step of the porting operation is to update the SMDetailViewController class to comply with the new data model. In particular, we need to change the saveItem: method as follows:

Grocery-chp5/Grocery/SMDetailViewController.m

- (void) saveItem:(id) sender {

NSLog(@"saveItem %@", self.detailItem);

self.detailItem.itemName = self.itemNameField.text;

[[NSNotificationCenter defaultCenter]

postNotificationName:SMItemModifiedNotification

object:self.detailItem];

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

[self.navigationController popViewControllerAnimated:YES];

} else {

[self.itemNameField resignFirstResponder];

self.itemNameField.text = @"";

}

}

For it work, don’t forget to import SMGroceryDocument.h.

This simply posts the notification that we have defined in Managing Grocery Items in a UIDocument, which will trigger an update to the array with the modified item and save it on disk.

Run the Application

Now you are really ready to test the new version on the application. Install it on two devices and once again put it through the usual tests: add an item, change its name, and then delete it. Watch for the changes to propagate between the two devices.

5.4 Moving On

In this chapter, you learned to use file wrappers to store data in iCloud. Because the contents managed by the application are stored in a single wrapped file, this new technique allows you to build applications that won’t clutter your users’ storage. You also learned how to nest wrappers to create a hierarchical structure that resembles a file system. As is required when you use a wrapper, you learned how to configure a project to accept a custom document type. And finally, you saw how to update view controllers so they can work with the new, wrapper-based data model.

The final code for this chapter is in the folder named Grocery-chp5.

In the next chapter, we will explore a new, related possibility: how to associate an image (or in general other resources) with an item.

Copyright © 2013, The Pragmatic Bookshelf.

Chapter 6

Handling Nontextual Information in a Data Model

In previous chapters you learned how to store a simple list of data items, each consisting of a string of text. But what if we need a more complex data type for each item, one that includes both text and an image or other type of media file?

In this chapter, you will learn how to associate images with items. While I will limit the discussion to images alone, the same techniques can be used with any type of media, including audio and video files. I will make the Grocery application more useful by associating an image to each item. In essence, you will see how to maintain a mapping between two collections—strings and images—and how to encode/decode such an information structure in a package that can to be handled by iCloud. To store the new data model, I will exploit NSFileWrapper again, but it will work with a treelike nested structure of file wrappers, each of which stores one type of data.

After reading this chapter, you will be able to build complex data models that exploit the capabilities of NSFileWrapper to build nested structures to be persisted on disk and propagated to other devices through iCloud.

6.1 Working with Data in Packages

Working with packages is a bit like working with directories and files. In fact, the NSFileWrapper is a representation of a node (either folder or file) in a file system. Unlike the commonly known desktop scenario, where the user can see and act on folders and files, in this case we are using a package to store information. The final user will in fact just see a single file (the root) in the Documents and Data section of their iCloud bucket. It’s up to us, developers, to build the structure of that root file. For example, in this chapter, we will put two subfolders in the root, one to store images and one for strings (names of an item), as in Figure 21, Structure of a package.

Figure 21. Structure of a package. The structure of the package we will build in this chapter.

This is how data is stored on disk. We will also need to map such a structure in-memory so that it’s easier to manipulate data. The technique we will use in this chapter exploits arrays. We will keep two separate arrays, one to hold images and one for names. When we store data from arrays to packages, we will encode them, whereas when we retrieve data from the package to build the in-memory arrays, we will use a decode procedure.

The data model is getting a bit more complex with respect to previous chapters, so whenever I refer to “item” in this chapter, I mean a couple made of a string, representing the name of the grocery item, and an image.

Now that you know the theory for adding images and other media files to an iCloud-enabled application, let’s put it to work in the Grocery application. You can reuse the project generated in the previous chapter.

6.2 Associating Images with Names

To add images to the Grocery app, we will extend the class SMGroceryDocument. Once that’s done, we will tweak the SMMasterViewController class to manage the new data model, and we will modify the SMDetailViewController class to allow the user to pick an image for any item in the list.

The first step is to extend the way we have structured data.

Adding Images to the Grocery Data Model

The item is now a couple made of a name and an image, as in Figure 22, The new structure of an item.

Figure 22. The new structure of an item

Open SMGroceryDocument.h, and define a few more properties and methods. We have added a new NSMutableArray to hold instances of images and a few helper methods to deal with the new structure, which now includes two arrays of data. Here is the final version of the header:[22]

Grocery-chp6/Grocery/SMGroceryDocument.h

#import <UIKit/UIKit.h>

#import "SMGroceryItem.h"

@interface SMGroceryDocument : UIDocument

@property (nonatomic, strong) NSMutableArray *items;

@property (nonatomic, strong) NSMutableArray *images;

- (void) addItem:(SMGroceryItem *) groceryitem;

- (void) removeItemAtIndex:(NSInteger) index;

- (NSInteger ) count;

- (SMGroceryItem *)itemAtIndex:(NSUInteger)index;

- (UIImage *)imageAtIndex:(NSUInteger)index;

@end

extern NSString *const SMItemModifiedNotification;

extern NSString *const SMModificationSavedNotification;

We have a new different method to remove items, removeItemAtIndex: , and there is a helper method to retrieve a picture from the array, imageAtIndex: .

In the implementation file, tweak initWithFileURL: to initialize the new array.

Grocery-chp6/Grocery/SMGroceryDocument.m

- (id)initWithFileURL:(NSURL *)url {

if ((self = [super initWithFileURL:url])) {

_items = [[NSMutableArray alloc] init];

_images = [[NSMutableArray alloc] init];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(itemModified:)

name:SMItemModifiedNotification

object:nil];

}

return self;

}

In this new version, when the user edits the details of an item, we will receive a notification carrying an array of three elements: the index, the string, and the image. This structure is needed to update correctly both the array of names and the images, as illustrated in itemModified: .

Grocery-chp6/Grocery/SMGroceryDocument.m

- (void) itemModified:(NSNotification *) notification {

NSArray *a = [notification object];

SMGroceryItem *item = [_items objectAtIndex:[[a objectAtIndex:0]

intValue]];

item.itemName = [a objectAtIndex:1];

UIImage *image = [a objectAtIndex:2];

[_images setObject:image atIndexedSubscript:[[a objectAtIndex:0]

intValue]];

[self saveToURL:[self fileURL]

forSaveOperation:UIDocumentSaveForOverwriting

completionHandler:^(BOOL success) {

if (success) {

[[NSNotificationCenter defaultCenter]

postNotificationName:SMModificationSavedNotification

object:nil];

}

}];

}

Here we use the index to retrieve the edited instances from the arrays and update them accordingly, before saving the changes via saveToURL:forSaveOperation:completionHandler: .

Next we need a few helper methods to add and delete items from the list. When a new item is added to the list, we add a corresponding image with a default placeholder. When an item is deleted, we simply remove the corresponding image as well. In either case, after updating the items and images arrays, we save the changes on disk. Retrieving elements from arrays is done by index, and the count method will be used to populate correctly the list of items. Here is the implementation of helper methods:

Grocery-chp6/Grocery/SMGroceryDocument.m

- (void) addItem:(SMGroceryItem *) groceryitem {

[_items addObject:groceryitem];

[_images addObject:[UIImage imageNamed:@"placeholder.png"]];

[self saveToURL:[self fileURL]

forSaveOperation:UIDocumentSaveForOverwriting

completionHandler:^(BOOL success) {

if (success) {

NSLog(@"new item added");

}

}];

}

- (void) removeItemAtIndex:(NSInteger) index {

[_items removeObjectAtIndex:index];

[_images removeObjectAtIndex:index];

[self saveToURL:[self fileURL]

forSaveOperation:UIDocumentSaveForOverwriting

completionHandler:^(BOOL success) {

if (success) {

NSLog(@"item deleted");

}

}];

}

- (SMGroceryItem *)itemAtIndex:(NSUInteger)index {

if (index < _items.count) {

return [_items objectAtIndex:index];

} else {

return nil;

}

}

- (UIImage *)imageAtIndex:(NSUInteger)index {

if (index < _images.count) {

return [_images objectAtIndex:index];

} else {

return nil;

}

}

- (NSInteger ) count {

return self.items.count;

}

In addItem: , we use a placeholder image that will display the letter g, as shown in Figure 23, Items with the default image.[23]

Now it’s time to review the core of the new data model, that is, the way we encode and decode information when it’s stored on disk.

Packaging the New Grocery Data Model

As in the previous implementation, we will store data on disk for iCloud replication using an NSFileWrapper. In this new version, we will have two elements to manage: an array of names, represented as strings, and an array of images, represented as binary files. As I mentioned in Managing Grocery Items in a UIDocument, file wrappers can be nested, creating a structure that easily maps onto the hierarchy of a file system. That is exactly what we are going to do now: encoding items and images in two separate wrappers and creating a root wrapper to hold both. This way, data is logically separated, while the user will see just one file in the storage settings. The first step is to define a few additional constants as keys for the wrappers. We place them at the top of SMGroceryDocument.m.

Grocery-chp6/Grocery/SMGroceryDocument.m

#define kItemsKey @"items"

#define kImagesKey @"images"

#define kItemsWrapperKey @"items.wra"

#define kImagesWrapperKey @"images.wra"

Next we move on to the encoding part. We initialize the root file wrapper with a dictionary, which will contain other wrappers (subfolders). In such a dictionary we put two child wrappers that contain, respectively, images and items encoded, as we already know from code. Here is the implementation of contentsForType:error: :

Grocery-chp6/Grocery/SMGroceryDocument.m

- (id)contentsForType:(NSString *)typeName error:(NSError **)outError {

NSMutableDictionary *wrappers = [NSMutableDictionary dictionary];

//Encoding items

NSMutableData *data = [NSMutableData data];

NSKeyedArchiver *arch =

[[NSKeyedArchiver alloc] initForWritingWithMutableData:data];

[arch encodeObject:_items forKey:kItemsKey];

[arch finishEncoding];

NSFileWrapper *entriesWrapper = [[NSFileWrapper alloc]

initRegularFileWithContents:data];

[wrappers setObject:entriesWrapper forKey:kItemsWrapperKey];

//Encoding images

NSMutableData *imageData = [NSMutableData data];

NSKeyedArchiver *imagesArchiver =

[[NSKeyedArchiver alloc] initForWritingWithMutableData:imageData];

[imagesArchiver encodeObject:_images forKey:kImagesKey];

[imagesArchiver finishEncoding];

NSFileWrapper *imagesWrapper = [[NSFileWrapper alloc]

initRegularFileWithContents:imageData];

[wrappers setObject:imagesWrapper forKey:kImagesWrapperKey];

NSLog(@"saving: images are %@", _images); NSFileWrapper *rootWrapper =

[[NSFileWrapper alloc] initDirectoryWithFileWrappers:wrappers];

return rootWrapper;

}

We initialize the dictionary to hold child file wrappers, use an NSKeyedArchiver to encode the arrays that store the names and images, create a file wrapper for each encoded array, and add it to the dictionary. Finally, we use the dictionary to initialize the root wrapper and return it. Notice that this technique opens endless possibilities, in that you could store as many arrays as you need in the same file wrapper. You just need to have a different key for each one.

The decoding part is based on the opposite procedure: extract the children from the root wrapper, and for each child use an NSKeyedUnarchiver to decode data and initialize the instance variables. Here is the loadFromContents:ofType:error: method:

Grocery-chp6/Grocery/SMGroceryDocument.m

- (BOOL)loadFromContents:(id)contents

ofType:(NSString *)typeName

error:(NSError **)outError {

NSFileWrapper *rootWrapper = (NSFileWrapper *)contents;

NSDictionary *children = [rootWrapper fileWrappers];

NSFileWrapper *itemsWrapper = [children objectForKey:kItemsWrapperKey];

NSData *data = [itemsWrapper regularFileContents];

NSKeyedUnarchiver *arch = [[NSKeyedUnarchiver alloc]

initForReadingWithData:data];

_items = [arch decodeObjectForKey:kItemsKey];

NSFileWrapper *imagesWrapper = [children objectForKey:kImagesWrapperKey];

NSData *imagesData = [imagesWrapper regularFileContents];

NSKeyedUnarchiver *imagesUnarchiver = [[NSKeyedUnarchiver alloc]

initForReadingWithData:imagesData];

_images = [imagesUnarchiver decodeObjectForKey:kImagesKey];

NSLog(@"loading: images are %@", _images);

return YES;

}

First I obtain the children from the root, identifying each child by the keyword assigned it during encoding. Then I unarchive each child wrapper and assign it to its corresponding variable.

The new data model is now complete. You’re ready to move on to the user interface, updating list and detail views for the application.

6.3 Updating the User Interface

As often happens, when you change a data model, you need to change the user interface as well. The changes we made in the previous section provide new options for both the list of grocery items and the detail. We are going to modify the grocery list view to display an image next to the name of each item in the list. In the detail view of a grocery item, we are going to let the user assign an image to the item, chosen from a library of images. Until a user makes the assignment, we’ll show a default image of a lowercase g.

To make these changes, we will edit two classes: SMMasterViewController and SMDetailViewController. Let’s start with the first.

Updating the List Controller

In the SMMasterViewController class, we update the methods that interact with the table view data source and delegate. We start with the method responsible for populating the table view, tableView:cellForRowAtIndexPath: .

Grocery-chp6/Grocery/SMMasterViewController.m

- (UITableViewCell *)tableView:(UITableView *)tableView

cellForRowAtIndexPath:(NSIndexPath *)indexPath {

static NSString *CellIdentifier = @"Cell";

UITableViewCell *cell =

[tableView dequeueReusableCellWithIdentifier:CellIdentifier];

if (cell == nil) {

cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault

reuseIdentifier:CellIdentifier];

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;

}

}

SMGroceryItem *groceryItem = [self.itemsDocument itemAtIndex:indexPath.row];

cell.textLabel.text = groceryItem.itemName;

cell.imageView.image = [self.itemsDocument imageAtIndex:indexPath.row];

return cell;

}

- (BOOL)tableView:(UITableView *)tableView

canEditRowAtIndexPath:(NSIndexPath *)indexPath

{

// Return NO if you do not want the specified item to be editable.

return NO;

}

- (void)tableView:(UITableView *)tableView

didSelectRowAtIndexPath:(NSIndexPath *)indexPath {

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

self.detailViewController =

[[SMDetailViewController alloc]

initWithNibName:@"SMDetailViewController_iPhone"

bundle:nil];

self.detailViewController.itemsDocument = self.itemsDocument;

self.detailViewController.selectedItemIndex = indexPath.row;

[self.navigationController pushViewController:self.detailViewController

animated:YES];

} else {

self.detailViewController.itemsDocument = self.itemsDocument;

self.detailViewController.selectedItemIndex = indexPath.row;

}

}

- (void)tableView:(UITableView *)tableView

commitEditingStyle:(UITableViewCellEditingStyle)editingStyle

forRowAtIndexPath:(NSIndexPath *)indexPath {

if (editingStyle == UITableViewCellEditingStyleDelete) {

if (self.detailViewController.selectedItemIndex == indexPath.row) {

self.detailViewController.selectedItemIndex = -1;

}

[self.itemsDocument removeItemAtIndex:indexPath.row];

[tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath]

withRowAnimation:UITableViewRowAnimationFade];

}

}

@end

This code assigns an image to each cell via imageAtIndex: .

The next step is to update the list when an item is deleted.

Grocery-chp6/Grocery/SMMasterViewController.m

- (void)tableView:(UITableView *)tableView

commitEditingStyle:(UITableViewCellEditingStyle)editingStyle

forRowAtIndexPath:(NSIndexPath *)indexPath {

if (editingStyle == UITableViewCellEditingStyleDelete) {

if (self.detailViewController.selectedItemIndex == indexPath.row) {

self.detailViewController.selectedItemIndex = -1;

}

[self.itemsDocument removeItemAtIndex:indexPath.row];

[tableView deleteRowsAtIndexPaths:[NSArray arrayWithObject:indexPath]

withRowAnimation:UITableViewRowAnimationFade];

}

}

In this case, we use the new method removeItemAtIndex: , and we trigger a refresh of the table view.

Finally, when an item is selected from the list, we pass both the document and the selected index to the created instance of SMDetailViewController.

Grocery-chp6/Grocery/SMMasterViewController.m

- (void)tableView:(UITableView *)tableView

didSelectRowAtIndexPath:(NSIndexPath *)indexPath {

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

self.detailViewController =

[[SMDetailViewController alloc]

initWithNibName:@"SMDetailViewController_iPhone"

bundle:nil];

self.detailViewController.itemsDocument = self.itemsDocument;

self.detailViewController.selectedItemIndex = indexPath.row;

[self.navigationController pushViewController:self.detailViewController

animated:YES];

} else {

self.detailViewController.itemsDocument = self.itemsDocument;

self.detailViewController.selectedItemIndex = indexPath.row;

}

}

This way, the detail view controller has all the information it needs to notify the model when the details of an item have been updated.

The final step is to update the detail controller to take advantage of the new data model and allow users to choose a custom picture for each item.

Updating the Detail Controller

We’ll first update the SMDetailViewController to display data related to the selected item. We add a variable to store the document, the index of the item selected, an image view to display the image, and a UIPopoverController needed for the iPad version to show the list of images to choose from. Here’s the new header file:

Grocery-chp6/Grocery/SMDetailViewController.h

#import <UIKit/UIKit.h>

#import "SMGroceryItem.h"

#import "SMGroceryDocument.h"

@interface SMDetailViewController : UIViewController

<UISplitViewControllerDelegate, UITextFieldDelegate,

UIImagePickerControllerDelegate, UINavigationControllerDelegate> {

}

@property (assign, nonatomic) NSInteger selectedItemIndex;

@property (strong, nonatomic) SMGroceryDocument *itemsDocument;

@property (strong, nonatomic) UITextField *itemNameField;

@property (strong, nonatomic) UIImageView *itemImageView;

@property (strong, nonatomic) UIPopoverController *popoverPickerController;

@end

In the implementation file, we delete the method setDetailItem: , and we define a setter for the index property so that it sets the value and triggers configureView and its corresponding getter.

Grocery-chp6/Grocery/SMDetailViewController.m

- (void) setSelectedItemIndex:(NSInteger)newItemIndex {

if (_selectedItemIndex != newItemIndex) {

_selectedItemIndex = newItemIndex;

}

if (self.masterPopoverController != nil) {

[self.masterPopoverController dismissPopoverAnimated:YES];

}

[self configureView];

}

Then we redefine itemHasChanged: as follows:

Grocery-chp6/Grocery/SMDetailViewController.m

- (void) itemHasChanged:(id) sender {

[self configureView];

}

Next we update configureView to set both the text field and the assigned image of an item selected by a user.

Grocery-chp6/Grocery/SMDetailViewController.m

- (void)configureView {

self.itemNameField.text =

[[self.itemsDocument itemAtIndex:self.selectedItemIndex] itemName];

UIImage *i = [self.itemsDocument imageAtIndex:self.selectedItemIndex];

self.itemImageView.image = i;

}

As we’ve defined it in Section 6.2, Associating Images with Names, the kItemModified notification is expecting an array of three elements whenever an item is modified. The detail controller is the class responsible for generating that notification (and its attached data structure). This work is done by the saveItem: method, as follows:

Grocery-chp6/Grocery/SMDetailViewController.m

- (void) saveItem:(id) sender {

[[NSNotificationCenter defaultCenter]

postNotificationName:SMItemModifiedNotification

object:@[[NSNumber numberWithInteger:self.selectedItemIndex],

self.itemNameField.text,

self.itemImageView.image]];

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

[self.navigationController popViewControllerAnimated:YES];

} else {

[self.itemNameField resignFirstResponder];

self.itemNameField.text = @"";

}

}

The next step is to update viewDidLoad to initialize the instance of UIImageView and add it to the display tree. This component will also trigger a display of a library of images from which a user can choose.[24] Here is the new viewDidLoad: :

Grocery-chp6/Grocery/SMDetailViewController.m

- (void)viewDidLoad

{

[super viewDidLoad];

UIBarButtonItem *saveButton =

[[UIBarButtonItem alloc] initWithBarButtonSystemItem:UIBarButtonSystemItemSave

target:self

action:@selector(saveItem:)];

self.navigationItem.rightBarButtonItem = saveButton;

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

self.itemNameField = [[UITextField alloc]

initWithFrame:CGRectMake(20, 20, 280, 31)];

} else {

self.itemNameField = [[UITextField alloc]

initWithFrame:CGRectMake(20, 20, 340, 31)];

}

self.itemNameField.borderStyle = UITextBorderStyleRoundedRect;

self.itemNameField.clearButtonMode = UITextFieldViewModeWhileEditing;

self.itemNameField.delegate = self;

[self.view addSubview:self.itemNameField];

self.itemImageView = [[UIImageView alloc] initWithFrame:

CGRectMake(20, 60, 50, 50)];

self.itemImageView.userInteractionEnabled = YES;

self.itemImageView.backgroundColor = [UIColor redColor];

[self.view addSubview:self.itemImageView];

UITapGestureRecognizer *tapRecognizer =

[[UITapGestureRecognizer alloc] initWithTarget:self

action:@selector(showImagePicker:)];

tapRecognizer.numberOfTapsRequired = 1;

[self.itemImageView addGestureRecognizer:tapRecognizer];

[self configureView];

}

To make the image view interactive, we have assigned it a UITapGestureRecognizer, which triggers the selector showImagePicker: , which will show the user the local library of images.

Grocery-chp6/Grocery/SMDetailViewController.m

- (void) showImagePicker:(id)sender {

UIImagePickerController *picker = [[UIImagePickerController alloc] init];

picker.sourceType = UIImagePickerControllerSourceTypePhotoLibrary;

picker.delegate = self;

if (([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPad)) {

self.popoverPickerController = [[UIPopoverController alloc]

initWithContentViewController:picker];

[self.popoverPickerController

presentPopoverFromRect:self.itemImageView.frame

inView:self.view

permittedArrowDirections:UIPopoverArrowDirectionAny

animated:YES];

} else {

[self presentViewController:picker

animated:YES

completion:nil];

}

}

The image picker is a native component that triggers the delegate’s method imagePickerController:didFinishPickingMediaWithInfoMediaWithInfo: when the user picks an image from the list. This method simply sets the picked image as the new image for the selected item, as follows:

Grocery-chp6/Grocery/SMDetailViewController.m

- (void)imagePickerController:(UIImagePickerController *)picker

didFinishPickingMediaWithInfo:(NSDictionary *)info {

self.itemImageView.image =

[info objectForKey:@"UIImagePickerControllerOriginalImage"];

if (([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPad)) {

[self.popoverPickerController dismissPopoverAnimated:YES];

} else {

[self dismissViewControllerAnimated:YES

completion:nil];

}

}

After the new image is picked, the library view is dismissed or, in the case of the iPad, the pop-over disappears.

Run the Application

You are now ready to test the new version of Grocery. Compile and install the application on two devices and do the usual tests: add an item and change its name and its image. Save the modified item and watch its changes propagate to your other device.[25]

Figure 24, A grocery item with an image associated shows a list of grocery items.

Figure 23. Items with the default image. A list of items displaying the default image.

Figure 24, A grocery item with an image associated shows a detailed view of a grocery item.

Figure 24. A grocery item with an image associated. This is the new look of the detail view, showing both the name and the image of a grocery item.

6.4 Moving On

In this chapter, we learned how to add images to an iCloud-enabled application. And you know more about how to build data models that can be nicely persisted on disk by means of nested file wrappers. The user sees just one file, containing all the information managed by the application, nicely packaged in a treelike hierarchy, with a root and children.

You also learned how nested wrappers must be structured in order for them to be properly encoded and decoded for iCloud: child wrappers contain encoded data and are assigned to a dictionary that is then passed to the root file wrapper.

You can find the code for this chapter in the repository. The project is named Grocery-04.

Having learned many of the techniques that are necessary for storing and retrieving data from iCloud, you should find yourself thinking of new ways to add this capability to your own applications. But one major topic remains: conflicts and how to resolve them. We will explore that in the next chapter.

Footnotes

[22]

We could have extended the previous class SMGroceryItem and associated it to an image. I prefer this “double array” model because I think it’s easier to encode and decode it in a package.

[23]

The image I am using is included in the project Grocery-chp6, and it’s called placeholder.png.

[24]

For the sake of simplicity, I show here how to pick an image from the local library of a device. If you’d like, you can use a picture taken with the device camera instead, and you can easily do it using the takePicture method of UIImagePickerController, which is documented here: http://developer.apple.com/library/ios/#documentation/uikit/reference/UIImagePickerController_Class/UIImagePickerController/UIImagePickerController.html .

[25]

If you are testing on 3G and using images taken from high-end devices like an iPhone5 or an iPad3, your images might be pretty big and their propagation might take a while.

Copyright © 2013, The Pragmatic Bookshelf.

Chapter 7

Handling Conflicts

In a shared application, conflicts are inevitable; it’s how the application handles them that matters. In the Grocery application, you have so far dealt with conflicts in an implicit way, applying a policy known as latest wins: the most recently saved version of a grocery item overwrites the contents of the previous one.

Although this policy might work for a single-user application, it’s not the best policy when more than one user has access to the same data. For example, suppose you and your partner edit an item on a shared grocery list more or less simultaneously. Suppose the item is a smoothie. Your partner types banana smoothie and you type pineapple smoothie. Who wins? Which smoothie is the application supposed to store? Although applications cannot solve relationship issues (yet), they can warn you of conflicts and help to resolve them.

In this chapter, you will learn how to detect conflicts. In particular, you will learn where to find information about the state of a UIDocument and which notifications to pay attention to. Then you will learn how to enhance the Grocery application to detect and display potential conflicts before they can occur and build on this approach with a technique for choosing between two or more document versions when they are in conflict. But first you need to understand the concept of document state.

7.1 Working with Document States and Notifications

In iCloud, every UIDocument has state. State determines what you can do with a UIDocument instance, and iCloud provides five that you can use to detect and handle conflicts. You can think of these states and their implications as similar to the green, yellow, and red lights of a traffic signal and the rules of the road we associate with each. A document can be thought of as in a “green” state when it is available and can be accessed, with no other process currently reading or writing to it. A document is in a “yellow” state when something is happening. Perhaps some process is writing to that file, but the file will be available soon. “Red” means “stop” for both cars and documents: a “red” state is one in which you cannot touch the document because some process is working on it.

Here are the five document states that iCloud provides:

UIDocumentStateNormal

This is the “green” or “good to go” state. When a document is normal, you can read or write to it.

UIDocumentStateClosed

This state tells you that there was an error in opening the document or reading data from it.

UIDocumentStateInConflict

A document is in this state when two or more versions exist. This happens, for example, when two users, on different devices, attempt to modify and then save a document within seconds of each other.

UIDocumentStateSavingError

In this state a document cannot be successfully saved, so an attempt to save it will fail.

UIDocumentStateEditingDisabled

This state means that the document is busy, so it is not safe to edit or save its contents.

To head off or deal with potential conflicts, an application needs to know when a document has changed state. For this, we’ll make use of yet another iCloud notification: UIDocumentStateChangedNotification. This notification is triggered whenever an instance of UIDocument changes its state. We encountered this notification briefly in Chapter 4, Managing Multiple Files and iCloud Notifications, but now we are going to exploit it to its full potential.

With states that we can use to detect conflicts and a notification to tell us when a state has changed, we have the basic elements needed to modify the Grocery application. In the next sections, we will explore two techniques for handling conflicts. The first helps prevent conflicts, while the second gives users a way to resolve them when they happen.

7.2 Preventing Conflicts Between Grocery Items

One way to prevent conflicts is to show the user the current state of an iCloud document and to block changes to its content unless it’s in a normal state. We can do this with the use of two document states: UIDocumentStateNormal and UIDocumentStateEditingDisabled. A document enters the latter state while it is being saved. Once the save is complete, the document returns to a normal state. To warn users of a potential conflict while a save operation is underway, we could add color to the names of the grocery items in the list: green for an item in a Normal state and red for one in an EditingDisabled state. That’s where we’ll start.

Since we want to focus exclusively on techniques for resolving conflicts, we are going to start fresh with a highly simplified version of the Grocery application, one that I’ve already written. The name of this version is Grocery-chp7-starter, and you’ll find it in the files for this book. This is a simple document-based application, one in which grocery items are refreshed only when the application is activated. To work with the examples in this chapter, download the application, compile and run the application on one device, add a few items, and then run it on the second device. The changes you made on the first should propagate to the second.

Once you’ve confirmed the application works on your devices, the next step is to set up an observer to watch for UIDocumentStateChangedNotification notifications. Modify the loadGrocery method in SMMasterViewController.m as follows:

Grocery-chp7-end/Grocery/SMMasterViewController.m

- (void) loadGrocery {

_query = [[NSMetadataQuery alloc] init];

[_query setSearchScopes:[NSArray arrayWithObject:

NSMetadataQueryUbiquitousDocumentsScope]];

NSPredicate *pred = [NSPredicate predicateWithFormat:@"%K like 'Item_*'",

NSMetadataItemFSNameKey];

[_query setPredicate:pred];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(queryDidFinishGathering:)

name:NSMetadataQueryDidFinishGatheringNotification

object:_query];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(documentHasChangedState:)

name:UIDocumentStateChangedNotification

object:nil];

[_query startQuery];

}

A UIDocumentStateChangedNotification will trigger a selector that simply refreshes the table view.

Grocery-chp7-end/Grocery/SMMasterViewController.m

- (void)documentHasChangedState:(id)sender {

[self.tableView reloadData];

}

Now it’s time to modify the way items are displayed in the list, changing the colors of the item names to match their state. Let’s first experiment with states to see how they work. Add this simple piece of code to the end of the tableView:cellForRowAtIndexPath: method, right before the return statement:

switch (groceryItem.documentState) {

case UIDocumentStateClosed:

NSLog(@"Closed");

break;

case UIDocumentStateNormal:

NSLog(@"Normal");

break;

case UIDocumentStateInConflict:

NSLog(@"Conflict");

break;

case UIDocumentStateEditingDisabled:

NSLog(@"Editing disabled");

break;

case UIDocumentStateSavingError:

NSLog(@"Saving error");

break;

default:

NSLog(@"Unknown state");

break;

}

This code simply displays the current state of each document in the list to the console. Let’s do a quick check. Install the application on both devices and make sure their lists are the same. For the sake of simplicity, create a list with just one item, which will make the messages in the console even clearer. Now on one device (the one not connected to Xcode for debugging), select an item, change its name, and save it. Now turn to the console, which should report first that the edited document has entered the UIDocumentStateEditingDisabled state and then that it has returned to the UIDocumentStateNormal state, exactly as expected.

Now you are ready to assign colors to the labels in a list to indicate the state of an item. Since we want to prevent possible conflicts, we will also temporarily disable any cell corresponding to a file that’s being saved. Here is a version of the tableView:cellForRowAtIndexPath: method that implements that outcome:

Grocery-chp7-end/Grocery/SMMasterViewController.m

- (UITableViewCell *)tableView:(UITableView *)tableView

cellForRowAtIndexPath:(NSIndexPath *)indexPath {

static NSString *CellIdentifier = @"Cell";

UITableViewCell *cell = [tableView

dequeueReusableCellWithIdentifier:CellIdentifier];

if (cell == nil) {

cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault

reuseIdentifier:CellIdentifier];

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;

}

}

SMGroceryItem *groceryItem = [_objects objectAtIndex:indexPath.row];

cell.textLabel.text = groceryItem.itemName;

switch (groceryItem.documentState) {

case UIDocumentStateClosed:

NSLog(@"Closed");

break;

case UIDocumentStateNormal:

NSLog(@"Normal");

cell.textLabel.textColor = [UIColor blackColor];

cell.userInteractionEnabled = YES;

break;

case UIDocumentStateInConflict:

cell.textLabel.textColor = [UIColor redColor];

cell.userInteractionEnabled = YES;

NSLog(@"Conflict");

break;

case UIDocumentStateEditingDisabled:

cell.textLabel.textColor = [UIColor yellowColor];

cell.userInteractionEnabled = NO;

NSLog(@"Editing disabled");

break;

case UIDocumentStateSavingError:

NSLog(@"Saving error");

break;

default:

NSLog(@"Unknown state");

break;

}

return cell;

}

With this updated method, we have added a color to each cell of the list for the states we’re interested in. We will discuss how to handle conflicts in the next section, Section 7.3, Resolving Conflicts Between Grocery Items, but let’s first add colors to the detail view as well, using the traffic light metaphor discussed at the beginning of the chapter to signal “go,” “caution,” and “stop.” Colors will be displayed in a small box next to the item name.

The first step is to add the box, a 10-point by 10-point square, to the detail view. Open SMDetailViewController.m and add a new UIView as a private property like this:

Grocery-chp7-end/Grocery/SMDetailViewController.m

@property (strong, nonatomic) UIView *documentStateView;

Next redefine viewDidLoad as follows to instantiate the new property documentStateView:

Grocery-chp7-end/Grocery/SMDetailViewController.m

- (void)viewDidLoad {

[super viewDidLoad];

self.documentStateView = [[UIView alloc]

initWithFrame:CGRectMake(5, 30, 10, 10)];

self.documentStateView.backgroundColor = [UIColor clearColor];

[self.view addSubview:self.documentStateView];

UIBarButtonItem *saveButton =

[[UIBarButtonItem alloc]

initWithBarButtonSystemItem:UIBarButtonSystemItemSave

target:self

action:@selector(saveItem:)];

self.navigationItem.rightBarButtonItem = saveButton;

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

self.itemNameField = [[UITextField alloc]

initWithFrame:CGRectMake(20, 20, 280, 31)];

} else {

self.itemNameField = [[UITextField alloc]

initWithFrame:CGRectMake(20, 20, 340, 31)];

}

self.itemNameField.borderStyle = UITextBorderStyleRoundedRect;

self.itemNameField.clearButtonMode = UITextFieldViewModeWhileEditing;

self.itemNameField.delegate = self;

[self.view addSubview:self.itemNameField];

[self configureView];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(configureView)

name:UIDocumentStateChangedNotification

object:nil];

}

Finally, tweak the configureView to color the box according to the state of the document: green for Normal, yellow for EditingDisabled, and red for InConflict.

- (void)configureView {

self.itemNameField.text = self.detailItem.itemName;

switch (self.detailItem.documentState) {

case UIDocumentStateClosed: NSLog(@"Closed");

break;

case UIDocumentStateNormal:

NSLog(@"Normal");

self.documentStateView.backgroundColor = [UIColor greenColor];

break;

case UIDocumentStateInConflict:

NSLog(@"Conflict");

self.documentStateView.backgroundColor = [UIColor redColor];

break;

case UIDocumentStateEditingDisabled:

self.documentStateView.backgroundColor = [UIColor yellowColor];

NSLog(@"Editing disabled");

break;

case UIDocumentStateSavingError:

NSLog(@"Saving error");

break;

default:

break;

}

Now let’s repeat the test you did previously. Run the app on one device, and create a few items. Leave the application open. Now run the app on a second device, select an item, change its name, and save it. On the first device you should observe the cell corresponding to the edited item first turn yellow and then return to black.

The second test is to open an item on the iPhone/iPod device. Then open the same an item on the second device, modify it, and save it. You will notice the color of the square changing in the first device, first to yellow and then back to green.

We have achieved the first of two goals, trying to prevent conflicts by warning users when a document leaves its normal state. Since we can’t prevent them all the time, it’s time to see how to deal with situations in which there are two conflicting versions of a file.

7.3 Resolving Conflicts Between Grocery Items

In iCloud, a conflict is declared when a file exists in two different versions. This can happen in several ways, but here’s one possible scenario. Suppose two users open the same item and change its text description, changing say the name smoothie to banana smoothie on one and pineapple smoothie on the other. Now suppose they each tap the Save button more or less at the same time.[26] The likely result is two conflicting versions of the file, because on the server side iCloud will receive two different values for the same file and will mark that file with a UIDocumentStateInConflict state.

The version of Grocery we’ve been building in this chapter so far is already capable of showing a conflict in its list of items. Let’s try to create that condition. Run the application on each device and confirm that they are in sync. Select the same item on each device, and change its title, entering a different value in its text field. Now tap Save on both devices. After a time, the list will refresh on each device, but now the name of the conflicted item will have the color red, as in Figure 25, Display of an InConflict item on an iPad and Figure 26, Display of an in conflict item on an iPhone.

Figure 25. Display of an InConflict item on an iPad. The red label in this iPad display indicates that two or more versions of the item exist in iCloud storage.

Figure 26. Display of an in conflict item on an iPhone. The red label in this iPhone display indicates that two or more versions of the item exist in iCloud storage.

Moreover, if we tap the item in conflict on either of the devices, we will also see the red square in the detail view.

A state of conflict remains between two or more versions of a document until it is resolved. If, for example, we try to reload the list of items in a conflicted application by restarting the application, the conflicting item will continue to appear in red. This happens because the conflict is persisted in iCloud and remains in effect until someone chooses which is the “right” or “winning” version to save.

The process of choosing the right version is called conflict resolution . It takes three steps to resolve an iCloud conflict.

1. Choosing the “right” version of a file

2. Marking the conflict as resolved

3. Removing the discarded versions of the file

The first step is pretty easy. In the current example, it is just a matter of choosing which smoothie goes into the list. For sake of simplicity, we will go for the following solution: the first device that will send a value for the smoothie and mark the conflict as resolved will be the “winner.” The second step, marking the conflict as resolved, requires us to list every conflicting version of the file by calling the unresolvedConflictVersionsOfItemAtURL: method of the class NSFileVersion. For a given file, there may be more than one, such as if more than two users edit a file at the same time. The following piece of code will extract the list of conflicts and return an array:

NSArray *conflicts = [NSFileVersion

unresolvedConflictVersionsOfItemAtURL:

[self.detailItem fileURL]];

The conflicts array contains instances of NSFileVersion, which we will use to mark the conflict as resolved. If there are no conflicting versions of the file, the array will be empty. If we want to find out which versions are in conflict, we can resort to two static methods belonging to NSFileVersion: currentVersionOfItemAtURL: and otherVersionsOfItemAtURL: . For example, the following piece of code will display the content of each version of the document in the list of conflicting documents:

if (self.detailItem.documentState == UIDocumentStateInConflict) {

NSFileVersion *currentFileVersion =

[NSFileVersion

currentVersionOfItemAtURL:

[self.detailItem fileURL]];

NSArray *otherVersions = [NSFileVersion

otherVersionsOfItemAtURL:

[self.detailItem fileURL]];

SMGroceryItem *i = [[SMGroceryItem alloc]

initWithFileURL:

[currentFileVersion URL]];

[i openWithCompletionHandler:^(BOOL success) {

NSLog(@"current version content is %@", i.itemName);

}];

for (NSFileVersion *c in otherVersions) {

SMGroceryItem *o = [[SMGroceryItem alloc] initWithFileURL:[c URL]];

[o openWithCompletionHandler:^(BOOL success) {

NSLog(@"other version content is %@", o.itemName);

}];

}

}

Depending on which device is connected to the console debugger, we can expect to see log messages like these:

2012-10-08 11:02:46.527 Grocery[351:907]

other version content is Smoothie Banana

2012-10-08 11:02:46.548 Grocery[351:907]

current version content is Smoothie Pineapple

The third step, after marking all the conflicts as resolved, is to remove other versions of the file with the removeOtherVersionsOfItemAtURL: method. Once we have made all three steps, we can save the detail item using the item using the method saveToURL:forSaveOperation:completionHandler: as usual. Let’s see how to modify the current version of SMDetailViewController to integrate such a conflict resolution process.

There is already an observer of UIDocumentStateChangedNotification in place, and we can remove the observer as soon as we catch the notification. We will tweak itemHasChanged: as follows:

Grocery-chp7-end/Grocery/SMDetailViewController.m

- (void) itemHasChanged:(id) sender {

if (self.detailItem) {

self.detailItem = [sender object];

[self configureView];

}

if (self.detailItem.documentState == UIDocumentStateInConflict) {

[[NSNotificationCenter defaultCenter]

removeObserver:self

name:UIDocumentStateChangedNotification

object:nil];

}

}

We update the method configureView to add some log statements that can tell us when there is a conflict.

Grocery-chp7-end/Grocery/SMDetailViewController.m

- (void)configureView {

self.itemNameField.text = self.detailItem.itemName;

switch (self.detailItem.documentState) {

case UIDocumentStateClosed: NSLog(@"Closed");

break;

case UIDocumentStateNormal:

NSLog(@"Normal");

self.documentStateView.backgroundColor = [UIColor greenColor];

break;

case UIDocumentStateInConflict:

NSLog(@"Conflict");

self.documentStateView.backgroundColor = [UIColor redColor];

break;

case UIDocumentStateEditingDisabled:

self.documentStateView.backgroundColor = [UIColor yellowColor];

NSLog(@"Editing disabled");

break;

case UIDocumentStateSavingError:

NSLog(@"Saving error");

break;

default:

break;

}

if (self.detailItem.documentState == UIDocumentStateInConflict) {

NSFileVersion *currentFileVersion = [NSFileVersion

currentVersionOfItemAtURL:

[self.detailItem fileURL]];

NSArray *otherVersions = [NSFileVersion

otherVersionsOfItemAtURL:

[self.detailItem fileURL]];

SMGroceryItem *i = [[SMGroceryItem alloc]

initWithFileURL:

[currentFileVersion URL]];

[i openWithCompletionHandler:^(BOOL success) {

NSLog(@"current version content is %@", i.itemName);

}];

for (NSFileVersion *c in otherVersions) {

SMGroceryItem *o = [[SMGroceryItem alloc] initWithFileURL:[c URL]];

[o openWithCompletionHandler:^(BOOL success) {

NSLog(@"other version content is %@", o.itemName);

}];

}}

}

In saveItem: , we perform the four steps described earlier: set the winning version, mark the conflicts as resolved, remove alternative versions, and save.

Grocery-chp7-end/Grocery/SMDetailViewController.m

- (void) saveItem:(id) sender {

// 1. Setting the winning version

self.detailItem.itemName = self.itemNameField.text;

if (self.detailItem.documentState == UIDocumentStateInConflict) {

NSArray *conflicts = [NSFileVersion

unresolvedConflictVersionsOfItemAtURL:

[self.detailItem fileURL]];

// 2. Marking conflicts as resolved

for (NSFileVersion *conflict in conflicts) {

conflict.resolved = YES;

}

// 3. Removing other versions

NSError *error = nil;

BOOL ok = [NSFileVersion removeOtherVersionsOfItemAtURL:

[self.detailItem fileURL] error:&error];

if (!ok) {

NSLog(@"Can't remove other versions: %@", error);

}

}

[self.detailItem saveToURL:self.detailItem.fileURL

forSaveOperation:UIDocumentSaveForOverwriting

completionHandler:^(BOOL success) {

if (success) {

NSLog(@"item saved ");

if ([[UIDevice currentDevice] userInterfaceIdiom] ==

UIUserInterfaceIdiomPhone) {

[self.navigationController

popViewControllerAnimated:YES];

}

}

}];

}

Now you can test the new application. Run it on both devices. If you did not change anything from the previous run, you should find that the conflict between the two “smoothie” items remains. Select the red item on one device, and you will see in the console the current and alternative versions of the content. Set a new title, or leave the current one, and tap Save. This way, you are picking this title as the winning version of the conflict. The new version will be propagated to iCloud and to the other device running the application.

7.4 Moving On

In this chapter, you learned how to detect conflicts between different versions of the same document and two ways to handle them. You saw that the state of a document can have one of five different values and that using iCloud notifications to find out when a state has changed is the key to handling conflicts. You learned how to prevent conflicts by warning users that a document is in flux and locking it down. You also learned how to resolve a conflict between two or more versions of a file by listing the conflicts, choosing a “correct” version, and removing the rejected version from iCloud.

To use this technique with your own applications, you know how to follow these steps: listen for document changes (UIDocumentStateChangedNotification), compile a list of conflicts when they do occur (unresolvedConflictVersionsOfItemAtURL:), and choose a correct version. Mark the remaining conflicts in the list as solved and remove all other versions of the document ( removeOtherVersionsOfItemAtURL: ). Then call saveToURL:forSaveOperation:completionHandler: as usual.

The code for this chapter is in the folder Grocery-chp7-end.

Now it’s time to move onto the next and final topic: working with relational data and iCloud using Core Data.

Footnotes

[26]

When I say “at the same time,” I mean something “one second or so apart.” Depending on the quality or reliability of the network connection, such a lag will almost always produce a conflict.

Copyright © 2013, The Pragmatic Bookshelf.

Chapter 8

Working with Core Data and iCloud

So far, you’ve learned to work with two types of data in iCloud: key-value pairs and document-based data. While these two approaches work well for many scenarios, sometimes only a relational data store will do. The iOS platform already includes a powerful tool for creating and interacting with relational data, Core Data, and with the release of iOS 5, Core Data is now iCloud enabled. This means that with a properly coded application, users can back up and replicate relational data stored on any iOS device they own.

In this chapter, I will explain how to build an iCloud-enabled application that leverages the capabilities of Core Data. Core Data is the framework that manages the life and persistence of objects on iOS and Mac OS devices.[27] Unlike a database, Core Data doesn’t require you to write SQL queries to store, edit, and retrieve data. Instead, you simply write Objective-C code, exploiting the Core Data APIs responsible for data serialization and storage. Since this book is about readying applications for iCloud, I am going to assume that you already have a working knowledge of Core Data--based applications.[28]

I’ll begin by illustrating a new relational model for our Grocery application. I’ll add a new object—a tag—to its domain, which I’ll use to classify the items in the grocery list. Next I’ll show you how to initialize the “Core Data stack” (data model, context, and coordinator) for iCloud, and I will describe how changes to a device are propagated to others. I’ll show how to respond to change notices sent by iCloud, and, finally, I will describe some approaches for resolving conflicts.

The first step is to get acquainted with the new, relational data model we’ll be using in this chapter. Let’s get started.

8.1 The Relational Model of the Grocery List

So far, we have been dealing with data represented in a “flat” way. In this chapter, I will start fresh with a data model that is conceptually the same as the previous version—a list of items—but now includes tags for each item. Each tag can be associated with one or more grocery items, and vice versa. Users can assign tags to their items to help organize their shopping. Since the model defines the relation between items and tags as many-to-many, any item can be associated with one or more tags, and each tag can be associated to one or more items. A graphical representation of the new relational model is shown in Figure 27, A relational model for Grocery. [29]

Figure 27. A relational model for Grocery. The relational model for the Grocery database consists of items and tags. The relation between an item and a tag is many-to-many.

A sample application that implements this model is included with the project for this chapter, Grocery-06-starter, available at the site for this book. The type of data storage is SQLite. The model includes two classes, SMGroceryItem and SMTag, plus a new view controller, SMTagPicker, which allows the user to assign one or more tags to an item. Figure 28, The tag picker shows the tag picker in action. [30]

Figure 28. The tag picker. The tag picker displays three tags: mall and grocery store and green grocer. Clicking one assigns it to a grocery item. To return to the item, click the Item button.

To display the tag picker, the user taps the tags label that is displayed in the detail view of an item. The tags label is the gray rectangle shown in Figure 29, A tagged item.

Figure 29. A tagged item. The new detail view shown here displays the tags associated with the carrots item of the Grocery application. When the user taps the gray label, the tag picker shown in Figure 28, The tag picker will appear.

The rest of the grocery project has the same functionality and user interface described in the previous chapters. Users, however, can now tag their grocery items with a new relational data model, Core Data, and a SQLite type of storage behind the scenes to implement the change.

Now that we have a sample Core Data application, let’s see what we must do to enable it for iCloud. There is no need to upload the database or its schema to iCloud. All that’s required is for you to change the way the context and file coordinator are initialized. Once these two changes have been made, the application will begin to synchronize its data the first time it’s launched. Changes made on one device are propagated to others through iCloud servers. In the case of Core Data applications, each change is recorded in a transaction log (for example, “A new item with name ’Carrots’ has been added”) and dispatched to the other devices through iCloud. In the next sections, I’ll explain how to initialize the Core Data stack to make it iCloud ready.

8.2 Initializing a Core Data Stack for iCloud

To initialize a classic Core Data application for iCloud, we must provide it with the following: a data model, a context, and a coordinator. The context mediates between the objects of an application (for example, the instances of grocery items) and the Core Data framework. When we change an object or create a new one, it’s never stored directly in the underlying store; it’s committed to the application’s context. Only when we “flush” a context by calling the save: method are the changes made permanent in the local device, the data having first been checked for consistency. A call to the save: method also triggers the propagation of data to iCloud. As with UIDocument data, the changes may not be propagated immediately depending on the availability of an appropriate connection, status of the device battery, and other conditions determined by the operating system.

The coordinator, short for “persistent store coordinator,” mediates between the context and the actual store (for example, a SQLite database). It is up to the coordinator to pick out the changes in the context and serialize them according to the type of Core Data storage (that is, SQLite, XML, or binary) being used.

Model, context, and coordinator are usually defined in the application delegate. In the Grocery-chp8-starter project for this chapter, these properties are defined in the SMAppDelegate class.

In the next two sections, let’s see how the coordinator should be updated to work with iCloud and then do the same for the application context.

Modifying the Coordinator

To a create coordinator for any Core Data application, we must complete the following steps:

1. Create a reference to the database, which can be a SQLite, XML, or binary file.

2. Instantiate a coordinator, passing the instance of model.

3. Register the coordinator by means of the addPersistentStoreWithType:configuration:URL:options:error: method.

For example, here’s the code to create a coordinator for the non-iCloud version of Grocery:

Grocery-chp8-starter/Grocery/SMAppDelegate.m

- (NSPersistentStoreCoordinator *)persistentStoreCoordinator

{

if (_persistentStoreCoordinator != nil) {

return _persistentStoreCoordinator;

}

NSURL *storeURL = [[self applicationDocumentsDirectory]

URLByAppendingPathComponent:@"Grocery.sqlite"];

NSError *error = nil;

_persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc]

initWithManagedObjectModel:

[self managedObjectModel]];

if (![_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType

configuration:nil

URL:storeURL

options:nil

error:&error]) {

NSLog(@"Unresolved error %@, %@", error, [error userInfo]);

abort();

}

return _persistentStoreCoordinator;

}

To initialize a coordinator for iCloud, it’s the third step that we need to change. There are two modifications to be made. The first is to create a dictionary of options required of an iCloud coordinator and pass it to the addPersistentStoreWithType:configuration:URL:options:error: method. The second is to make sure that the registration of the coordinator is nonblocking.

The dictionary has to include values for three properties.

NSPersistentStoreUbiquitousContentNameKey

A name that uniquely identifies the store in the ubiquity container

NSPersistentStoreUbiquitousContentURLKey

A path to a file that will store the transaction logs

NSMigratePersistentStoresAutomaticallyOption

A boolean value to specify how to perform automatic migrations in the store

Before we build the dictionary, we first have to create the URL for the transaction log file whose name we’ll assign to NSPersistentStoreUbiquitousContentURLKey . Here’s the code to create a subfolder in the ubiquity container, named grocery_data, that we’ll use for the Grocery application:

Grocery-chp8-end/Grocery/SMAppDelegate.m

NSFileManager *fileManager = [NSFileManager defaultManager];

NSURL *transactionLogsURL = [fileManager

URLForUbiquityContainerIdentifier:nil];

NSString* coreDataCloudContent = [[transactionLogsURL path]

stringByAppendingPathComponent:

@"grocery_data"];

transactionLogsURL = [NSURL fileURLWithPath:coreDataCloudContent];

With a URL for the transaction file in hand, we can now build a dictionary to initialize the coordinator for the Grocery database.

Grocery-chp8-end/Grocery/SMAppDelegate.m

NSDictionary* options = @{NSPersistentStoreUbiquitousContentNameKey :

@"com.studiomagnolia.coredata.grocery",

NSPersistentStoreUbiquitousContentURLKey:

transactionLogsURL,

NSMigratePersistentStoresAutomaticallyOption:

@YES

};

The final task is to register the coordinator in a way that doesn’t block interaction with the user interface. Nothing is more frustrating to users. To avoid blocking, we should put registration into a background queue, a secondary thread that performs data synchronization with the servers and notifies the application when it’s done. To do this, I’ve resorted to Grand Central Dispatch (GCD) and its dispatch_async() method.[31]

Once the registration of the coordinator has been completed, we will want to notify the application. Here’s the code to do it for our Grocery project:

Grocery-chp8-end/Grocery/SMAppDelegate.m

dispatch_async(dispatch_get_main_queue(), ^{

NSLog(@"persistent store added");

[[NSNotificationCenter defaultCenter]

postNotificationName:

@"com.studiomagnolia.groceryItemsSynchronized"

object:self

userInfo:nil];

});

Now, let’s put all of this together and define the method persistentStoreCoordinator . It belongs to the application delegate for Grocery, SMAppDelegate, as in the starter project.

Grocery-chp8-end/Grocery/SMAppDelegate.m

- (NSPersistentStoreCoordinator *)persistentStoreCoordinator

{

if (_persistentStoreCoordinator != nil) {

return _persistentStoreCoordinator;

}

_persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc]

initWithManagedObjectModel:

[self managedObjectModel]];

NSString *storePath = [[self applicationDocumentsDirectory]

stringByAppendingPathComponent:@"Grocery.sqlite"];

NSPersistentStoreCoordinator* psc = _persistentStoreCoordinator;

dispatch_async(

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0),

^{

NSURL *storeUrl = [NSURL fileURLWithPath:storePath];

// building the path to store transaction logs

NSFileManager *fileManager = [NSFileManager defaultManager];

NSURL *transactionLogsURL = [fileManager

URLForUbiquityContainerIdentifier:nil];

NSString* coreDataCloudContent = [[transactionLogsURL path]

stringByAppendingPathComponent:

@"grocery_data"];

transactionLogsURL = [NSURL fileURLWithPath:coreDataCloudContent];

//  Building the options array for the coordinator

NSDictionary* options = @{NSPersistentStoreUbiquitousContentNameKey :

@"com.studiomagnolia.coredata.grocery",

NSPersistentStoreUbiquitousContentURLKey:

transactionLogsURL,

NSMigratePersistentStoresAutomaticallyOption:

@YES

};

NSError *error = nil;

[psc lock];

if (![psc addPersistentStoreWithType:NSSQLiteStoreType

configuration:nil

URL:storeUrl

options:options

error:&error]) {

NSLog(@"Core data error %@, %@", error, [error userInfo]);

}

[psc unlock];

// post a notification to tell the main thread

// to refresh the user interface

dispatch_async(dispatch_get_main_queue(), ^{

NSLog(@"persistent store added");

[[NSNotificationCenter defaultCenter]

postNotificationName:

@"com.studiomagnolia.groceryItemsSynchronized"

object:self

userInfo:nil];

});

});

return _persistentStoreCoordinator;

}

Now let’s move on to the last step in modifying Core Data for iCloud: context creation.

Modifying Context

To update the definition of context and make it iCloud aware, we need to make these three changes:

1. Choose a concurrency type to initialize the context with.

2. Set the persistent store coordinator.

3. Listen for NSPersistentStoreDidImportUbiquitousContentChangesNotification notifications.

Our choice of concurrency type determines how the context behaves when it’s accessed concurrently by different threads. We can associate it with a private queue (which runs in the background) or with the main application thread (which is used to draw the user interface). In the case of the Grocery application, I’ve chosen to update the context with objects that live in the main thread, so we will initialize the context as follows:

Grocery-chp8-end/Grocery/SMAppDelegate.m

NSManagedObjectContext* moc = [[NSManagedObjectContext alloc]

initWithConcurrencyType:

NSMainQueueConcurrencyType];

This line of code declares the context to be queue-based, so to set its properties, we need to use either the performBlockAndWait: or performBlock: method. For example, to set the coordinator of the context, we write the following:

[moc performBlockAndWait:^{

[moc setPersistentStoreCoordinator:coordinator];

}];

Having specified the concurrency type, the last step is to add an observer to the context to listen for iCloud notifications that the store has been modified. The name of the notification that we need to listen for is pretty long:

NSPersistentStoreDidImportUbiquitousContentChangesNotification .

This notification will be thrown when there are changes in the content of the persistent store (for example, when a new item is created or edited).

Pulling all of it together, here is the new definition of context :

Grocery-chp8-end/Grocery/SMAppDelegate.m

- (NSManagedObjectContext *)managedObjectContext

{

if (_managedObjectContext != nil) {

return _managedObjectContext;

}

NSPersistentStoreCoordinator *coordinator =

[self persistentStoreCoordinator];

if (coordinator != nil) {

// choose a concurrency type for the context

NSManagedObjectContext* moc = [[NSManagedObjectContext alloc]

initWithConcurrencyType:

NSMainQueueConcurrencyType];

[moc performBlockAndWait:^{

// configure context properties

[moc setPersistentStoreCoordinator: coordinator];

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(mergeChangesFromiCloud:)

name:NSPersistentStoreDidImportUbiquitousContentChangesNotification

object:coordinator];

}];

_managedObjectContext = moc;

}

return _managedObjectContext;

}

The method mergeChangesFromiCloud: that appears in this code is defined as follows:

Grocery-chp8-end/Grocery/SMAppDelegate.m

- (void)mergeChangesFromiCloud:(NSNotification *)notification {

NSManagedObjectContext* moc = [self managedObjectContext];

NSDictionary *noteInfo = [notification userInfo];

[moc performBlock:^{

NSMutableDictionary *mergingPolicyResult = [NSMutableDictionary dictionary];

[mergingPolicyResult setObject:noteInfo[NSInsertedObjectsKey]

forKey:NSInsertedObjectsKey];

[mergingPolicyResult setObject:noteInfo[NSUpdatedObjectsKey]

forKey:NSUpdatedObjectsKey];

[mergingPolicyResult setObject:[NSSet set] // Exclude deletions

forKey:NSDeletedObjectsKey];

NSNotification *saveNotification =

[NSNotification notificationWithName:notification.name

object:self

userInfo:mergingPolicyResult];

[moc mergeChangesFromContextDidSaveNotification:saveNotification];

[moc processPendingChanges];

}];

}

This method is responsible of merging changes notified from iCloud into the local store, applying the default merge policy whenever conflicts occur. I will provide more details about custom policies for conflict resolution in Section 8.3, Handling Conflicts.

In the code, a notification is posted when the data synchronization done at startup is finished. You need to listen for that notification. I have set up the observer at the end of viewDidLoad of SMMasterViewController, as follows:

[[NSNotificationCenter defaultCenter]

addObserver:self

selector:@selector(reloadItems)

name:@"com.studiomagnolia.groceryItemsSynchronized"

object:nil];

The reloadItems method that appears in the preceding code triggers a reload of the table and is defined like this:

Grocery-chp8-end/Grocery/SMMasterViewController.m

- (void) reloadItems {

NSLog(@"============ reloading items");

NSError *error = nil;

if (![[self fetchedResultsController] performFetch:&error]) {

NSLog(@"Core data error %@, %@", error, [error userInfo]);

} else {

[self.tableView reloadData];

}

}

Finally, we need to refactor applicationDocumentsDirectory in SMAppDelegate as follows and change its signature in the header accordingly:

Grocery-chp8-end/Grocery/SMAppDelegate.m

- (NSString *)applicationDocumentsDirectory {

return [NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,

NSUserDomainMask, YES) lastObject];

}

Now it’s time test the new Grocery application on some real devices. Install it on an iPhone or iPad and add a few items with a bunch of tags. Then install it on a second iOS device and confirm that the items on the first are correctly propagated. Keep both applications open, change items on one device, and then look to confirm they’ve been propagated to the other.

Now that you’ve learned the basics of iCloud-enabling a Core Data application, you’re ready for something more complex: conflict resolution and related policies.

8.3 Handling Conflicts

As with the UIDocument data of earlier chapters, conflicts can occur in Core Data applications too. It’s entirely possible to have simultaneous changes to the same properties of an item, such as the spelling of its name or its tag. In this section, we’ll discuss two ways to resolve conflicts: adopting a policy predefined by Apple or creating a custom policy.

Use a Predefined Apple Policy

As you saw in Modifying Context, when we define the context, we must also provide a mechanism for dealing with concurrent updates to the data. In previous examples, we used iCloud’s mergeChangesFromContextDidSaveNotification: method, which merges changes automatically. The way this method works is pretty smart. When users change the properties of an object and those properties are not the same, the method simply merges both changes. For example, if you change the title of an item on one device and its tags on another, it will update the item with both the new values. If there is a conflict, however, the current implementation of the Grocery application will throw an error. That’s because the instance of context we have created makes use of the mergePolicy property, whose default value is NSErrorMergePolicy. Other values we could have chosen include the following:

NSMergeByPropertyStoreTrumpMergePolicy

Changes coming from other devices win over the in-memory version.

NSMergeByPropertyObjectTrumpMergePolicy

In-memory changes win over external ones.

NSOverwriteMergePolicy

Every change (external or in-memory) overwrites the version in the persistent store.

NSRollbackMergePolicy

This discards changes to conflicting objects in memory.

To specify the merge policy of a context, we can use the following code, choosing a value for mergePolicy from the preceding list:

NSManagedObjectContext* moc =

[[NSManagedObjectContext alloc]

initWithConcurrencyType:NSMainQueueConcurrencyType];

moc.mergePolicy = ...;

If one of the predefined policies fits your needs, I encourage you to use it. The alternative is to create a conflict resolution policy of your own, as we’ll see in the next section.

Create a Custom Policy

Before diving into the code to implement a custom policy, let’s first take a look at the notification messages that iCloud creates whenever there is a change to the database. To observe them, just change the mergeChangesFromiCloud: method to display their contents.

- (void)mergeChangesFromiCloud:(NSNotification *)notification {

NSLog(@"notification %@", notification);

NSDictionary *noteInfo = [notification userInfo];

NSMutableDictionary *localUserInfo = [NSMutableDictionary dictionary];

NSLog(@"insertions = %@",

[noteInfo objectForKey:NSInsertedObjectsKey]);

NSLog(@"deletions = %@",

[noteInfo objectForKey:NSDeletedObjectsKey]);

NSLog(@"updates = %@",

[noteInfo objectForKey:NSUpdatedObjectsKey]);

}

Run the application on an iPhone connected to the debugger and then, on an iPad, add a new item. The console will print something like this:

NSConcreteNotification 0x37fec0 {

name = com.apple.coredata.ubiquity. importer.didfinishimport;

object = <NSPersistentStoreCoordinator: 0x353f30>; userInfo = {

deleted = "{(\n)}";

inserted = "{(\n 0x41dt50 <x-coredata://7F194E5A-628V-4359-9931-

H3419BE9FE18/SMGroceryItem/p5>\n)}";

updated = "{(\n)}";

}

}

As you can see, the iCloud notification gives us all the details of the transaction log. In the specific case shown here, there was no deletion, there were no updates, and there was just one insertion.

Here’s a code schema you can use to create your own policies for handling conflicts:

- (void)mergeChangesFromiCloud:(NSNotification *)notification {

NSManagedObjectContext* moc = [self managedObjectContext];

[moc performBlock:^{

NSMutableDictionary *mergingPolicyResult = [NSMutableDictionary dictionary];

// process insertions

// process deletions

// process updates

NSNotification *saveNotification =

[NSNotification notificationWithName:

NSManagedObjectContextDidSaveNotification

object:self

userInfo:mergingPolicyResult];

[moc mergeChangesFromContextDidSaveNotification: saveNotification];

[moc processPendingChanges];

}];

}

The code works like this: once we have built a dictionary of the changes we want to commit to the context, we build a notification that carries the dictionary and then call the mergeChangesFromContextDidSaveNotification , followed by processPendingChanges .

With this schema, we should be able to build the custom resolution policies we need to resolve conflicts in our Core Data applications.

For example, if we want to build an application that for some reason prevents deletions, we can implement it as follows:

- (void)mergeChangesFromiCloud:(NSNotification *)notification {

NSManagedObjectContext* moc = [self managedObjectContext];

NSDictionary *noteInfo = [notification userInfo];

[moc performBlock:^{

NSMutableDictionary *mergingPolicyResult = [NSMutableDictionary dictionary];

[mergingPolicyResult setObject:noteInfo[NSInsertedObjectsKey]

forKey:NSInsertedObjectsKey];

[mergingPolicyResult setObject:noteInfo[NSUpdatedObjectsKey]

forKey:NSUpdatedObjectsKey];

[mergingPolicyResult setObject:[NSSet set] // Exclude deletions

forKey:NSDeletedObjectsKey];

NSNotification *saveNotification =

[NSNotification notificationWithName:notification.name

object:self

userInfo:mergingPolicyResult];

[moc mergeChangesFromContextDidSaveNotification:saveNotification];

[moc processPendingChanges]

}];

}

8.4 Moving On

In this chapter, I explained how to build an iCloud-enabled application that leverages the capabilities of Core Data. In particular, I showed how to change a “classic” Core Data application and enable it for iCloud. You learned how to alter the initialization of a Core Data stack and two ways to handle conflict resolution when more than one user at a time is using your application. If you want to check out the final project created throughout this chapter, it is located in the folder named Grocery-chp8-end.

8.5 Conclusion

This chapter concludes our journey through the land of iCloud. We started with the simplest form of iCloud data, key-value storage, and explored how changes to its values can be quickly propagated to other devices. We then moved to UIDocument-based data formats with which we can build complex applications that store text, images, and more. Finally, we talked about how to deal with relational information using Core Data. For each approach I showed you how to save data and how to set up an application to react to change notifications broadcast by iCloud servers.

Now that we’ve arrived at our destination, you should be able to decide which approach is the best for your application (and your users) and write the code to make it work. Good luck. It has been a pleasure serving as your guide.

Footnotes

[27]

Although in this chapter I will deal only with iOS, you can also build iCloud-enabled Core Data applications for Mac OS.

[28]

If you want to get acquainted with Core Data, you can check out Core Data: Data Storage and Management for iOS, OS X, and iCloud [Zar12].

[29]

For the sake of simplicity, I have chosen to not deal with images in this chapter. Feel free to extend this data model by adding a new field to SMGroceryItem to hold a reference to an image URL. For small images, you could use external binary storage. For more information about this, refer to Chapter 5.2 of Core Data: Data Storage and Management for iOS, OS X, and iCloud [Zar12].

[30]

The list of tags in the picker is fixed; the list is created when the picker is called for the first time. Feel free to complete the view controller by adding code to create, edit, and delete tags.

[31]

If you are not familiar with GCD, you should read this document from Apple’s documentation: https://developer.apple.com/library/mac/#documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html .

Copyright © 2013, The Pragmatic Bookshelf.

Appendix 1

Bibliography

[AD12]

Chris Adamson and Bill Dudney. iOS SDK Development. The Pragmatic Bookshelf, Raleigh, NC and Dallas, TX, 2012.

[Zar12]

Marcus S. Zarra. Core Data: Data Storage and Management for iOS, OS X, and iCloud. The Pragmatic Bookshelf, Raleigh, NC and Dallas, TX, Second, 2012.

Copyright © 2013, The Pragmatic Bookshelf.

You May Be Interested In…

Click a cover for more information

Table of Contents

iCloud for Developers

Table of Contents

Early Praise for iCloud for Developers

Acknowledgments

Preface

Who Should Read This Book?

What’s in This Book?

How to Read This Book

Notes on Formatting

Online Resources

Requirements

Moving On

Chapter 1: Preparing Your Application for iCloud

1.1 What Is iCloud?

1.2 What’s Behind iCloud

1.3 Introducing the Grocery Application

1.4 Enabling Your Application for iCloud

1.5 Checking for iCloud Availability

1.6 Moving On

Chapter 2: Working with Key-Value Data

2.1 iCloud Storage Types

2.2 Using Key-Value Pairs with iCloud

2.3 Using Key-Value Pairs in Grocery

2.4 Reacting to Changes in iCloud

2.5 Key-Value Storage Limitations

2.6 Moving On

Chapter 3: Working with Documents

3.1 Interacting with iCloud

3.2 Extending the UIDocument Class

3.3 Modeling a Grocery Item as a UIDocument

3.4 Displaying a Grocery Item

3.5 Moving On

Chapter 4: Managing Multiple Files and iCloud Notifications

4.1 Creating and Managing Multiple Files

4.2 Creating and Managing Multiple Grocery Items

4.3 Managing Updates While an Application Is Running

4.4 Editing Grocery Item Content

4.5 Moving On

Chapter 5: Wrapping Items in a Single File

5.1 Working with File Packages

5.2 Packaging Grocery Items

5.3 Updating the User Interface

5.4 Moving On

Chapter 6: Handling Nontextual Information in a Data Model

6.1 Working with Data in Packages

6.2 Associating Images with Names

6.3 Updating the User Interface

6.4 Moving On

Chapter 7: Handling Conflicts

7.1 Working with Document States and Notifications

7.2 Preventing Conflicts Between Grocery Items

7.3 Resolving Conflicts Between Grocery Items

7.4 Moving On

Chapter 8: Working with Core Data and iCloud

8.1 The Relational Model of the Grocery List

8.2 Initializing a Core Data Stack for iCloud

8.3 Handling Conflicts

8.4 Moving On

8.5 Conclusion

Appendix 1: Bibliography

You May Be Interested In…