IT. Expert System.

Android Reference


Class BackupDataOutput

  • public class BackupDataOutput
    extends Object
    Provides the structured interface through which a BackupAgent commits information to the backup data set, via its onBackup() method. Data written for backup is presented as a set of "entities," key/value pairs in which each binary data record "value" is named with a string "key."

    To commit a data record to the backup transport, the agent's onBackup() method first writes an "entity header" that supplies the key string for the record and the total size of the binary value for the record. After the header has been written, the agent then writes the binary entity value itself. The entity value can be written in multiple chunks if desired, as long as the total count of bytes written matches what was supplied to writeEntityHeader().

    Entity key strings are considered to be unique within a given application's backup data set. If a backup agent writes a new entity under an existing key string, its value will replace any previous value in the transport's remote data store. You can remove a record entirely from the remote data set by writing a new entity header using the existing record's key, but supplying a negative dataSize parameter. When you do so, the agent does not need to call writeEntityData(byte[], int).


    Here is an example illustrating a way to back up the value of a String variable called mStringToBackUp:

     static final String MY_STRING_KEY = "storedstring";
     public void onBackup(ParcelFileDescriptor oldState, BackupDataOutput data, ParcelFileDescriptor newState)
             throws IOException {
         byte[] stringBytes = mStringToBackUp.getBytes();
         data.writeEntityHeader(MY_STRING_KEY, stringBytes.length);
         data.writeEntityData(stringBytes, stringBytes.length);
    See Also:
    • Constructor Detail

    • Method Detail

      • writeEntityHeader

        public int writeEntityHeader(String key,
                            int dataSize)
                              throws IOException
        Mark the beginning of one record in the backup data stream. This must be called before writeEntityData(byte[], int).
        key - A string key that uniquely identifies the data record within the application
        dataSize - The size in bytes of this record's data. Passing a dataSize of -1 indicates that the record under this key should be deleted.
        The number of bytes written to the backup stream
        IOException - if the write failed
      • writeEntityData

        public int writeEntityData(byte[] data,
                          int size)
                            throws IOException
        Write a chunk of data under the current entity to the backup transport.
        data - A raw data buffer to send
        size - The number of bytes to be sent in this chunk
        the number of bytes written
        IOException - if the write failed
      • setKeyPrefix

        public void setKeyPrefix(String keyPrefix)
      • finalize

        protected void finalize()
                         throws Throwable
        Description copied from class: Object
        Invoked when the garbage collector has detected that this instance is no longer reachable. The default implementation does nothing, but this method can be overridden to free resources.

        Note that objects that override finalize are significantly more expensive than objects that don't. Finalizers may be run a long time after the object is no longer reachable, depending on memory pressure, so it's a bad idea to rely on them for cleanup. Note also that finalizers are run on a single VM-wide finalizer thread, so doing blocking work in a finalizer is a bad idea. A finalizer is usually only necessary for a class that has a native peer and needs to call a native method to destroy that peer. Even then, it's better to provide an explicit close method (and implement Closeable), and insist that callers manually dispose of instances. This works well for something like files, but less well for something like a BigInteger where typical calling code would have to deal with lots of temporaries. Unfortunately, code that creates lots of temporaries is the worst kind of code from the point of view of the single finalizer thread.

        If you must use finalizers, consider at least providing your own ReferenceQueue and having your own thread process that queue.

        Unlike constructors, finalizers are not automatically chained. You are responsible for calling super.finalize() yourself.

        Uncaught exceptions thrown by finalizers are ignored and do not terminate the finalizer thread. See Effective Java Item 7, "Avoid finalizers" for more.

        finalize in class Object


Android Reference

Java basics

Java Enterprise Edition (EE)

Java Standard Edition (SE)





Java Script








Design patterns

RFC (standard status)

RFC (proposed standard status)

RFC (draft standard status)

RFC (informational status)

RFC (experimental status)

RFC (best current practice status)

RFC (historic status)

RFC (unknown status)

IT dictionary

All information of this service is derived from the free sources and is provided solely in the form of quotations. This service provides information and interfaces solely for the familiarization (not ownership) and under the "as is" condition.
Copyright 2016 © ELTASK.COM. All rights reserved.
Site is optimized for mobile devices.
Downloads: 92 / 159524751. Delta: 0.04729 с