C H A P T E R 1 1
Data Storage and Retrieval
11-4
About Data Storage on Newton Devices
different from soups that are not part of a union. Unless specifically noted
otherwise, anything said about soups in this text applies equally to union soups.
Figure 11-1
Stores, soups and union soups
In general, you'll want to use union soups for most purposes, especially for saving
most data the user creates with your application. Applications must allow the user
to choose whether to save new data on the internal or external store; using union
soups makes this easy to do.
An application creates a union soup by registering a soup definition frame with the
system; registering the soup definition causes the system to return a union soup
object to which the application can send messages that save and retrieve data. This
object may represent a new soup, one created previously, or no soups (if, for some
reason, all of the union's member soups are unavailable). For a detailed discussion
of soup creation, see "Soups" beginning on page 11-7.
All soups save frame data as objects called entries. An entry is a frame that has
been added to a soup by means of any of several system-supplied methods
provided for this purpose. Note that you cannot create a valid entry by simply
adding certain slots and values to a frame--the system must create the entry for
you from a frame presented as an argument to one of the entry-creation methods.
Returning to the database analogy, you can think of entries as individual records in
the database, and you can think of the soup as the database itself. Like a database, a
soup is opaque--you retrieve data by requesting it, rather than by examining its
records directly.
Your request for soup data takes the form of a
Query
message sent to the soup or
union soup object. The
Query
method accepts as its argument a frame known as
Internal Store
Entries
External Store
aSoup
aSoup
Union Soup
{theNum:121088
, ...
}
{myFn:<code block>
, ...
}
{aSlot:"some string data"
, ...
}
{data:
, ...
}