Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

My application has to send SMS and run on phones with BREW version 2.1.3 and 3.1.2.
For phone with BREW 2.1.3 I use SendSMS method of ITAPI while for phone with BREW 3.1.2 I create instances of AEECLSID_SMS and AEECLSID_SMSMSG to send a message(I have to use these interfaces instead of TAPI).

Is there a way to make a single dll and mod to invoke ITAPI sendSMS method if current phone BREW verion is 2.1.3 and another method for BREW 3.x?

Maybe you can get the brew version in runtime (thru GETAEEVERSION) and call accordingly.
Even if you do that, how do you solve the problem of which SDK version to include for compilation?
The main problem where it makes us to have separate builds for 2.x and 3.x till now, is which SDK version should be included for compilation of that single dll or mod file. :confused:

Maybe you can get the brew version in runtime (thru GETAEEVERSION) and call accordingly.
Even if you do that, how do you solve the problem of which SDK version to include for compilation?
The main problem where it makes us to have separate builds for 2.x and 3.x till now, is which SDK version should be included for compilation of that single dll or mod file. :confused:

RPDP wrote:Even if you do that, how do you solve the problem of which SDK version to include for compilation?
It doesn't really matter. Different versions are very nearly binary compatible. If you compare the sections of the SDK that you use, you should be able to determine what's needed to make it work with a different version.
In particular, using an older version of the SDK than on the device is almost certain to work. Using a newer version should work if you're careful not to use newer features, but you have to be careful because sometimes old names are changed to point to new things.
brewee wrote:For phone with BREW 2.1.3 I use SendSMS method of ITAPI while for phone with BREW 3.1.2 I create instances of AEECLSID_SMS and AEECLSID_SMSMSG to send a message(I have to use these interfaces instead of TAPI).
If you're using ISHELL_CreateInstance, try falling back to the older method if it tells you that the interface is not supported.

RPDP wrote:Even if you do that, how do you solve the problem of which SDK version to include for compilation?
It doesn't really matter. Different versions are very nearly binary compatible. If you compare the sections of the SDK that you use, you should be able to determine what's needed to make it work with a different version.
In particular, using an older version of the SDK than on the device is almost certain to work. Using a newer version should work if you're careful not to use newer features, but you have to be careful because sometimes old names are changed to point to new things.
brewee wrote:For phone with BREW 2.1.3 I use SendSMS method of ITAPI while for phone with BREW 3.1.2 I create instances of AEECLSID_SMS and AEECLSID_SMSMSG to send a message(I have to use these interfaces instead of TAPI).
If you're using ISHELL_CreateInstance, try falling back to the older method if it tells you that the interface is not supported.

rabidcow wrote:Using a newer version should work if you're careful not to use newer features, but you have to be careful because sometimes old names are changed to point to new things.
You need to be careful when moving forward and recompiling against a newer version of the SDK. In many cases, the #defined class IDs will change, meaning that your previous code will now be attempting to instantiate a class not supported on the device. In many cases, there is a #define that refers to the previous class ID. For example, if you try to compile a 2.1 application that uses IAddrBook against the 3.1.5 header files, it will fail to instantiate the IAddrBook instance. You would need to instead use AEECLSID_ADDRBOOK_21 from the 3.1 headers, which has the same value AEECLSID_ADDRBOOK did in the 2.1 headers.

rabidcow wrote:Using a newer version should work if you're careful not to use newer features, but you have to be careful because sometimes old names are changed to point to new things.
You need to be careful when moving forward and recompiling against a newer version of the SDK. In many cases, the #defined class IDs will change, meaning that your previous code will now be attempting to instantiate a class not supported on the device. In many cases, there is a #define that refers to the previous class ID. For example, if you try to compile a 2.1 application that uses IAddrBook against the 3.1.5 header files, it will fail to instantiate the IAddrBook instance. You would need to instead use AEECLSID_ADDRBOOK_21 from the 3.1 headers, which has the same value AEECLSID_ADDRBOOK did in the 2.1 headers.

max wrote:For example, if you try to compile a 2.1 application that uses IAddrBook against the 3.1.5 header files, it will fail to instantiate the IAddrBook instance. You would need to instead use AEECLSID_ADDRBOOK_21 from the 3.1 headers, which has the same value AEECLSID_ADDRBOOK did in the 2.1 headers.
Out of interest, did the person who decided to do it that way (rather than adding new class IDs for the new interfaces) have a particular hatred for developers, or did they just hate all people equally? ;)

max wrote:For example, if you try to compile a 2.1 application that uses IAddrBook against the 3.1.5 header files, it will fail to instantiate the IAddrBook instance. You would need to instead use AEECLSID_ADDRBOOK_21 from the 3.1 headers, which has the same value AEECLSID_ADDRBOOK did in the 2.1 headers.
Out of interest, did the person who decided to do it that way (rather than adding new class IDs for the new interfaces) have a particular hatred for developers, or did they just hate all people equally? ;)

To be fair, they are at least different major versions. I believe that AEECLSID_FILEMGR changes between 3.1.2 and 3.1.3.... I think the issue is a mandate that different implementations of a single interface id must be binary compatible. Except widgets, which decided not to....

To be fair, they are at least different major versions. I believe that AEECLSID_FILEMGR changes between 3.1.2 and 3.1.3.... I think the issue is a mandate that different implementations of a single interface id must be binary compatible. Except widgets, which decided not to....

max wrote:You need to be careful when moving forward and recompiling against a newer version of the SDK. In many cases, the #defined class IDs will change, meaning that your previous code will now be attempting to instantiate a class not supported on the device.
Right, it's really safer to use an older version of the SDK and add in anything new that you need. But you should make sure you understand what those pieces are doing before you attempt it. What I'm really getting at is that there's nothing magical about the headers if you understand what they're doing. They don't rely on weird compiler layouts or anything for the most part. (finding the "stdlib" helper struct is a bit magical)

max wrote:You need to be careful when moving forward and recompiling against a newer version of the SDK. In many cases, the #defined class IDs will change, meaning that your previous code will now be attempting to instantiate a class not supported on the device.
Right, it's really safer to use an older version of the SDK and add in anything new that you need. But you should make sure you understand what those pieces are doing before you attempt it. What I'm really getting at is that there's nothing magical about the headers if you understand what they're doing. They don't rely on weird compiler layouts or anything for the most part. (finding the "stdlib" helper struct is a bit magical)