Reducing Need to Reopen Zip Streams

[zz85]

Opening Zipstream Once
Fri, May 11, 2007 at 12:45 AM

Hi Gert,

couple of days ago I managed to get DFM running using a zipped dictionary (I created ZipInputStreamAccess implemented using ZipInputStream extending DfMInputStreamAccess). Its advantage in this case is that the dictionary uses much less space on the phone. I noted is this implementation that when ever a csvFile, its calls the underlying InputStreamAccess.. Then ZipInputStreamAccess would try to seek through the file till its searches the file and open its stream.

Now the question, is there anyway you would know that could move back the inputstream - sort of a random access file, go back to start of zip file or reset the stream (stream.reset() doesn't work).
Otherwise is there a way to cache the files which are read out of the zip file? If not, each time I need to reopen the stream to the zipped file, another security promoted will appear.

Now I am looking at ReadManiac codes if they have a better implementation because when I trying their software, I see I could fast forward and backward a file without any file access warnings.

Joshua

Fri, May 11, 2007 at 1:03 AM

Looking thru ReadManiac code, seems they uses a File class

However http://developers.sun.com/techtopics/mobility/apis/ttips/fileconnection/ mentions this is a Optional Package..

How well do JSR-75 phones support this feature? com.sun.midp.io.j2me.storage.File

Hallo Joshua !



What, you already managed to (partly) access a zipped dictionary ? I thought that would be much more effort !



Well, that's the restriction, there is no random file access as far as I know. Right, a stream.reset() won't help. So the only way that I know to do a stream.seek(pos) (for positioning at byte number post) is to re-open the stream and do a stream.skip – and hope that the skip is implemented efficiently !! With the drawback of the security prompts as you write; well we'll need to get a certification anyway, I believe.



Caching is a good idea also for performance improvement ! For example the zip file's file table (where all the file names and their position is stored) might be a good candidate for caching. Also, the searchlist files are read for each translation and might be a good candidate for caching. In any case, I am not aware of any caching class that is provided in Java ME you would have to implement it yourself. I once tried to write a simple caching myself (I think I did put it in CsvFile.java), but I never really completed it.



Hope in the end your will find a way to get things work !



Besides: posting in the forum might help to get an advice from other people ...



Gert

> However http://developers.sun.com/techtopics/mobility/apis/ttips/fileconnection/ mentions this is a Optional Package..

Well, that is JSR 75 !!



> How well do JSR-75 phones support this feature? com.sun.midp.io.j2me.storage.File

What is com.sun.midp.io.j2me.storage.File ? Never heard about that.



Gert

[zz85]

Does anyone knows the memory limit a midlet can use? We could perhaps store the search index in the memory.. Or maybe the RMS (my impression its limited to about 64k)..

[Gert]

In general the space from the RMS is less than the heap. Also RMS tends to be rather slow. Of course this differs from device to device.

For the available heap space, there is a good database at j2mepolish.org.

There is also a method where you can inquire the free and the total available heap space. DfM does do this in a memory log function of Util.java.

Gert