08-03-2011 04:35 PM - edited 08-03-2011 04:40 PM
I have some issues building my BlackBerry Java Application (consists of 4 modules)
It all started when I tried to bundle a 14MB file to the one of my modules. The complier wasn't able to build my app throwing a exception "Fatal Internal error: java.lang.NullPointerException - this was not a compile time error, it was a Run-Time error coming from the compiler itself.
I tried to research this problem and found the following KB article from RIM:
The article says that the maximum size of my application can be not more than 14000KB and also that the limit for the number of sibling COD files that can exist within a single application is 127. The second part of this stetement is confusing since it is not clear if it's referring to maximum number of COD files for the whole application of just for a single module, i.e. does it mean that I can have not more than 127 per every module I have in my app (so it's 4*127 total), or the total number of all CODs I have in my app (for all 4 modules) should be not more than 127.
Anyway, I've reduced the size of my 14 MB file down to 5.5 MB and now I'm able to build the application, but I'm still unable to run it.
The results of my further experiments confused me even more - here they are:
Total Number of CODs
Number of CODs in the biggest module (contains that file)*
6.0/7.0 – Class ‘net.rim.device.api.crypto.SHA1Digest’ not found
5.0 – Class ‘javax.wireless.messaging.MessageConnection’ not found
Javaloader Error loading Module:
The specified module was rejected by the device and cannot be loaded
*-Other 3 modules always had the same total numbers of CODs – 35.
The first (4000KB) and the last (6000KB) experiments make sense to me (assuming that ‘rejected by the device’ error is due to the number of CODs (128) in my module), however I’m totally puzzled by the second (4400KB) and third (5500KB). The second one has the total number of CODs for the app greater than 127 – 130, however it builds just fine. The third one has the total number of CODs greater than 127, but the number of CODs in the biggest module is less than 127, however it does not start. I know that the “Class … not found” exception could be thrown when I run on the device that has an OS version lower than the JDE complier version I used. This is not the case here.
I believe that I’m hitting some limit with my file and the number of CODs that it's generating. Does anyone know what this limit is???
08-03-2011 07:43 PM
Sorry, I can't help here, I have found that the size of cods can depend on the JDE level you are building as well.
Can we attempt to persuade you that this approach is the wrong way to try to package data fro the device? Does it really need to be included in a cod file?
08-04-2011 11:13 AM
Peter, do you mean 'Startup Tier' when you say JDE level? Or you mean the OS version (5.0, 6.0)?
Our app needs to have an essential configuration component during the first time it starts up. Until now we've been downloading it OTA during the start-up time (splash screen) and saving it to device's SDCard memory space, so no impact was done to device's Application memory.
This approach works just fine, however it has two potential disadvantages that some of our customers didn't like:
- Startup time (if that component is downloaded OTA - startup time might be as long as 30 secs - 1 min)
- Cost of data
Our solution was to provide an option to include this component during the build time. That's why we believe it HAS to be included in a cod file. It works just fine for our other platforms (iOS, Android), so we want to have similar functionality with our BB client as well.
We know that large COD files can take some device's Application memory space and potentially slow down the device or prevent the normal operations of the existing apps (like email). Unfortunately at this point we can't think of any other way of accomplishing what we want....
08-04-2011 12:58 PM
I mean OS Level. Take the same code and build for 4.2, 4.5, 4.6, 5.0. 6.0 and you will have 5 different sized cods, with 6.0 being the biggest.
I understand your concern. The fact that Application memory on the Blackberry device has caused a number of restrictions and this is really one of them. However the disadvantage with including the file with the application is that it always takes up application space, which might be better used for other things.
The only option I can think of is to use a resource cod, which the user downloads as well as your application, and then runs. It basically copies the contained resources out of itself onto the SD Card and then deletes it self. I use this for something I do and a sample of this is here: