Τρίτη, 27 Μαρτίου 2012

Property lists - XML - when to use - short notes



strong points: 

  • For situations where you need to store small amounts of persistent data—say less than a few hundred kilobytes—property lists offer a uniform and convenient means of organizing, storing, and accessing the data.
  • A property list can be stored in one of three different ways: in an XML representation, in a binary format, or in an “old-styleASCII format inherited from OpenStep.
  • In general, if your property list is relatively small, the benefits of XML property lists outweigh the I/O speed and compactness that comes with binary property lists. If you have a large data set, binary property lists, keyed archives, or custom data formats are a better solution
  • And although NSDictionary and CFDictionary objects allow their keys to be objects of any type, if the keys are not string objects, the collections are not property-list objects.
  • If you are looking for a way to implement user or application preferences, Cocoa provides a class specifically for this purpose.See Preferences and Settings Programming Guide and Preferences Programming Topics for Core Foundation for more information.




A property list is a structured data representation used by Cocoa and Core Foundation as a convenient way to store, organize, and access standard types of data. It is colloquially referred to as a “plist.”
Applications on iOS use property lists in their Settings bundle to define the list of options displayed to users.

Note: Although user and application preferences use property lists to structure and store data, you should not use the property list API of either Cocoa or Core Foundation to read and modify them. Instead, use the programming interfaces provided specifically for this purpose—see Preferences and Settings Programming Guide and Preferences Programming Topics for Core Foundation for more information.


A root property-list object is at the top of this hierarchy, and in almost all cases is a dictionary or an array. Note, however, that a root property-list object does not have to be a dictionary or array; for example, you could have a single string, number, or date, and that primitive value by itself can constitute a property list.

Property lists are based on an abstraction for expressing simple hierarchies of data. The items of data in a property list are of a limited number of types. Some types are for primitive values and others are for containers of values. The primitive types are strings, numbers, binary data, dates, and Boolean values. The containers are arrays—indexed collections of values—and dictionaries—collections of values each identified by a key. The containers can contain other containers as well as the primitive types. Thus you might have an array of dictionaries, and each dictionary might contain other arrays and dictionaries, as well as the primitive types. A root property-list object is at the top of this hierarchy, and in almost all cases is a dictionary or an array.

The static representation of a property list, which is used for storage, can be either XML or binary data. (The binary version is a more compact form of the XML property list.)

Abstract type
XML element
Cocoa class
Core Foundation type
array
<array>
CFArray (CFArrayRef)
dictionary
<dict>
CFDictionary (CFDictionaryRef)
string
<string>
CFString (CFStringRef)
data
<data>
CFData (CFDataRef)
date
<date>
CFDate (CFDateRef)
number - integer
<integer>
CFNumber (CFNumberRef, integer value)
number - floating point
<real>
CFNumber (CFNumberRef, floating-point value)
Boolean
<true/> or <false/>
NSNumber (boolValue == YES or boolValue == NO)

By convention, each Cocoa and Core Foundation object listed in above table is called a property-list object

example of exctracted xml file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
                  <dict>
                                    <key>shares</key>
                                    <integer>200</integer>
                                    <key>symbol</key>
                                    <string>AAPL</string>
                  </dict>
                  <dict>
                                    <key>shares</key>
                                    <integer>160</integer>
                                    <key>symbol</key>
                                    <string>GOOG</string>
                  </dict>
</array>
</plist>

And although NSDictionary and CFDictionary objects allow their keys to be objects of any type, if the keys are not string objects, the collections are not property-list objects.

In most cases, however, methods provided by the NSPropertyListSerialization class should provide enough flexibility

For situations where you need to store small amounts of persistent data—say less than a few hundred kilobytes—property lists offer a uniform and convenient means of organizing, storing, and accessing the data.

In some situations, the property-list architecture may prove insufficient. If you need a way to store large, complex graphs of objects, objects not supported by the property-list architecture, or objects whose mutability settings must be retained, use archiving. See Archives and Serializations Programming Guide for more information

If you are looking for a way to implement user or application preferences, Cocoa provides a class specifically for this purpose. While the user defaults system does use property lists to store information, you do not have to access these plists directly. See Preferences and Settings Programming Guide and Preferences Programming Topics for Core Foundation for more information.

Note that property lists should be used for data that consists primarily of strings and numbers. They are very inefficient when used with large blocks of binary data.

A property list can be stored in one of three different ways: in an XML representation, in a binary format, or in an “old-style” ASCII format inherited from OpenStep. You can serialize property lists in the XML and binary formats. The serialization API with the old-style format is read-only.

XML property lists are more portable than the binary alternative and can be manually edited, but binary property lists are much more compact; as a result, they require less memory and can be read and written much faster than XML property lists. In general, if your property list is relatively small, the benefits of XML property lists outweigh the I/O speed and compactness that comes with binary property lists. If you have a large data set, binary property lists, keyed archives, or custom data formats are a better solution.

Δεν υπάρχουν σχόλια:

Δημοσίευση σχολίου