Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Posts: 410
Registered: ‎06-03-2010
My Device: Z10 Red
My Carrier: Free

Re: Problem with Persistable

I do to, but for each project that use the same library, I rename the library in the appdescriptor and I never use any Persistable in this common library.

This way I'm certain that I'll never have any collision between applications that have nothing common except the library they use.


Peter, do you mean you can add two projects to Appworld with the exactly the same library. And when an user download them both, they will both work independantly?

And with library version support too? I mean if your second app use an updated version of the library, it will not override the library for the first application?

Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Problem with Persistable

"do you mean you can add two projects to Appworld with the exactly the same library."


I meant I have applications that are effectively split into different projects and so are different cods.  This specifically applies to BBM enabled apps, where the BBM cod may not get loaded if the user does not have BBM installed.  So it is separate from the rest of the application, which can run quite happily with or without the BBM cod. 


However if you do want to have two projects with the same library, but make the two projects are independent of each other, then this is the KB article for you:


Basically you create a jar from the 'Library' and then include that jar in your build path, and 'export' the jar with your Application build.  Then you get one set of cods for each application, and the library jar is actually included.  This saves all the problems with making a cod out of the jar.  You must make sure that your jar file is not eviscerated.  Normally you will compile a project to a cod file, and the jar is only created so that you compile against it.  So the jar from a normal Library build only has the interfaces and none of the real code.  To use this approach, you need a jar with the real classes in it. 


If you use this approach, and ship a second application with a different version of the Library, then both applications are happy, because they are still using the classes from the jar file that were included in the application during the build. 


Hope this helps.