09-16-2010 03:36 PM
Here's the RIM documentation for Class.getResourceAsStream():
RIM Implementation Notes: This method searches for the resource starting from the directory in which the current project's JDP file resides. By default, it is assumed that this JDP file resides in the parent directory of the current project's package space. Thus, the package space directory structure (e.g., com/rim/package_name) is prepended to name so that the search begins relative to this package space, i.e., in the current project's source directory. However, if the current project's JDP file does not reside in its assumed location, the above behaviour will prevent the resource from being found. In this case, the user should prepend a forward slash (/) to the resource name before calling getResourceAsStream. This treats name as an absolute path, which is compared with a tree rooted at the location of the JDP file.
This is terribly confusing (when getResourceAsStream executes, it's not on the user's development machine and neither the JDP file nor the project source directory are accessible) and is certainly wrong for the Eclipse plug-in, which has done away with JDP files. Unfortunately, this excerpt is from the latest and greatest OS 6 docs.
Is there any more coherent explanation of the search path that getResourceAsStream uses? Some realistic examples of different cases, that show when a leading '/' is needed, when to add a path prefix, etc., would be very helpful. A recent post described a way to open an input stream to a resource in another module, since getResourceAsStream() does not seem to work for that:
ContentConnection cc = (ContentConnection)Connector.open("cod://module/pa
Is this recommended? Or is there perhaps a way for getResourceAsStream() to search dependent .cod files the way that Bitmap.getBitmapResource() does?
Solved! Go to Solution.
09-21-2010 02:21 PM
The cod:// protocol is not supported.
Class.getResourceAsStream essentially accepts a file path that points to a file packaged within your COD file. The path mirrors the package structure in the cod file.
The description pertains to the BlackBerry JDE and should be clarified for Eclipse.
I have forwarded your feedback to the documentation team using the feedback form here:
09-21-2010 06:27 PM
Thanks, Mark. I take it, then, that aside from bitmaps, there is no supported way for code in one COD file to access a resource packaged in another COD file (e.g., a dependent library)?
09-22-2010 09:40 AM
Not directly. The library could expose this via a method call of its own.