07-14-2008 10:11 AM
Quote from previous forums:
|MIDP allows to read .jad files properties using the "getAppProperty" method. Is there anything alike it using RIM, that allows to modify it's properties without having to compile the project?|
The BlackBerry Bold 9000 supports reading jad file attributes using the MIDlet.getAppProperty method. Please see the link below for more information.
How To - Programmatically read the attributes of a JAD file
Solved! Go to Solution.
07-15-2008 01:03 PM
No, reading jad file attributes is not supported in BlackBerry handheld software version below 4.3
07-16-2008 10:28 AM
Just to clarify, programmatically reading the attributes added to a jad file after the application has been built is only available in versiomn 4.3.0 and higher.
If you add the jad file to your BlackBerry JDE project, add a custom attribute and then build your application the attribute is available to your application in versions prior to 4.3.0.
07-16-2008 10:38 AM
The most commonly deployed workaround is for the app to initiate a connection to the server on first run, requesting any configuration parameters. Another option is to set up the app as an SMS listener using PushRegistry (KB article below), receiving the configuration parameters as an SMS message.
07-16-2008 01:21 PM
They are not viable options. I was considering passing a string as an argument into main () and then parsing the information from the string
MIDlet-1: App Name, icon.png, pass this into the main method as an argument
Would that be a reliable situation?
I you also answer why the class to get the information from a jad in version 4.3 has to be signed and such functionality is only made available in that version when MIDlets have been able to do it unsigned from the start.
The example from the link above to get the jad information using 4.3 didn't work, I got a null pointer when I used myGroup.getProperty
07-16-2008 01:34 PM
Use of the MIDlet class should not require signing. The BlackBerry specific example would. What method are you using that is giving a NullPointException?
07-16-2008 02:59 PM
For the call to getProperty() returning null, are you running on a live device running 4.3 or higher where the app has actually been installed via an OTA download? I've created sample applications that are able to retrieve this information without error.
As for code signing, note that if your app is a MIDlet, then calling MIDlet.getAppProperty() does not require code signing. But, as you've noted, if your app extends the Application or UiApplication class, then yes, using CodeModuleManager will require code signing.
07-29-2008 04:41 PM
The only workaround I know of is to include a text file or a class/interface in the application itself with the right configuration info.
You can do this two ways:
1) Create a new sibling directory and copy the .jdp file for your project into that folder. Edit the .jdp copy and change all the references to your .java files (and any resources) to be relative to the new directory, i.e. "foo.java" becomes "..\myproject\foo.java". Do this for all files EXCEPT for the one resource/class that is going to be configuration-specific. That one will be local to the current directory. Now you essentially compile the project twice, and sign it twice, to end up with two different sets of .cod files.
2) The other approach is to isolate just the configuration stuff into its own library project and to clone that project. For example, you'd have a "Config1" project that would have a "com.mycompany.Config" interface with various settings. It would end up with its own .cod file, say config.cod. You'd then create "Config2" that had the identical class in it. Your main project would then be set to depend on Config1. At build time you'd compile up the other configuration projects as well, each would create config.cod. When deploying you'd just swap in the correct version of config.cod for whatever device you want to use.
The latter method is more elegant, but it requires another .cod file to be created for no particular reason. That said, the same method can also be used to isolate OS-dependent code into modules separate from the non-OS dependent stuff.
Been there, done that....