Support for "Loadable Dictionaries" - using DictionaryforMIDs on devices with small JAR-sizes

 

Development done - but certificate sill missing

The development of the "Loadable Dictionaries" is basically complete (well, a few nice-to-have features still should be implemented).

But one thing is missing: the certificate for DictionaryForMIDs !

Certificate:

Because the file system is accessed for the "Loadable Dictionaries", the DictionaryForMIDs application needs to be signed with a certificate. Otherwise, on most devices, the user will be prompted a confirmation dialogue each time when a file is accessed. For detailed technical information on this see the Recommended Security Policy for GSM/UMTS devices.

It needs to be checked whether somehow DictionaryForMIDs can obtain a certificate under conditions that are suitable for an Open Source project. A commercial certificate is expensive, for example a VeriSign code signing certificate costs about $500 per year, and unless there is a generous donor, the DictionaryForMIDs project cannot obtain such a commercial certificate.

 

General Background on "Loadable Dictionaries"

Many entry level cell phone models support only small JAR-file sizes, for example a few hundred kB. The dictionaries files that are incorporated into the DictionaryForMIDs_xxx.jar application JAR-file are often a few MB in size, so these dictionaries cannot be installed on those models.

But usually there are several MB of free space in the file system of the cell phone ! So let's put the dictionary there !

Basically all new models that appear on the market support JSR 75, including Nokias popular Series 40 3rd edition. JSR 75 specifies a portable way of accessing the file system of a cell phone/PDA. By using the JSR 75, the DictionaryForMIDs_xxx.jar-file (this file contains the dictionary files) can be put in the file system of the phone and the dictionary files can be read from there. The DictionaryForMIDs_empty.jar (application JAR-file) does contain only the program code and is much smaller.
 

Accessing the file system - already implemented !

The access to the file system is already implemented since version 3.1.0. The class JSR75InputStream does the access via the JSR75 API. All other relevant classes have also been extended, so that by now there is a working framework for accessing the files in the file system. For how to use the current implementation, the FAQ.
 

Implementing a 'file selection' dialogue - already implemented !

Joshua did implement a simple file selection dialogue to let the user select a JAR file: The user is be able to pick within DictionaryForMIDs a DictionaryForMIDs_xxx.jar-file that he downloaded from the dictionary download page and did copy on the file system of his cell phone/PDA.
 

Reading the JAR-files - already implemented !

Joshua did use the GNU Classpath ZIP-Library for reading JAR-files from DictionaryForMIDs (JAR files use the file ZIP format). Based on this he implemented the class ZipInputStreamAccess. All this really works fine ! But some performance optimization is needed, read below.
 

 

Remaining improvements

1. No restart of DictionaryForMIDs after selecting a dictionary
2. Performance optimization for reading the dictionary data files when the user selects a JAR file

1. No restart of DictionaryForMIDs after selecting a dictionary

Currently, DictionaryForMIDs needs to be restarted after a dictionary is selected in the file browser. This is annoying for the user and the implementation needs to be improved so that this restart is not necessary.

2. Performance optimization for reading the dictionary data files when the user selects a JAR file

The reading of the JAR files is too slow when the JAR file is parsed for each translation !

Here is the reason: ZipInputStreamAccess uses from the Classpath ZIP-Library mainly the ZipInputStream class. Using ZipInputStream causes the JAR file to be decompressed to the point until a certain file is found. As an example, for read a 50 kB file maybe 2 MB of the JAR file have to be decompressed.

Here is the solution 1 (Gert's preferred solution): When the dictionary is selected, uncompress the JAR file and write the plain dictionary data files to the file system; then for each translation access those dictionary files directly in the file system - and the translation speed will be "fantastic" !

Here is the solution 2: Us the class ZipFile ! With ZipFile a file is directly accessed in the JAR file without decompressing all previous files. Unfortunately the implementation of GNU Classpath ZipFile.java needs Jave SE classes for random file access. So ZipFile.java will not compile directly in Java ME. Fortunately in Java ME the random file access can easily be achieved by using an InputStream and the skip method (the InputStream may need to be reopened before skip is called). So adapting ZipFile.java to Java ME should not be too much work.

A remark at the side: the DictionaryForMIDs JAR files are several MB in size, so one-time loading of the complete JAR file on the heap is not a working solution for most devices.
Second remark: Joshua also points to http://www.jcraft.com/jzlib/ which may is an alternative to the GNU Classpath implementation (this library should work with Java ME).
 

Who can do this important job ? Support is assured via the DictionaryForMIDs forum !!

 

Questions or comments ?

As always, contact us if you have questions !