how to define where to put dictionary?

Started by mikezang, 31. July 2009, 03:47:54

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

mikezang

I am using a Sharp 932SH mobile phone, it doesn't support JSR75, but has another file access system, then the JSR file size has a 1M limitation, so that I have to use Loadable Dictionary.

My 1st Question is where I have to put dictionary file? and how to config it?  I try to use English - Chinese.

2nd question is where I can find more detail information about source, because I try to show Chinese text file in my Japanese mobile phone.

Thanks for your advise.

mikezang

Gert

A modern phone which does not support JSR-75 ? This would be the first modern model that I have heard of which does not support JSR-75.

Well, ok concerning your 1st question: if JSR-75 is not supported, then loadable dictionaries will not work; if your phone really does not support JSR-75 (which seems very unusual for me), then the file system access would have to be implemented with whatever API your phone supports to access files.

Concerning your 2nd question: for development, also source, just see http://dictionarymid.sourceforge.net/development.html

Note that DictionaryForMIDs supports Bitmap Fonts, which allow to show Chinese characters with any mobile, even if Chinese characters are not supported by the device.

Best greetings,
Gert

mikezang

Thanks for your answer.

it seems that my message is not so clearly, my phone can access file system with com.j_phone.io.StorageConnection, but it doesn't sopport javax.microedition.io.file, so I can't compile source.

I try to make a adapter class to wrap com.j_phone.io.StorageConnection, do you have any idea?

I read your source and http://dictionarymid.sourceforge.net/development.html, I want to know if there is any else information about classes for using bitmap fonts, can you help me?

Best regards

mikezang

Gert

Ah, thanks, now I do understand you problem better.

Thanks to the well-modularized architecture of DictionaryForMIDs :D it is very easy to add support for the file system access based on any other Java API. In DfM we already have support for Java ME JSR-75, Java SE, Android and some 'variations'. Approx. 3 lines of code and you will be done.

I even did write a documentation how to add file system access for additional platforms ... just that right now I can't remember where it is :( Ok, I will search.

BitmapFonts are documented at http://dictionarymid.sourceforge.net/bitmapfont.html. If the existing information should not be sufficient for you, then you should contact Sean.

Greetings !
Gert

Gert

#4
I just added a short description in the section "Implementing file access for new Java platforms" of http://dictionarymid.sourceforge.net/development.html.

Hope that helps !

Gert

mikezang

I will try to use my file system and Bitmap font for my application.

By the way, I have another question, why didn't you put links on left of menu for
http://dictionarymid.sourceforge.net/development.html
http://dictionarymid.sourceforge.net/bitmapfont.html

Thanks a lot.

mikezang

Gert

QuoteBy the way, I have another question, why didn't you put links on left of menu for
http://dictionarymid.sourceforge.net/development.html
http://dictionarymid.sourceforge.net/bitmapfont.html

Well, our web designers suggested not to include too many items in the navigator pane on the left.

Ok, happy development !
Gert

mikezang

I just downloaded source for JavaME version, the package javax.microedition.io.file.FileConnection is still needed, I thought this package is not standard in MIDP2.0, is it right?

I thought that I don't need that package when I got your reply message, it seems that I have to make a adapter class to wrap my device API to use package javax.microedition.io.file.FileConnection, may I meke sense?

Best regards
mikezang

Gert

You do not need javax.microedition.io.file.FileConnection; neither the source nor the class files; just write your implementation of DfMInputStreamAccess as described in the section "Implementing file access for new Java platforms"

Gert

mikezang

I am sorry that I am not sure about  DictionaryForMIDs, because it is little complex:)

I copied some sources that can't be compiled as below, even I implement DfMInputStreamAccess, it can't be compiled, so do I have to delete some source files?

in de.kugihan.dictionaryformids.dataaccess.fileaccess.JSR75InputStreamAccess.java
de.kugihan.dictionaryformids.dataaccess.fileaccess.ZipInputStreamAccess.java
import javax.microedition.io.file.FileConnection;

in de.kugihan.dictionaryformids.hmi_java_me.filebrowser.FileBrowser.java
import javax.microedition.io.file.FileConnection;
import javax.microedition.io.file.FileSystemRegistry;


in de.kugihan.dictionaryformids.hmi_java_me.DictionarySettingForm.java
import javax.microedition.io.file.FileSystemRegistry;



Gert

Ok, I see your problems.

Let me try to back up: DictionaryForMIDs has been implemented for different Java platforms (actually there is also a Windows Mobile implementation in C++, but let's ignore that for the moment). These Java platforms share the common Translation Layer and the Data Access Layer, as described at http://dictionarymid.sourceforge.net/development.html.

For each of the different Java platforms, the HMI Layer was implemented specifically for that Java platform, additionally also the file access via DfMInputStreamAccess. For example the Java SE and the Java ME implementations each bring their own source for the HMI Layer, and also their own source for the file access.

The error messages that you list below come from compiling the Java ME source, that part that accesses the JSR-75 API.

Now, I do not really understand the capabilities of your platform. I understood that JSR-75 is not supported; my first question is whether MIDP-2.0 is supported ? If not, then there should be plenty of additional error messages.

And, my second question, I would like to know the development environment / compiler that you are using.

Even if JSR-75 is not supported on your mobile, if you compile with a Java ME development environment such as the Sun SDK, then simply switch on the support for JSR-75, so that the source will compile fine. At runtime (when DfM is started on your device) then there is a detection if the device supports JSR-75. If not, no calls are made for the JSR-75 API.

If your development environment does not support JSR-75, then just uncomment all calls to the JSR-75 API; or as you suggest delete the files that use JSR-75 (you will however have to uncomment the code that makes use of those deleted classes).

Regards,
Gert





mikezang

#11
Thanks for your detail explaination.

My device supports MIDP2.0, but uses com.j_phone.io.StorageConnection for file access.

So I can delete all files that use FileConnection, then implement class to use StorageConnection, is it right?

Another idea is to make a adapter FileConeection, do you think what idea is better and simple?

Gert

What development environment are you using ?

Gert

Gert

Besides, deleting the files is probably not a good solution because DictionarySettingForm is an important class.

Instead, I suggest that you leave the files and uncomment all references to the JSR-75 API. That should not be much more than 10 lines.

Gert

mikezang

I am using eclipse3.5 and netbeans6.7 with my device's emulator, can this help you?