04-05-2009, 01:12 AM
Join Date: Apr 2009
Post Thanks: 0
Thanked 0 Times in 0 Posts
| | security problem.. hmm...
I'm not sure I completely agree with both the points made:
1. Regarding it being a "security hole": I think I should explain why I've asked this particular question. In Java, its pretty easy to implement your own classloader, which can selectively "load" functionality in the form of classes in a separate context from the system classloader. Its possible to use classloading as a form of "dynamic loading".. where you can presumable download a bunch of classes (like for example, in a JAR file), define a separate "class path" for them, and then instantiate your own classloader to get them to work. This is well documented and extensively used (in fact, unless I'm completely off the mark, applets are basically classes streamed over HTTP and then loaded at run-time, right? basically, same principle)? Since Blackberry doesn't allow us to implement our own classloaders, that pretty much means I have to explore alternatives, hence the question about "dynamically" loading an app with specific functionality, and then launching it whenever needed (and... doing this in as automated a manner as possible). If I use OTA or any other method, it still requires the user to download the actual COD file that does the specific job, which is not my design goal.
2. Regarding the "documented" methods.. as I have already explained, I KNOW the methods of installation. I thought this particular point would be obvious, the "documented" methods do not work for my particular requirement (for the reasons, please see point 1.). Now if what I'm asking for is either: a)not implemented b)not allowed, I can understand, in which case I'm hoping that someone can point me to what the alternative is to dynamic class loading in Blackberry; that should solve my problem.