Java Development

[MSohm]

Quote from previous forums:

---

Guest: Willy	Can I use getAppProperty on BlackBerry 9000 Posted: Jul 11, 2008 3:41 PM	Reply
	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

DB-00638

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800708/800646/How_To_...

[ianstrain]

What about before 4.3? Is it possible? Have you any work arounds if it is not?

[MSohm · Accepted solution]

No, reading jad file attributes is not supported in BlackBerry handheld software version below 4.3

[ianstrain]

well any work arounds then?

[MSohm]

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. 

[bzubert]

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. 

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800332/800429/How_To_... 

[ianstrain]

They are not viable options. I was considering passing a string as an argument into main () and then parsing the information from the string

eg.

Jad file

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

[MSohm]

Use of the MIDlet class should not require signing.  The BlackBerry specific example would.  What method are you using that is giving a NullPointException?

[bzubert]

Ian,

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. 

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800708/800646/How_To_...

[EricGiguere]

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....