FileConnection interface considerations

While the FileConnection interface extends Connection and objects are created using the Generic Connection Framework (GFC), there are some important differences with respect to other commonly used Connection implementations. One of the most important differences is that a call to Connector.open() can be successful even if the file doesn't currently exist. This is necessary when creating new files or directories. Nevertheless, it is illegal to open an InputStream to a non-existing file.

Another difference is that a FileConnection can remain open after the input or output streams are closed. Hence, it is important to call the FileConnection.close() method after the file has been accessed and thus ensure that it is available for other applications. In a related matter, modifications to a file using the OutputStream are not necessarily visible immediately by the file system. This depends on the actual implementation and the device's operating system. The flush() method ensures that any buffer is cleared and its contents written to the actual file.

An extra disparity with other Connection objects is that a FileConnection object can be reused using the setFileConnection() method. This method is mainly meant for doing directory traversal. The idea is that having built a FileConnection on a particular directory, the list() method can be called to obtain an enumeration of the child files and directories (files or directories existing within the original directory). The members of this enumeration can be passed to setFileConnection() as an argument, and then the original FileConnection points to this newly specified child file or directory. Basically, the argument of setFileConnection() is a relative path to another child file or directory already existing or the ".." argument for the upper directory.

One general consideration that has been highlighted for all kinds of I/O operations is that they should be performed in a different thread than the GUI thread. The same recommendation applies when using the FC API. This is highlighted when considered that due to the security framework, file-related operations could generate user prompts to authorize them. If an I/O operation is executed in the GUI thread and a user prompt is needed, the MIDlet may deadlock.