Hi all! I''ve been browsing these forums for a while but until now had nothing to post. I read the J2ME article and i''m trying to make a little game for my cellphone, but I can''t figure out how to open a file, read data from it, or write data to it (for save games and such). I looked at the API for DataInputStream, DataOutputStream, etc.... but i can''t figure out if its even the right class to use (since it takes a URL parameter instead of filename) Any help would be good, and i''d really appreciate an example of saving a string/char/int into a file and then reading them back. Thanks in advance.

To the best of my knowledge it is impossible to write a file in the J2ME environment, and you can only read a file which is contained in your JAR. A separate interface, the "record management system" (RMS), is provided so you can save information between sessions. InputStreams and OutputStreams are more useful for (a) working with HTTP connections as you''ve discovered and (b) this cool hack using pairs of ByteFooStream and DataFooStream that lets you pack/unpack data in a byte array, very useful for RMS stuff actually (since you read/write byte[]''s from the RMS).

So yeah, you want to look at class javax.microedition.rms.RecordStore and work from there.

You can read resource streams from the .jar, but apart from that, the only things that the java.io are used for is networking over HTTP and RMS

There is quite deliberately no API for reading local files on the device.

Mark

thanks for the answers.

edit: i found an article at http://www.microjava.com/articles/techtalk/rms so im reading it now.

just curious though.... why would they prevent you from writing to a file / creating a file/ etc... ?

thanks.

[edited by - Durath on May 8, 2004 4:32:13 AM]

Reasons they would not let you read/write files:

1. The device might not even have a filesystem per se (or it could be readonly).
2. The device may have files in the filesystem which no application should be able to read/write, otherwise it would cause the device to fail, or expose information the manufacturers don''t want to
3. The device will have limited storage available, the application should not be able fill it up and thus annoy the user
4. If the application (game) is removed from the device, the device MUST be able to clean up its files. If they are scattered all over the filesystem (ala Windows), this is difficult to impossible.
5. The native filesystem might not have good performance characteristics if files are repeatedly created/deleted, long filenames, deep directories, many files per directory etc.

Basically, it boils down to - it''s a small device, with limited capabilities and has to be pretty idiot-proof.

The reasons above, prevent the device from failing due to a faulty app, and ensure that the user can always just delete the game and reclaim its space.

Mark