| java.lang.Object | |
| ↳ | android.os.FileObserver |
Monitors files (using inotify)
to fire an event after files are accessed or changed by by any process on
the device (including this one). FileObserver is an abstract class;
subclasses must implement the event handler onEvent(int, String).
Each FileObserver instance monitors a single file or directory. If a directory is monitored, events will be triggered for all files and subdirectories inside the monitored directory.
An event mask is used to specify which changes or actions to report. Event type constants are used to describe the possible changes in the event mask as well as what actually happened in event callbacks.
Warning: If a FileObserver is garbage collected, it will stop sending events. To ensure you keep receiving events, you must keep a reference to the FileObserver instance from some other live object.
| Constants | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| int | ACCESS | Event type: Data was read from a file | |||||||||
| int | ALL_EVENTS | Event mask: All valid event types, combined | |||||||||
| int | ATTRIB | Event type: Metadata (permissions, owner, timestamp) was changed explicitly | |||||||||
| int | CLOSE_NOWRITE | Event type: Someone had a file or directory open read-only, and closed it | |||||||||
| int | CLOSE_WRITE | Event type: Someone had a file or directory open for writing, and closed it | |||||||||
| int | CREATE | Event type: A new file or subdirectory was created under the monitored directory | |||||||||
| int | DELETE | Event type: A file was deleted from the monitored directory | |||||||||
| int | DELETE_SELF | Event type: The monitored file or directory was deleted; monitoring effectively stops | |||||||||
| int | MODIFY | Event type: Data was written to a file | |||||||||
| int | MOVED_FROM | Event type: A file or subdirectory was moved from the monitored directory | |||||||||
| int | MOVED_TO | Event type: A file or subdirectory was moved to the monitored directory | |||||||||
| int | MOVE_SELF | Event type: The monitored file or directory was moved; monitoring continues | |||||||||
| int | OPEN | Event type: A file or directory was opened | |||||||||
| Public Constructors | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Equivalent to FileObserver(path, FileObserver.ALL_EVENTS).
| |||||||||||
Create a new file observer for a certain file or directory.
| |||||||||||
| Public Methods | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
The event handler, which must be implemented by subclasses.
| |||||||||||
Start watching for events.
| |||||||||||
Stop watching for events.
| |||||||||||
| Protected Methods | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Invoked when the garbage collector has detected that this instance is no longer reachable.
| |||||||||||
|
[Expand]
Inherited Methods | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
From class
java.lang.Object
| |||||||||||
Event type: Data was read from a file
Event mask: All valid event types, combined
Event type: Metadata (permissions, owner, timestamp) was changed explicitly
Event type: Someone had a file or directory open read-only, and closed it
Event type: Someone had a file or directory open for writing, and closed it
Event type: A new file or subdirectory was created under the monitored directory
Event type: A file was deleted from the monitored directory
Event type: The monitored file or directory was deleted; monitoring effectively stops
Event type: Data was written to a file
Event type: A file or subdirectory was moved from the monitored directory
Event type: A file or subdirectory was moved to the monitored directory
Event type: The monitored file or directory was moved; monitoring continues
Event type: A file or directory was opened
Equivalent to FileObserver(path, FileObserver.ALL_EVENTS).
Create a new file observer for a certain file or directory.
Monitoring does not start on creation! You must call
startWatching() before you will receive events.
| path | The file or directory to monitor |
|---|---|
| mask | The event or events (added together) to watch for |
The event handler, which must be implemented by subclasses.
This method is invoked on a special FileObserver thread.
It runs independently of any threads, so take care to use appropriate
synchronization! Consider using post(Runnable) to shift
event handling work to the main thread to avoid concurrency problems.
Event handlers must not throw exceptions.
| event | The type of event which happened |
|---|---|
| path | The path, relative to the main monitored file or directory, of the file or directory which triggered the event |
Start watching for events. The monitored file or directory must exist at this time, or else no events will be reported (even if it appears later). If monitoring is already started, this call has no effect.
Stop watching for events. Some events may be in process, so events may continue to be reported even after this method completes. If monitoring is already stopped, this call has no effect.
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.