/**@class android.provider.ContactsContract.Data
 implements android.provider.ContactsContract.DataColumnsWithJoins

 implements android.provider.ContactsContract.ContactCounts

@extends java.lang.Object

 <p>
 Constants for the data table, which contains data points tied to a raw
 contact.  Each row of the data table is typically used to store a single
 piece of contact
 information (such as a phone number) and its
 associated metadata (such as whether it is a work or home number).
 </p>
 <h3>Data kinds</h3>
 <p>
 Data is a generic table that can hold any kind of contact data.
 The kind of data stored in a given row is specified by the row's
 {@link #MIMETYPE} value, which determines the meaning of the
 generic columns {@link #DATA1} through
 {@link #DATA15}.
 For example, if the data kind is
 {@link android.provider.ContactsContract.CommonDataKinds.android.provider.CommonDataKinds.Phone android.provider.CommonDataKinds.Phone.CONTENT_ITEM_TYPE}, then the column
 {@link #DATA1} stores the
 phone number, but if the data kind is
 {@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Email android.provider.android.provider.ContactsContract.CommonDataKinds.Email.CONTENT_ITEM_TYPE}, then {@link #DATA1}
 stores the email address.
 Sync adapters and applications can introduce their own data kinds.
 </p>
 <p>
 ContactsContract defines a small number of pre-defined data kinds, e.g.
 {@link android.provider.ContactsContract.CommonDataKinds.Phone}, {@link android.provider.ContactsContract.CommonDataKinds.Email} etc. As a
 convenience, these classes define data kind specific aliases for DATA1 etc.
 For example, {@link android.provider.ContactsContract.CommonDataKinds.android.provider.CommonDataKinds.Phone android.provider.CommonDataKinds.Phone.NUMBER} is the same as
 {@link android.provider.ContactsContract.Data Data.DATA1}.
 </p>
 <p>
 {@link #DATA1} is an indexed column and should be used for the data element that is
 expected to be most frequently used in query selections. For example, in the
 case of a row representing email addresses {@link #DATA1} should probably
 be used for the email address itself, while {@link #DATA2} etc can be
 used for auxiliary information like type of email address.
 <p>
 <p>
 By convention, {@link #DATA15} is used for storing BLOBs (binary data).
 </p>
 <p>
 The sync adapter for a given account type must correctly handle every data type
 used in the corresponding raw contacts.  Otherwise it could result in lost or
 corrupted data.
 </p>
 <p>
 Similarly, you should refrain from introducing new kinds of data for an other
 party's account types. For example, if you add a data row for
 "favorite song" to a raw contact owned by a Google account, it will not
 get synced to the server, because the Google sync adapter does not know
 how to handle this data kind. Thus new data kinds are typically
 introduced along with new account types, i.e. new sync adapters.
 </p>
 <h3>Batch operations</h3>
 <p>
 Data rows can be inserted/updated/deleted using the traditional
 {@link ContentResolver#insert}, {@link ContentResolver#update} and
 {@link ContentResolver#delete} methods, however the newer mechanism based
 on a batch of {@link ContentProviderOperation} will prove to be a better
 choice in almost all cases. All operations in a batch are executed in a
 single transaction, which ensures that the phone-side and server-side
 state of a raw contact are always consistent. Also, the batch-based
 approach is far more efficient: not only are the database operations
 faster when executed in a single transaction, but also sending a batch of
 commands to the content provider saves a lot of time on context switching
 between your process and the process in which the content provider runs.
 </p>
 <p>
 The flip side of using batched operations is that a large batch may lock
 up the database for a long time preventing other applications from
 accessing data and potentially causing ANRs ("Application Not Responding"
 dialogs.)
 </p>
 <p>
 To avoid such lockups of the database, make sure to insert "yield points"
 in the batch. A yield point indicates to the content provider that before
 executing the next operation it can commit the changes that have already
 been made, yield to other requests, open another transaction and continue
 processing operations. A yield point will not automatically commit the
 transaction, but only if there is another request waiting on the
 database. Normally a sync adapter should insert a yield point at the
 beginning of each raw contact operation sequence in the batch. See
 {@link ContentProviderOperation.Builder#withYieldAllowed(boolean)}.
 </p>
 <h3>Operations</h3>
 <dl>
 <dt><b>Insert</b></dt>
 <dd>
 <p>
 An individual data row can be inserted using the traditional
 {@link ContentResolver#insert(Uri, ContentValues)} method. Multiple rows
 should always be inserted as a batch.
 </p>
 <p>
 An example of a traditional insert:
 <pre>
 ContentValues values = new ContentValues();
 values.put(Data.RAW_CONTACT_ID, rawContactId);
 values.put(Data.MIMETYPE, Phone.CONTENT_ITEM_TYPE);
 values.put(Phone.NUMBER, "1-800-GOOG-411");
 values.put(Phone.TYPE, Phone.TYPE_CUSTOM);
 values.put(Phone.LABEL, "free directory assistance");
 Uri dataUri = getContentResolver().insert(Data.CONTENT_URI, values);
 </pre>
 <p>
 The same done using ContentProviderOperations:
 <pre>
 ArrayList&lt;ContentProviderOperation&gt; ops =
          new ArrayList&lt;ContentProviderOperation&gt;();

 ops.add(ContentProviderOperation.newInsert(Data.CONTENT_URI)
          .withValue(Data.RAW_CONTACT_ID, rawContactId)
          .withValue(Data.MIMETYPE, Phone.CONTENT_ITEM_TYPE)
          .withValue(Phone.NUMBER, "1-800-GOOG-411")
          .withValue(Phone.TYPE, Phone.TYPE_CUSTOM)
          .withValue(Phone.LABEL, "free directory assistance")
          .build());
 getContentResolver().applyBatch(ContactsContract.AUTHORITY, ops);
 </pre>
 </p>
 <dt><b>Update</b></dt>
 <dd>
 <p>
 Just as with insert, update can be done incrementally or as a batch,
 the batch mode being the preferred method:
 <pre>
 ArrayList&lt;ContentProviderOperation&gt; ops =
          new ArrayList&lt;ContentProviderOperation&gt;();

 ops.add(ContentProviderOperation.newUpdate(Data.CONTENT_URI)
          .withSelection(Data._ID + "=?", new String[]{String.valueOf(dataId)})
          .withValue(Email.DATA, "somebody@android.com")
          .build());
 getContentResolver().applyBatch(ContactsContract.AUTHORITY, ops);
 </pre>
 </p>
 </dd>
 <dt><b>Delete</b></dt>
 <dd>
 <p>
 Just as with insert and update, deletion can be done either using the
 {@link ContentResolver#delete} method or using a ContentProviderOperation:
 <pre>
 ArrayList&lt;ContentProviderOperation&gt; ops =
          new ArrayList&lt;ContentProviderOperation&gt;();

 ops.add(ContentProviderOperation.newDelete(Data.CONTENT_URI)
          .withSelection(Data._ID + "=?", new String[]{String.valueOf(dataId)})
          .build());
 getContentResolver().applyBatch(ContactsContract.AUTHORITY, ops);
 </pre>
 </p>
 </dd>
 <dt><b>Query</b></dt>
 <dd>
 <p>
 <dl>
 <dt>Finding all Data of a given type for a given contact</dt>
 <dd>
 <pre>
 Cursor c = getContentResolver().query(Data.CONTENT_URI,
          new String[] {Data._ID, Phone.NUMBER, Phone.TYPE, Phone.LABEL},
          Data.CONTACT_ID + &quot;=?&quot; + " AND "
                  + Data.MIMETYPE + "='" + Phone.CONTENT_ITEM_TYPE + "'",
          new String[] {String.valueOf(contactId)}, null);
 </pre>
 </p>
 <p>
 </dd>
 <dt>Finding all Data of a given type for a given raw contact</dt>
 <dd>
 <pre>
 Cursor c = getContentResolver().query(Data.CONTENT_URI,
          new String[] {Data._ID, Phone.NUMBER, Phone.TYPE, Phone.LABEL},
          Data.RAW_CONTACT_ID + &quot;=?&quot; + " AND "
                  + Data.MIMETYPE + "='" + Phone.CONTENT_ITEM_TYPE + "'",
          new String[] {String.valueOf(rawContactId)}, null);
 </pre>
 </dd>
 <dt>Finding all Data for a given raw contact</dt>
 <dd>
 Most sync adapters will want to read all data rows for a raw contact
 along with the raw contact itself.  For that you should use the
 {@link android.provider.ContactsContract.RawContactsEntity}. See also {@link android.provider.ContactsContract.RawContacts}.
 </dd>
 </dl>
 </p>
 </dd>
 </dl>
 <h2>Columns</h2>
 <p>
 Many columns are available via a {@link android.provider.ContactsContract.Data#CONTENT_URI} query.  For best performance you
 should explicitly specify a projection to only those columns that you need.
 </p>
 <table class="jd-sumtable">
 <tr>
 <th colspan='4'>Data</th>
 </tr>
 <tr>
 <td style="width: 7em;">long</td>
 <td style="width: 20em;">{@link #_ID}</td>
 <td style="width: 5em;">read-only</td>
 <td>Row ID. Sync adapter should try to preserve row IDs during updates. In other words,
 it would be a bad idea to delete and reinsert a data row. A sync adapter should
 always do an update instead.</td>
 </tr>
 <tr>
 <td>String</td>
 <td>{@link #MIMETYPE}</td>
 <td>read/write-once</td>
 <td>
 <p>The MIME type of the item represented by this row. Examples of common
 MIME types are:
 <ul>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.StructuredName android.provider.android.provider.ContactsContract.CommonDataKinds.StructuredName.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.CommonDataKinds.Phone android.provider.CommonDataKinds.Phone.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Email android.provider.android.provider.ContactsContract.CommonDataKinds.Email.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Photo android.provider.android.provider.ContactsContract.CommonDataKinds.Photo.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Organization android.provider.android.provider.ContactsContract.CommonDataKinds.Organization.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Im android.provider.android.provider.ContactsContract.CommonDataKinds.Im.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Nickname android.provider.android.provider.ContactsContract.CommonDataKinds.Nickname.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Note android.provider.android.provider.ContactsContract.CommonDataKinds.Note.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.CommonDataKinds.StructuredPostal android.provider.CommonDataKinds.StructuredPostal.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.Contacts.GroupMembership android.provider.Contacts.GroupMembership.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Website android.provider.android.provider.ContactsContract.CommonDataKinds.Website.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Event android.provider.android.provider.ContactsContract.CommonDataKinds.Event.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.Relation android.provider.android.provider.ContactsContract.CommonDataKinds.Relation.CONTENT_ITEM_TYPE}</li>
 <li>{@link android.provider.ContactsContract.CommonDataKinds.android.provider.android.provider.ContactsContract.CommonDataKinds.SipAddress android.provider.android.provider.ContactsContract.CommonDataKinds.SipAddress.CONTENT_ITEM_TYPE}</li>
 </ul>
 </p>
 </td>
 </tr>
 <tr>
 <td>long</td>
 <td>{@link #RAW_CONTACT_ID}</td>
 <td>read/write-once</td>
 <td>The id of the row in the {@link android.provider.ContactsContract.RawContacts} table that this data belongs to.</td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #IS_PRIMARY}</td>
 <td>read/write</td>
 <td>Whether this is the primary entry of its kind for the raw contact it belongs to.
 "1" if true, "0" if false.
 </td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #IS_SUPER_PRIMARY}</td>
 <td>read/write</td>
 <td>Whether this is the primary entry of its kind for the aggregate
 contact it belongs to. Any data record that is "super primary" must
 also be "primary".  For example, the super-primary entry may be
 interpreted as the default contact value of its kind (for example,
 the default phone number to use for the contact).</td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #DATA_VERSION}</td>
 <td>read-only</td>
 <td>The version of this data record. Whenever the data row changes
 the version goes up. This value is monotonically increasing.</td>
 </tr>
 <tr>
 <td>Any type</td>
 <td>
 {@link #DATA1}<br>
 {@link #DATA2}<br>
 {@link #DATA3}<br>
 {@link #DATA4}<br>
 {@link #DATA5}<br>
 {@link #DATA6}<br>
 {@link #DATA7}<br>
 {@link #DATA8}<br>
 {@link #DATA9}<br>
 {@link #DATA10}<br>
 {@link #DATA11}<br>
 {@link #DATA12}<br>
 {@link #DATA13}<br>
 {@link #DATA14}<br>
 {@link #DATA15}
 </td>
 <td>read/write</td>
 <td>
 <p>
 Generic data columns.  The meaning of each column is determined by the
 {@link #MIMETYPE}.  By convention, {@link #DATA15} is used for storing
 BLOBs (binary data).
 </p>
 <p>
 Data columns whose meaning is not explicitly defined for a given MIMETYPE
 should not be used.  There is no guarantee that any sync adapter will
 preserve them.  Sync adapters themselves should not use such columns either,
 but should instead use {@link #SYNC1}-{@link #SYNC4}.
 </p>
 </td>
 </tr>
 <tr>
 <td>Any type</td>
 <td>
 {@link #SYNC1}<br>
 {@link #SYNC2}<br>
 {@link #SYNC3}<br>
 {@link #SYNC4}
 </td>
 <td>read/write</td>
 <td>Generic columns for use by sync adapters. For example, a Photo row
 may store the image URL in SYNC1, a status (not loaded, loading, loaded, error)
 in SYNC2, server-side version number in SYNC3 and error code in SYNC4.</td>
 </tr>
 </table>

 <p>
 Some columns from the most recent associated status update are also available
 through an implicit join.
 </p>
 <table class="jd-sumtable">
 <tr>
 <th colspan='4'>Join with {@link android.provider.VoicemailContract.StatusUpdates}</th>
 </tr>
 <tr>
 <td style="width: 7em;">int</td>
 <td style="width: 20em;">{@link #PRESENCE}</td>
 <td style="width: 5em;">read-only</td>
 <td>IM presence status linked to this data row. Compare with
 {@link #CONTACT_PRESENCE}, which contains the contact's presence across
 all IM rows. See {@link android.provider.VoicemailContract.StatusUpdates} for individual status definitions.
 The provider may choose not to store this value
 in persistent storage. The expectation is that presence status will be
 updated on a regular basis.
 </td>
 </tr>
 <tr>
 <td>String</td>
 <td>{@link #STATUS}</td>
 <td>read-only</td>
 <td>Latest status update linked with this data row.</td>
 </tr>
 <tr>
 <td>long</td>
 <td>{@link #STATUS_TIMESTAMP}</td>
 <td>read-only</td>
 <td>The absolute time in milliseconds when the latest status was
 inserted/updated for this data row.</td>
 </tr>
 <tr>
 <td>String</td>
 <td>{@link #STATUS_RES_PACKAGE}</td>
 <td>read-only</td>
 <td>The package containing resources for this status: label and icon.</td>
 </tr>
 <tr>
 <td>long</td>
 <td>{@link #STATUS_LABEL}</td>
 <td>read-only</td>
 <td>The resource ID of the label describing the source of status update linked
 to this data row. This resource is scoped by the {@link #STATUS_RES_PACKAGE}.</td>
 </tr>
 <tr>
 <td>long</td>
 <td>{@link #STATUS_ICON}</td>
 <td>read-only</td>
 <td>The resource ID of the icon for the source of the status update linked
 to this data row. This resource is scoped by the {@link #STATUS_RES_PACKAGE}.</td>
 </tr>
 </table>

 <p>
 Some columns from the associated raw contact are also available through an
 implicit join.  The other columns are excluded as uninteresting in this
 context.
 </p>

 <table class="jd-sumtable">
 <tr>
 <th colspan='4'>Join with {@link android.provider.ContactsContract.RawContacts}</th>
 </tr>
 <tr>
 <td style="width: 7em;">long</td>
 <td style="width: 20em;">{@link #CONTACT_ID}</td>
 <td style="width: 5em;">read-only</td>
 <td>The id of the row in the {@link android.provider.Contacts} table that this data belongs
 to.</td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #AGGREGATION_MODE}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.RawContacts}.</td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #DELETED}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.RawContacts}.</td>
 </tr>
 </table>

 <p>
 The ID column for the associated aggregated contact table
 {@link android.provider.ContactsContract.Contacts} is available
 via the implicit join to the {@link android.provider.ContactsContract.RawContacts} table, see above.
 The remaining columns from this table are also
 available, through an implicit join.  This
 facilitates lookup by
 the value of a single data element, such as the email address.
 </p>

 <table class="jd-sumtable">
 <tr>
 <th colspan='4'>Join with {@link android.provider.ContactsContract.Contacts}</th>
 </tr>
 <tr>
 <td style="width: 7em;">String</td>
 <td style="width: 20em;">{@link #LOOKUP_KEY}</td>
 <td style="width: 5em;">read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}</td>
 </tr>
 <tr>
 <td>String</td>
 <td>{@link #DISPLAY_NAME}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}</td>
 </tr>
 <tr>
 <td>long</td>
 <td>{@link #PHOTO_ID}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #IN_VISIBLE_GROUP}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #HAS_PHONE_NUMBER}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #STARRED}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>String</td>
 <td>{@link #CUSTOM_RINGTONE}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #SEND_TO_VOICEMAIL}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>int</td>
 <td>{@link #CONTACT_PRESENCE}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>String</td>
 <td>{@link #CONTACT_STATUS}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>long</td>
 <td>{@link #CONTACT_STATUS_TIMESTAMP}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>String</td>
 <td>{@link #CONTACT_STATUS_RES_PACKAGE}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>long</td>
 <td>{@link #CONTACT_STATUS_LABEL}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 <tr>
 <td>long</td>
 <td>{@link #CONTACT_STATUS_ICON}</td>
 <td>read-only</td>
 <td>See {@link android.provider.ContactsContract.Contacts}.</td>
 </tr>
 </table>
*/
var Data = {

/** The content:// style URI for this table, which requests a directory
 of data rows matching the selection criteria.
*/
CONTENT_URI : "null",
/** A boolean parameter for {@link android.provider.ContactsContract.Data#CONTENT_URI}.
 This specifies whether or not the returned data items should be filtered to show
 data items belonging to visible contacts only.
*/
VISIBLE_CONTACTS_ONLY : "visible_contacts_only",
/** The MIME type of the results from {@link #CONTENT_URI}.
*/
CONTENT_TYPE : "vnd.android.cursor.dir/data",
/**<p>
 Build a {@link android.provider.ContactsContract.Contacts#CONTENT_LOOKUP_URI}
 style {@link Uri} for the parent {@link android.provider.ContactsContract.Contacts}
 entry of the given {@link android.provider.ContactsContract.Data} entry.
 </p>
 <p>
 Returns the Uri for the contact in the first entry returned by
 {@link ContentResolver#query(Uri, String[], String, String[], String)}
 for the provided {@code dataUri}.  If the query returns null or empty
 results, silently returns null.
 </p>
*/
getContactLookupUri : function(  ) {},


};