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
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 (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
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
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 (http://dictionarymid.sourceforge.net/bitmapfont.html). If the existing information should not be sufficient for you, then you should contact Sean.
Greetings !
Gert
I just added a short description in the section "Implementing file access for new Java platforms" of http://dictionarymid.sourceforge.net/development.html (http://dictionarymid.sourceforge.net/development.html).
Hope that helps !
Gert
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
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
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
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
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;
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 (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
Thanks for your detail explaination.
My device supports MIDP2.0, but uses com.j_phone.io.StorageConnection (http://notitle.net/vappli/doc/P5/com/j_phone/io/StorageConnection.html) 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?
What development environment are you using ?
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
I am using eclipse3.5 and netbeans6.7 with my device's emulator (http://wakoopa.com/software/softbank-mexa-emulator), can this help you?
Where do the CLDC and MIDP Jar-files come from ? From NetBeans ?
Gert
I use device's library, you can find it in attachment.
Hmmm, this is interesting for me. Is this library part of an SDK (Software Development Kit) or similar ? Maybe there is some non-Japanese documentation for this ? All that I could find on the internet till now is Japanese ... ok I'd like to learn some Japanese, but this would probably take me 20 years ;)
Anyway, thanks to your posting I detected that in DictionarySettingsForm the "import javax.microedition.io.file.FileSystemRegistry" is misplaced; I just removed that line and committed the updated DictionarySettingsForm to the SVN repository, see http://dictionarymid.svn.sourceforge.net/viewvc/dictionarymid/trunk/JavaME/src/de/kugihan/dictionaryformids/hmi_java_me/DictionarySettingForm.java?view=markup (http://dictionarymid.svn.sourceforge.net/viewvc/dictionarymid/trunk/JavaME/src/de/kugihan/dictionaryformids/hmi_java_me/DictionarySettingForm.java?view=markup)
The following files you can delete without problems:
in de.kugihan.dictionaryformids.dataaccess.fileaccess.JSR75InputStreamAccess.java
de.kugihan.dictionaryformids.dataaccess.fileaccess.ZipInputStreamAccess.java
Concerning: de.kugihan.dictionaryformids.hmi_java_me.filebrowser.FileBrowser.java probably the easiest is if you uncomment the calls to the JSR-75 API in this file.
Ok, I will read the forum again tomorrow.
Best regards,
Gert
You are right, that lib is from my device's SDK. I don't think there will have more English information about MEXA API, because such device are only for Japanese market.
Now I deleted SR75InputStreamAccess.java and ZipInputStreamAccess.java, then I commented import for FileConnection, so void showCurrDir() can't be used as it uses FileConnection currDir = null;
What can I do?
Put in this file all lines in comments that use the JSR-75 API. Of course, same with all other code that causes problems with relation to this.
Gert
I also commented in file FileBrowser.java as below:
void showCurrDir() {
// Enumeration e;
// FileConnection currDir = null;
// try {
// setTitle(currDirName);
// deleteAll();
// if (MEGA_ROOT.equals(currDirName)) {
// e = FileSystemRegistry.listRoots();
// } else {
// currDir = (FileConnection)Connector.open("file://localhost/" + currDirName, Connector.READ);
// e = currDir.list();
// not root - draw UP_DIRECTORY
// append(UP_DIRECTORY, dirIcon);
// append(CURRENT_DIRECTORY, dirIcon);
// }
//
// while (e.hasMoreElements()) {
// String fileName = (String)e.nextElement();
//
// if (fileName.charAt(fileName.length() - 1) == SEP) {
// // This is directory
// append(fileName, dirIcon);
// } else {
// // this is regular file
// append(fileName, fileIcon);
// }
// }
// if (currDir != null) {
// currDir.close();
// }
// } catch (IOException ioe) {
// ioe.printStackTrace();
// }
}
now compile is ok, but even I run it, only display "No Dictionary loaded".
I am still not sure how to implement what you said in section "Implementing file access for new Java platforms"? Csn you show me more detail?
Thanks a lot.
mikezang
You have to enter the "Dictionary path" in the Settings dialoge, see FAQ for more links on the loadable dictionaries.
Since you deactivated the File Browser, you will have to enter the "Dictionary path" manually.
Concerning "Implementing file access for new Java platforms"; maybe it helps if you look at the existing implementations of DfMInputStreamAccess.
Gert
There is no Dictionary Path item in my settings when I run it, do you know why?
You are right ! In DictionarySettingsForm (http://dictionarymid.svn.sourceforge.net/viewvc/dictionarymid/trunk/JavaME/src/de/kugihan/dictionaryformids/hmi_java_me/DictionarySettingForm.java?view=markup (http://dictionarymid.svn.sourceforge.net/viewvc/dictionarymid/trunk/JavaME/src/de/kugihan/dictionaryformids/hmi_java_me/DictionarySettingForm.java?view=markup)) this field is only shown if the dictionary data files are accessed via JSR-75:
// Path to dictionary
211 if (DictionarySettings.isUseFileAccessJSR75()) {
212 DictionarySettings.setDictionaryPath(SettingsStore.getSettingsStore().getDictionaryPath());
213 }
So you need to deactivate the if-statement in line 211.
In cases such as these, please 'just help yourself' ;) Please have a look at the source when something does not work as expected, and try to correct the problem yourself. If you really get stuck, then make a posting and I can support you.
Gert
I modified source and now I can get title screen and settings form, I also found some bugs (I think so) in source and modified them.
The problem is no any Chinese is displayed, though menu can be displayed in Chinese. check another thread (http://dictionarymid.sourceforge.net/forum/index.php?topic=152.0) what I put with some pictures.
Do you have any suggestion?