10-22-2012 03:40 PM
I am building a library that i want to include in a project i'm working on. I got the jar for the file, removed the MIDP line which usually causes errors and verified the file.
The thing is that now i want to include this library with a project and when i add it in Eclipse and select the option to export it (i want to include it inside my cod files) i get an error saying that the jar "can not be exported because some class in it was eviscerated".
I think this is due to the fact that my library uses rim protected classes (that require signing) but i'm not really sure.
Any idea on how to solve the problem? Thanks
Solved! Go to Solution.
10-27-2012 06:13 PM
When you build the library jar, you need to build it be used as a 3rd party jar, otherwise it is, as you have fouind out, eviscerated. This explains the process:
11-05-2012 08:12 AM
Thanks for your help. It worked perfectly. One more question i'm wondering. I read on that link that you cannot use persistent store on a library compiled as a Bundled library. Why this happens exactly? Can't i refer on the library as ID to the running application in some fashion like UiApplication....? Or this has something to do with another different point?
I have done some tests in this way and it seems to work properly. It looks like it is working as long as i save all data to an object specific to my app and not for the library itself. (i'm interested in storing the info in the app itself but to have the code in the library)
11-05-2012 08:40 AM - edited 11-05-2012 09:26 AM
The comment is correct.
As I understand it, and in simplified terms, the problem here is the restrictions the BlackBerry has on two applications sharing the same fully qualified class name name.
This is allowed as long as there is nothing that is sharable in that library. So two applications can both have a class called:
and these can be different and the BB will cope.
It can cope because the Blackberry will always know that for one application, it uses that application's class, and in another application, that other application's class.
However persistent store objects are shared. This means that if there is data stored and it uses
and there are two class definitions for this class, the BlackBerry has to choose one of them and will get confused if there are two.
I think this is a result of the way persistent store is tidied up when an application is deleted. Basically it looks at all the persisted classes in the application, and removes any Objects in persistent store that use these persistent classes. This means that when you delete an app, you delete its data, which is a good thing. But this restriction seems to be the result, and makes sure that the BB does not delete some other applications data as a result.
Imagine you did have a
shared bundled library with persisted data. Then Application A, which had that Library embedded, created some persistent data. The Application B, also with the same Library did the same. Then the user deleted Application A. The BB would delete data from persistent store for both Application A and B.
Edit: The way I have got round this restriction and still give my Library routines access to a persisted object, is to have an interface in my
shared bundled library, which the shared bundled Library code uses. Then in each Application, I create a real persisted Object, that implements the interface. Now the shared bundled Library code can use this Object, but it is still Application specific. This does mean extra coding, but is worth it for me.
Edit: Missued the expressinns shared and bundled, as suggested in the following post. Hopefully corrected now.
11-05-2012 09:21 AM
I'm a bit confused. I understand that the warning is only for bundled libraries and not shared ones.
Other than that i guess the problem with the bundled is the class names (as you explain with shared ones, maybe you just changed words?). So the problem would be that if i use the same library in another project, one could delete other project data. Am i getting this right?
On the other side, if i'm using the Running app class name as hash for the persistent object, even if using the same library on different projects, the data should not mix or overwrite, right?
11-05-2012 09:50 AM
I have corrected the description above, I had used shared when I meant bundled. Thanks for pointing this out.
The difference between bundled and shared Library, is that you load a shared library as a separate cod, and it is not specific to one application.
A bundled library is included with the Application cod.
The persistent store ID used is not directly relevant in this discussion. But as an attempt to further clarify this, let us assume that we have two applications and the following different scenarios.
1) In the first case we have bundled library used in both applications, the library does NOT have an persistent Objects, and there are different IDs used by each application for their persisted Objects. In this case, the applications would not interact at all. Removing one application would not cause any issues, and that application's persisted data would be removed.
2) In this case we have a bundled library in both applications, with no persisted Objects, but the applications both use the same ID. This is likely to cause problems.
3) This case the applications have a shared library installed separately, but they provide the persistent ID to be used to the library, and the library provides a shared persisted Object to invoking applications. The applications would not interact, but removing an application would leave that application's persisted data. Removing the shared Library would remove both application's data.
4) Final case, the two Applications use the same ID with a shared library as above. This is likely to cause problems.
Does that clear anything up?