Working with GCF on the 6600
File Connecton Optional Package
By definition, the 1.x versions of the series 60 developer platform were not required to provide filesystem access. On the other hand, the version 2.0 spec does mention a file manager. Unfortunately it seems the File Connection Optional Package (FCOP) has not been implemented in the Nokia 6600.
The recommended approach to access file system resources is via the generic connections framework, with a line of code such as:
Connection con = Connector.open("file:///filename");
What you get when you run the code is a java.lang.ClassNotFoundException. This indicates that the phone's KVM does not have required class. In this case is the FileConnection. This can be confirmed by trying out another line of code.
String v = System.getProperty(
When you go back to the S60 guide, you find that the references to file system access happen to berather vague. JCOP is not mentioned at all. Thus C++ may be the only way in which you can possible to read, write (and what not) on this phone. As the authors of fExplorer seems to have managed.
The browser and the HTTP Client
As already mentioned this phone has a superb browser. It's HTTPConnector does not seem all that bad either. I tested the system by retrieving using both the GET and POST methods. The good news is that they both methods seem to work fine. However it did seem that the HTTPConnection will refuse to connect to a web server running on a non standard port (the same holds true for the WTK emulator). This is something most people can live with.
Since HTTP support is nothing new, how to establish an HTTP connection is already well documented. Indeed it's something many J2ME developers are familiar with, but for the benefit of the newby who might favour this site with a visit here's how it works:
HttpConnection c = (HttpConnection)Connector.open(url);
When looking at the MMAPI I mentioned that the size of a record in the RMS is limited to about 128kb, to overcome this shortcoming, I decided to write the captured audio to the OutputStream of the HTTPConnection. The idea is that it would then facilitate a longer recording.
Unfortunately it didn't quite work out, it resulted in what would be called a buffer overflow in the C world but in this Java 2 Micro Enviorenement it resulted in a Symbina OS error. Apparently all the captured data is kept in memory before being written to the OutputStream in a single operation. This certainly is the way HTTPUrlConnection in the Standard Edition works. What should happen is that all the data should be written to disk as it's being captured but that does not seem to happen.
Another existing feature of the nokia 6600 is that it is among the very small number of phones that provide access to the bluetooth subsystem through java. Not being an expert in the bluetooth API, this features was checked out using Ben Hui's bluechat MIDlet, but I did manage to connect to other devices equipped with bluetooth radios.
Unfortunately at the time of writing none of the other Bluetooth phones that I have access to come equipped with the J2ME BT API (there's a mouthfull of abbreviations for you) so this study was some what restricted.
If you use the AMR format as discussed above, you may be able to make a longer recording because it is highly efficient when it comes to storage space. The PCM format takes up much for space. Since the available storage space is limited normally you change your WTK settings to match the capacity of the device. That does not work with audio capture since we are forced to work with different encoding when switching between the WTK and phone. You have to keep your fingures crossed that the storage space will not be exceeded.