iOS Programming: The Big Nerd Ranch Guide, 3/e (Big Nerd Ranch Guides) (101 page)

Finally, we can test our work. Build and run
Nerdfeed
on a device. Click
Stop
in
Xcode
, and then build and run on another device. Restart the application on the first device, and select a row from the table view. After a few moments, you will see the checkmark appear in that row on the other device!

One thing to keep in mind when using iCloud-capable applications is that deleting an application does not delete the data from Apple’s servers. Sometimes when developing an iCloud application, you will need to change the structure of your data and delete the old data structure from the cloud.

To delete an application’s data from the cloud, open the
Settings
application on the device and select
iCloud
. Next, select
Storage & Backup
near the bottom of the next screen and then
Manage Storage
. You will see a screen that looks like
Figure 30.8
.

Figure 30.8  Managing iCloud Storage

 

Every iCloud-capable application on a device will appear on this screen under
Documents & Data
. When developing an application, its name is not yet registered with Apple’s servers, so it will appear as
Unknown
. To delete the data associated with an application you are developing, tap the
Unknown
row. Then, tap the
Edit
button. A big
Delete All
button will appear – tap it to remove the data from the iCloud servers.

You only have to delete data from iCloud’s storage from one device because all devices share the same data.

Although not an explicit feature of iCloud, iOS supports backing up the contents of a device in the cloud. Part of the backup process synchronizes the
Documents
and
Library/Preferences
directories of each application sandbox. This is pretty neat, but you can’t go hog wild. This ability to back up data in
Documents/
in the cloud has led to a new requirement for applications: you can’t store too much data in the
Documents
directory on pain of your application being rejected by the App Store.

Of course,
“
too much data
”
is frustratingly vague, but the general rule is only store in
Documents/
what really needs backing up and not what can be recreated. Data that can be recreated should be stored in
Library/Caches/
instead of
Documents/
.

However, there is a problem with this rule. The system can purge the contents
Library/Caches/
when an application is running low on disk space, and it can do so without warning. Now, if an application can recreate its caches from another server, it’s not a big deal if this directory gets purged – you just download the content again. However, some applications cache content for offline use. For example, an application could download web articles so that the user can read them on a plane. If the application is offline, data that gets purged can’t be recreated.

If you need to store potentially large amounts offline content indefinitely, the fix is to put the data in
Documents/
and
set a special flag that prevents the file or the folder and its contents from being backed up. This protects the data from being purged and keeps the App Store happy. You set this flag like so:

The important bit here is the key
NSURLIsExcludedFromBackupKey
. This key can be set on any URL (file or folder) in an application’s sandbox and prevent it from being backed up. Note that this flag is not the same as the
.nosync
suffix, which prevents a file or folder in a ubiquity container from being synchronized in the cloud.

Welcome to the end of the book! You should be very proud of all your work and all that you have learned. Now, there’s good news and bad news:

It is now time to make some mistakes, read some really tedious documentation, and be humbled by the heartless experts who will ridicule your questions. Here’s what we recommend:

Write apps now.
If you don’t immediately use what you have learned, it will fade. Exercise and extend your knowledge. Now.

Go deep.
This book has consistently favored breadth over depth; any chapter could have been expanded into an entire book. Find a topic that you find interesting and really wallow in it – do some experiments, read Apple’s docs on the topic, read a posting on a blog or on StackOverflow.

Connect.
There is an iOS Developer Meetup in most cities, and the talks are surprisingly good. There are discussion groups online. If you are doing a project, find people to help you: designers, testers (AKA guinea pigs), and other developers.

Make mistakes and fix them.
You will learn a lot the days you say,
“
This application has become a ball of crap! I’m going to throw it away and write it again with an architecture that makes sense.
”
Polite programmers call this
refactoring
.

Give back.
Share the knowledge. Answer a dumb question with grace. Give away some code.

You can find us both on Twitter, where we keep you informed about programming and entertained about life:
@joeconwaybnr
and
@aaronhillegass
.

Keep an eye out for future guides from Big Nerd Ranch. We also offer week-long courses for developers. And if you just need some code written, we do contract programming. For more information, visit our website at
http://www.bignerdranch.com/
.

It is you, dear reader, who makes our lives of writing, coding, and teaching possible. So thank you for buying our book.