Dynamically loadable classes | developer.brewmp.com Dynamically loadable classes | developer.brewmp.com

Developer

Dynamically loadable classes

Forums:

It would be nice if BREW supported dynamically loadable classes. Basically, I'd like to be able to add new classes to my project and have them included in the project dynamically. This will not work by creating new extensions, since I would need to know the clsid of each one. I've talked to someone who said they were able to do it on a bunch of phones through some security flaw, but this isn't really a *supported* way of doing it through BREW.

Dynamically loading classes would allow applications to be more dynamic and easier to upgrade if problems do exist on a released phone. And don't say that you need NSTL to verify it works first since NSTL isn't really effective. We've accidentally submitted bad builds and they somehow passed even though it completely didn't work. To me, NSTL just robs developers blind for doing shoddy work. Also, NSTL assuming that testing your application on a verizon phone is the same as testing your application on any other carrier is a horrible assumption. I've run across *many* phones that have different issues depending on which carrier the phone's firmware was built for.

So, I guess my second suggestion is to get rid of NSTL, and instead have the carriers do the testing themselves, since in my experience, they do it anyways.

I'm not sure what you mean by "dynamically loadable classes". Could you give an example? And couldn't you use a private extension?
-Erik

I'm not sure what you mean by "dynamically loadable classes". Could you give an example? And couldn't you use a private extension?
-Erik

The problem with extensions is that you have to pay to submit them and have to know the ClsId in advance. It would be nice to just take a binary file, load it as a class which is abstracted out by an interface, and run it. This would allow me to save multiple files (implementations of the interface) in the local app directory and be able to run arbitrary code....I know Qualcomm might not want arbitrary code running, but it will exist in my application's directory which will not be accessible to any other application/program. Basically, I want a dll interface so I can load arbitrary dll's.

The problem with extensions is that you have to pay to submit them and have to know the ClsId in advance. It would be nice to just take a binary file, load it as a class which is abstracted out by an interface, and run it. This would allow me to save multiple files (implementations of the interface) in the local app directory and be able to run arbitrary code....I know Qualcomm might not want arbitrary code running, but it will exist in my application's directory which will not be accessible to any other application/program. Basically, I want a dll interface so I can load arbitrary dll's.

A private extension is one that does not have a class ID and is not submitted for testing. It is included in your MOD file, and you call the constructor directly.
I suppose this still wouldn't be what you wanted, since all code has to be in the MOD file.
-Erik

A private extension is one that does not have a class ID and is not submitted for testing. It is included in your MOD file, and you call the constructor directly.
I suppose this still wouldn't be what you wanted, since all code has to be in the MOD file.
-Erik

Yeah, that's not exactly what I wanted. Dynamically loading code from a separate file based on a common interface that the mod recognizes is what I'm looking for. This would allow me to keep instances of my code separate from the mod, so they can be updated on the fly, so functionality can be added into my application later without having to resubmit the entire application to NSTL and *HOPE* the user downloads the update after I send them to the BREW deck via update checking code. As soon as they open my application, it would be easy for me to check for updates myself and download the necessary components.
It's all a matter of user-experience. I want to give the user a great experience, but BREW is not allowing me to. To me, that means BREW is not doing its job.

Yeah, that's not exactly what I wanted. Dynamically loading code from a separate file based on a common interface that the mod recognizes is what I'm looking for. This would allow me to keep instances of my code separate from the mod, so they can be updated on the fly, so functionality can be added into my application later without having to resubmit the entire application to NSTL and *HOPE* the user downloads the update after I send them to the BREW deck via update checking code. As soon as they open my application, it would be easy for me to check for updates myself and download the necessary components.
It's all a matter of user-experience. I want to give the user a great experience, but BREW is not allowing me to. To me, that means BREW is not doing its job.

It sounds like you want to circumvent the NSTL and operator testing, though. And the operators would not be happy with that. So even if such a mechanism existed in BREW, I don't think operators would allow apps that used it.
-Erik

It sounds like you want to circumvent the NSTL and operator testing, though. And the operators would not be happy with that. So even if such a mechanism existed in BREW, I don't think operators would allow apps that used it.
-Erik