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

Developer

Forums

Forums:

I've got a Motorola V260 right here, and I'm watching the DBGPRINTF() output of a test application of mine. The test application, among other things, logs critical events like EVT_APP_STOP, EVT_APP_RESUME, EVT_APP_SUSPEND, and EVT_APP_STOP.

Unfortunately, when the device receives an incoming call, none of these events are generated. That's right, no EVT_APP_SUSPEND!

Also, this device starts a pop-up dialog whenever the user hits one of the volume up or down keys, like it's older sister the Motorola T720. Unlike the T720, the V260 does *not* generate SUSPEND/RESUME events for that popup!

However am I to pass NSTL?

-Jesse

These are OEM-intended behaviors. The suspend event is sent when the user chooses to accept the incoming call or read the received SMS.

These are OEM-intended behaviors. The suspend event is sent when the user chooses to accept the incoming call or read the received SMS.

And exactly how should the application know how to redraw the screen then if the user ignores the SMS in the dialog?

And exactly how should the application know how to redraw the screen then if the user ignores the SMS in the dialog?

I have repeated this test and confirmed these disturbing results for the entire batch of new Motorola devices, including the A840, V260, V265, and V65P.
jhw wrote:Unfortunately, when the device receives an incoming call, none of these events are generated. That's right, no EVT_APP_SUSPEND!
-Jesse

I have repeated this test and confirmed these disturbing results for the entire batch of new Motorola devices, including the A840, V260, V265, and V65P.
jhw wrote:Unfortunately, when the device receives an incoming call, none of these events are generated. That's right, no EVT_APP_SUSPEND!
-Jesse

mohlendo wrote:These are OEM-intended behaviors. The suspend event is sent when the user chooses to accept the incoming call or read the received SMS.
Unfortunately, this information rarely seems to make it in front of those that
are testing at NSTL. And so, it is still a battle everytime an app is flunked for
suspend/resume behavior that is beyond the app developer's control.

mohlendo wrote:These are OEM-intended behaviors. The suspend event is sent when the user chooses to accept the incoming call or read the received SMS.
Unfortunately, this information rarely seems to make it in front of those that
are testing at NSTL. And so, it is still a battle everytime an app is flunked for
suspend/resume behavior that is beyond the app developer's control.

.... And app developers are the first ones to be blamed for NSTL failure.
How for gods sake can we know which device shows what behaviour ?
I Totally agree with u jMiller
Regards

.... And app developers are the first ones to be blamed for NSTL failure.
How for gods sake can we know which device shows what behaviour ?
I Totally agree with u jMiller
Regards

jhw wrote:I've got a Motorola V260 right here, and I'm watching the DBGPRINTF() output of a test application of mine. The test application, among other things, logs critical events like EVT_APP_STOP, EVT_APP_RESUME, EVT_APP_SUSPEND, and EVT_APP_STOP.
Unfortunately, when the device receives an incoming call, none of these events are generated. That's right, no EVT_APP_SUSPEND!
Also, this device starts a pop-up dialog whenever the user hits one of the volume up or down keys, like it's older sister the Motorola T720. Unlike the T720, the V260 does *not* generate SUSPEND/RESUME events for that popup!
However am I to pass NSTL?
-Jesse
"I've got a Motorola V260 right here"
I'm jealous.
Since this device is listed at NSTL as pre-commercial, then, of course, this is
the time where you report the bug an then it gets fixed before the
handset is released :rolleyes: :rolleyes: :cool:
Of course, Qualcomm's device page lists the phone as commercial
(new) -- which is very confusing for those of us that try to use these lists of phones to decide on future submissions. (I did think it was strange when there
were no 260/265 devices available for testing in the lab and after checking
NSTL's site now I know why -- its pre-commercial).
Doh!

jhw wrote:I've got a Motorola V260 right here, and I'm watching the DBGPRINTF() output of a test application of mine. The test application, among other things, logs critical events like EVT_APP_STOP, EVT_APP_RESUME, EVT_APP_SUSPEND, and EVT_APP_STOP.
Unfortunately, when the device receives an incoming call, none of these events are generated. That's right, no EVT_APP_SUSPEND!
Also, this device starts a pop-up dialog whenever the user hits one of the volume up or down keys, like it's older sister the Motorola T720. Unlike the T720, the V260 does *not* generate SUSPEND/RESUME events for that popup!
However am I to pass NSTL?
-Jesse
"I've got a Motorola V260 right here"
I'm jealous.
Since this device is listed at NSTL as pre-commercial, then, of course, this is
the time where you report the bug an then it gets fixed before the
handset is released :rolleyes: :rolleyes: :cool:
Of course, Qualcomm's device page lists the phone as commercial
(new) -- which is very confusing for those of us that try to use these lists of phones to decide on future submissions. (I did think it was strange when there
were no 260/265 devices available for testing in the lab and after checking
NSTL's site now I know why -- its pre-commercial).
Doh!

The whole handset info thing is completely screwed up - with sadly so much in BREW.
It is virtually impossible to find reliable information on handsets anywhere. Qualcomm's handset pages are utterly outdated all the time and never really kept up tp date. Much of the information on handsets they provide is incorrect or incomplete - like the platformIDs for example - the emulator skins are broken left and right as we all know, and it just keeps going on that way.
I also find it utterly ridiculous how secretive everyone is about launch dates of phones. A handset could be launched tomorrow and still no one would be willing to tell you about it today. The logic of that escapes me entirely and I don't buy into the "launch dates can change so we rather not tell" excuses. We are developers, not Joe Shmoe Average Consumer... we pay big money to Qualcomm and the carriers EVERY MOTNH with our sales and I think that should deserve a little respect.
I really wish that someone at Qualcomm and the carriers would finally realize that cell phones are commodity items and that the technology involved is as low tech in most ways like that found in a VCR remote control - though I admit a it more complex.
I said it many times before and I'll keep saying it until things change. It is driving me nuts how Qualcomm seems to be determined to make the life of developers unnecessary hard by providing misleading information or no information at all. It is just not good business, but they don't seem to care.

The whole handset info thing is completely screwed up - with sadly so much in BREW.
It is virtually impossible to find reliable information on handsets anywhere. Qualcomm's handset pages are utterly outdated all the time and never really kept up tp date. Much of the information on handsets they provide is incorrect or incomplete - like the platformIDs for example - the emulator skins are broken left and right as we all know, and it just keeps going on that way.
I also find it utterly ridiculous how secretive everyone is about launch dates of phones. A handset could be launched tomorrow and still no one would be willing to tell you about it today. The logic of that escapes me entirely and I don't buy into the "launch dates can change so we rather not tell" excuses. We are developers, not Joe Shmoe Average Consumer... we pay big money to Qualcomm and the carriers EVERY MOTNH with our sales and I think that should deserve a little respect.
I really wish that someone at Qualcomm and the carriers would finally realize that cell phones are commodity items and that the technology involved is as low tech in most ways like that found in a VCR remote control - though I admit a it more complex.
I said it many times before and I'll keep saying it until things change. It is driving me nuts how Qualcomm seems to be determined to make the life of developers unnecessary hard by providing misleading information or no information at all. It is just not good business, but they don't seem to care.

Dragon wrote:
It is virtually impossible to find reliable information on handsets anywhere. Qualcomm's handset pages are utterly outdated all the time and never really kept up tp date. Much of the information on handsets they provide is incorrect or incomplete - like the platformIDs for example - the emulator skins are broken left and right as we all know, and it just keeps going on that way.
Amen! We've taken to completely ignoring the emulator skins until we handle a real device, whereupon we go through and make sure all of the memory settings, platformIDs, keyCodes, and screen dimensions match to the real hardware.
In turn all that customization/correction creates it's own problems; inevitably, whatever QA department the client is running ends up testing things on their own "pristine" emulator configs and start bugging all kinds of random stuff.
And yet, once you've got QA using corrected emulator configs, NSTL never seems to flag the same bugs; from which we deduce that NSTL has their own corrected configs, so why does QUALCOMM keep serving up incorrect configs and device specs?
To be sure, the quality of the configs and specs on the QUALCOMM site improved in the last six months, but there are still gaps; e.g. there are two distinct devices called C343, one for Verizon and one for Pelephone, each with distinct platformIDs, screen dimensions, and stability issues! You can't find that mentioned anywhere on the QUALCOMM site, and nobody's writing contracts or bug trackers that distinguish between the two.
I also agree with Dragon's .sig; BREW is way to old to not have matured enough for us to have proper emulation of an on-hardware runtime environment, especially considering that ARM processor hardware emulators are abundant. Wouldn't it be nice to do proper profiling and performance tuning with flexible tools? Wouldn't it be nice to get most of your big-endian issues cleaned up without wrestling with NokiaAppLoader.dll?
-Jesse

Dragon wrote:
It is virtually impossible to find reliable information on handsets anywhere. Qualcomm's handset pages are utterly outdated all the time and never really kept up tp date. Much of the information on handsets they provide is incorrect or incomplete - like the platformIDs for example - the emulator skins are broken left and right as we all know, and it just keeps going on that way.
Amen! We've taken to completely ignoring the emulator skins until we handle a real device, whereupon we go through and make sure all of the memory settings, platformIDs, keyCodes, and screen dimensions match to the real hardware.
In turn all that customization/correction creates it's own problems; inevitably, whatever QA department the client is running ends up testing things on their own "pristine" emulator configs and start bugging all kinds of random stuff.
And yet, once you've got QA using corrected emulator configs, NSTL never seems to flag the same bugs; from which we deduce that NSTL has their own corrected configs, so why does QUALCOMM keep serving up incorrect configs and device specs?
To be sure, the quality of the configs and specs on the QUALCOMM site improved in the last six months, but there are still gaps; e.g. there are two distinct devices called C343, one for Verizon and one for Pelephone, each with distinct platformIDs, screen dimensions, and stability issues! You can't find that mentioned anywhere on the QUALCOMM site, and nobody's writing contracts or bug trackers that distinguish between the two.
I also agree with Dragon's .sig; BREW is way to old to not have matured enough for us to have proper emulation of an on-hardware runtime environment, especially considering that ARM processor hardware emulators are abundant. Wouldn't it be nice to do proper profiling and performance tuning with flexible tools? Wouldn't it be nice to get most of your big-endian issues cleaned up without wrestling with NokiaAppLoader.dll?
-Jesse

jhw wrote:BREW is way to old to not have matured enough for us to have proper emulation of an on-hardware runtime environment, especially considering that ARM processor hardware emulators are abundant.
Not to mention the UI (oooh don't mention the UI!).
Were are certainly pre windows 3.0 with the UI --.
The UI toolkit, as I understand, is not something that is useable
for the majority of the platform id's that are in end users hands right
now.
"San Diego — June 07, 2004 — QUALCOMM Incorporated (Nasdaq: QCOM), pioneer and world leader of Code Division Multiple Access (CDMA) digital wireless technology, today announced significantly expanded support for the development of fully customized user interfaces (UI) on wireless devices via the BREW solution. Although extensive user interface development has been possible and has been achieved with the BREW solution in the past, the newly released BREW 3.1 client software and BREW UI Toolkit include enhancements and additional tools solely designed to simplify and scale the creation of a complete UI that works across multiple devices."
Brew 3.1? Please.
I couldn't even find the UI toolkit on the extranet when I searched today.Where is it anyway?
What we need is a Cntrl3d type library, with source, that works across
everything from 1.1 through the latest versions. Works consistently,
provides access to the mesage loop for proper subclassing and superclassing,
understands things like font files (across all versions remember),
owner draw, etc. Same is true for this super secret CONVERTBMP format.
The advantage is that now operators, NSTL, etc's work is significantly
reduced as users are all using a consistent framework that is tested instead
of each rolling their own.
Why are developers having to reverse engineer CONVERTBMP, write their own
UI controls, memcpy, etc?
I am waiting for the "Undocumented BREW" book to come out, but perhaps that will never happen. So I will proabably bite the bullet for one of my newer apps and try and figure out the CONVERTBMP issues, write my own text control. Allready wrote new menu code for new apps, and part of the text control.
I know its not reccomended, but I also have to compete with apps that are
getting the increased frame rate of knowing those formats.
When Ballmer came out screaming "developers! developers!" at that microsoft conference he did appear a little insane. But, seriously, a developer evangelist is needed at this point.
Otherwise, I suppose there is some money to be made for someone to produce a reliable 3rd party UI toolit that works for the phones that are in users hands now.
Anybody?, anybody?, Bueller?

jhw wrote:BREW is way to old to not have matured enough for us to have proper emulation of an on-hardware runtime environment, especially considering that ARM processor hardware emulators are abundant.
Not to mention the UI (oooh don't mention the UI!).
Were are certainly pre windows 3.0 with the UI --.
The UI toolkit, as I understand, is not something that is useable
for the majority of the platform id's that are in end users hands right
now.
"San Diego — June 07, 2004 — QUALCOMM Incorporated (Nasdaq: QCOM), pioneer and world leader of Code Division Multiple Access (CDMA) digital wireless technology, today announced significantly expanded support for the development of fully customized user interfaces (UI) on wireless devices via the BREW solution. Although extensive user interface development has been possible and has been achieved with the BREW solution in the past, the newly released BREW 3.1 client software and BREW UI Toolkit include enhancements and additional tools solely designed to simplify and scale the creation of a complete UI that works across multiple devices."
Brew 3.1? Please.
I couldn't even find the UI toolkit on the extranet when I searched today.Where is it anyway?
What we need is a Cntrl3d type library, with source, that works across
everything from 1.1 through the latest versions. Works consistently,
provides access to the mesage loop for proper subclassing and superclassing,
understands things like font files (across all versions remember),
owner draw, etc. Same is true for this super secret CONVERTBMP format.
The advantage is that now operators, NSTL, etc's work is significantly
reduced as users are all using a consistent framework that is tested instead
of each rolling their own.
Why are developers having to reverse engineer CONVERTBMP, write their own
UI controls, memcpy, etc?
I am waiting for the "Undocumented BREW" book to come out, but perhaps that will never happen. So I will proabably bite the bullet for one of my newer apps and try and figure out the CONVERTBMP issues, write my own text control. Allready wrote new menu code for new apps, and part of the text control.
I know its not reccomended, but I also have to compete with apps that are
getting the increased frame rate of knowing those formats.
When Ballmer came out screaming "developers! developers!" at that microsoft conference he did appear a little insane. But, seriously, a developer evangelist is needed at this point.
Otherwise, I suppose there is some money to be made for someone to produce a reliable 3rd party UI toolit that works for the phones that are in users hands now.
Anybody?, anybody?, Bueller?

jmiller2 wrote:Not to mention the UI (oooh don't mention the UI!).
Were are certainly pre windows 3.0 with the UI --.
The UI toolkit, as I understand, is not something that is useable
for the majority of the platform id's that are in end users hands right
now.
The UI toolkit is in beta right now. It's supported on BREW 2.1 and up.
It's pretty nice, we're finally getting some real UI widgets. A lot of people are comparing it to Swing, if that gives you an idea of what it's like.
-Erik

jmiller2 wrote:Not to mention the UI (oooh don't mention the UI!).
Were are certainly pre windows 3.0 with the UI --.
The UI toolkit, as I understand, is not something that is useable
for the majority of the platform id's that are in end users hands right
now.
The UI toolkit is in beta right now. It's supported on BREW 2.1 and up.
It's pretty nice, we're finally getting some real UI widgets. A lot of people are comparing it to Swing, if that gives you an idea of what it's like.
-Erik

jmiller2 wrote:Unfortunately, this information rarely seems to make it in front of those that
are testing at NSTL. And so, it is still a battle everytime an app is flunked for
suspend/resume behavior that is beyond the app developer's control.
Yes, I agree that there has been a disconnect in bringing known issues to NSTL's attention (and NSTL-discovered bugs reported to Qualcomm). I hate to say it, but there are always going to be device issues that slip through the cracks and are not discovered until TBT. As much as we test handsets, there's no way we could be as thorough in coming up with obscure code situations as you creative bunch. ;)
We have made huge improvements in the reporting of known issues during the past few months, but there is obviously room for more improvements. Trust me, there are quite a few things in the pipe at the moment.
If your application IS penalized for a device report, it has always been Qualcomm's policy to verify the bug and then instruct NSTL to disregard it as appropriate.

jmiller2 wrote:Unfortunately, this information rarely seems to make it in front of those that
are testing at NSTL. And so, it is still a battle everytime an app is flunked for
suspend/resume behavior that is beyond the app developer's control.
Yes, I agree that there has been a disconnect in bringing known issues to NSTL's attention (and NSTL-discovered bugs reported to Qualcomm). I hate to say it, but there are always going to be device issues that slip through the cracks and are not discovered until TBT. As much as we test handsets, there's no way we could be as thorough in coming up with obscure code situations as you creative bunch. ;)
We have made huge improvements in the reporting of known issues during the past few months, but there is obviously room for more improvements. Trust me, there are quite a few things in the pipe at the moment.
If your application IS penalized for a device report, it has always been Qualcomm's policy to verify the bug and then instruct NSTL to disregard it as appropriate.

ShantanuDeo wrote:.... And app developers are the first ones to be blamed for NSTL failure.
How for gods sake can we know which device shows what behaviour ?
I Totally agree with u jMiller
Regards
Well, the burden partly lies on developers to report device issues that are not yet documented. If no one reports it, how are we to know that it exists? NSTL currently forwards what they suspect to be device issues to us, and we test to see if they're reproducible. If you do find a device bug, please submit it to BREW Support. We'll test to see if it's reproducible; if it is, we file a device bug report for the OEM to investigate. While the device is still early in the commercialization process, the OEM may very well fix the problem. Either way, it will be documented as a known issue. If your device is failed by NSTL for a known issue, send an email to eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%4e%53%54%4c%53%75%70%70%6f%72%74%40%6e%73%74%6c%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%4e%53%54%4c%53%75%70%70%6f%72%74%40%6e%73%74%6c%2e%63%6f%6d%3c%2f%61%3e%27%29%3b')), pointing out the mistake. They will re-evaluate your application's testing results.

ShantanuDeo wrote:.... And app developers are the first ones to be blamed for NSTL failure.
How for gods sake can we know which device shows what behaviour ?
I Totally agree with u jMiller
Regards
Well, the burden partly lies on developers to report device issues that are not yet documented. If no one reports it, how are we to know that it exists? NSTL currently forwards what they suspect to be device issues to us, and we test to see if they're reproducible. If you do find a device bug, please submit it to BREW Support. We'll test to see if it's reproducible; if it is, we file a device bug report for the OEM to investigate. While the device is still early in the commercialization process, the OEM may very well fix the problem. Either way, it will be documented as a known issue. If your device is failed by NSTL for a known issue, send an email to eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%4e%53%54%4c%53%75%70%70%6f%72%74%40%6e%73%74%6c%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%4e%53%54%4c%53%75%70%70%6f%72%74%40%6e%73%74%6c%2e%63%6f%6d%3c%2f%61%3e%27%29%3b')), pointing out the mistake. They will re-evaluate your application's testing results.

jmiller2 wrote:"I've got a Motorola V260 right here"
I'm jealous.
Since this device is listed at NSTL as pre-commercial, then, of course, this is
the time where you report the bug an then it gets fixed before the
handset is released :rolleyes: :rolleyes: :cool:
Of course, Qualcomm's device page lists the phone as commercial
(new) -- which is very confusing for those of us that try to use these lists of phones to decide on future submissions. (I did think it was strange when there
were no 260/265 devices available for testing in the lab and after checking
NSTL's site now I know why -- its pre-commercial).
Doh!
Where are you seeing this? On the Verizon section of the Device page, the v260/265 are listed as pre-commercial. Perhaps it was corrected earlier today, either way it was a mistake. NSTL's website is correct.

jmiller2 wrote:"I've got a Motorola V260 right here"
I'm jealous.
Since this device is listed at NSTL as pre-commercial, then, of course, this is
the time where you report the bug an then it gets fixed before the
handset is released :rolleyes: :rolleyes: :cool:
Of course, Qualcomm's device page lists the phone as commercial
(new) -- which is very confusing for those of us that try to use these lists of phones to decide on future submissions. (I did think it was strange when there
were no 260/265 devices available for testing in the lab and after checking
NSTL's site now I know why -- its pre-commercial).
Doh!
Where are you seeing this? On the Verizon section of the Device page, the v260/265 are listed as pre-commercial. Perhaps it was corrected earlier today, either way it was a mistake. NSTL's website is correct.

mohlendo wrote:Where are you seeing this? On the Verizon section of the Device page, the v260/265 are listed as pre-commercial. Perhaps it was corrected earlier today, either way it was a mistake. NSTL's website is correct.
Yup, I reported it and it was corrected today.
(Of course no mention was made back to me that it was corrected)
I did mention the carrier at first, but I later edited my post as sometimes I am not sure if on this public forum it would be ok to mention specifics like that.

mohlendo wrote:Where are you seeing this? On the Verizon section of the Device page, the v260/265 are listed as pre-commercial. Perhaps it was corrected earlier today, either way it was a mistake. NSTL's website is correct.
Yup, I reported it and it was corrected today.
(Of course no mention was made back to me that it was corrected)
I did mention the carrier at first, but I later edited my post as sometimes I am not sure if on this public forum it would be ok to mention specifics like that.

Dragon wrote:The whole handset info thing is completely screwed up - with sadly so much in BREW.
It is virtually impossible to find reliable information on handsets anywhere. Qualcomm's handset pages are utterly outdated all the time and never really kept up tp date. Much of the information on handsets they provide is incorrect or incomplete - like the platformIDs for example - the emulator skins are broken left and right as we all know, and it just keeps going on that way.
Every time a new software build is released, the DDS is updated. The platform IDs are a genuine problem - there is no real historical listing of PIDs for a handset, mapping between PIDs and software builds, or listing of build changes that caused the PID to roll. We've identified this as a major source of "annoyance" (polite term) to developers, and are currently creating a much more robust system to categorize device information and offer much greater searching capabilities on device details. As far as emulator skins go, these issues will become mainly obsolete as 3.x becomes adopted. The emulator skin information will be picked up from the same source of handset information as the DDS. In the meantime, we're fixing every bug on existing skins once we learn of it, and reviewing the new skins provided by the OEMs to ensure that they're more accurate representations of handset specs.
Dragon wrote:I also find it utterly ridiculous how secretive everyone is about launch dates of phones. A handset could be launched tomorrow and still no one would be willing to tell you about it today. The logic of that escapes me entirely and I don't buy into the "launch dates can change so we rather not tell" excuses. We are developers, not Joe Shmoe Average Consumer... we pay big money to Qualcomm and the carriers EVERY MOTNH with our sales and I think that should deserve a little respect.
This is also a very valid point. Unfortunately, there are all sorts of legal restrictions in place as to what information received from carriers we can and cannot release. The best choice here is to contact the carrier directly, as they are more capable of releasing this information.
Dragon wrote:
I said it many times before and I'll keep saying it until things change. It is driving me nuts how Qualcomm seems to be determined to make the life of developers unnecessary hard by providing misleading information or no information at all. It is just not good business, but they don't seem to care.
Trust me, this is not the case at all. It's just that like in any other large organization, change cannot happen overnight. We're working! ;)

Dragon wrote:The whole handset info thing is completely screwed up - with sadly so much in BREW.
It is virtually impossible to find reliable information on handsets anywhere. Qualcomm's handset pages are utterly outdated all the time and never really kept up tp date. Much of the information on handsets they provide is incorrect or incomplete - like the platformIDs for example - the emulator skins are broken left and right as we all know, and it just keeps going on that way.
Every time a new software build is released, the DDS is updated. The platform IDs are a genuine problem - there is no real historical listing of PIDs for a handset, mapping between PIDs and software builds, or listing of build changes that caused the PID to roll. We've identified this as a major source of "annoyance" (polite term) to developers, and are currently creating a much more robust system to categorize device information and offer much greater searching capabilities on device details. As far as emulator skins go, these issues will become mainly obsolete as 3.x becomes adopted. The emulator skin information will be picked up from the same source of handset information as the DDS. In the meantime, we're fixing every bug on existing skins once we learn of it, and reviewing the new skins provided by the OEMs to ensure that they're more accurate representations of handset specs.
Dragon wrote:I also find it utterly ridiculous how secretive everyone is about launch dates of phones. A handset could be launched tomorrow and still no one would be willing to tell you about it today. The logic of that escapes me entirely and I don't buy into the "launch dates can change so we rather not tell" excuses. We are developers, not Joe Shmoe Average Consumer... we pay big money to Qualcomm and the carriers EVERY MOTNH with our sales and I think that should deserve a little respect.
This is also a very valid point. Unfortunately, there are all sorts of legal restrictions in place as to what information received from carriers we can and cannot release. The best choice here is to contact the carrier directly, as they are more capable of releasing this information.
Dragon wrote:
I said it many times before and I'll keep saying it until things change. It is driving me nuts how Qualcomm seems to be determined to make the life of developers unnecessary hard by providing misleading information or no information at all. It is just not good business, but they don't seem to care.
Trust me, this is not the case at all. It's just that like in any other large organization, change cannot happen overnight. We're working! ;)

jhw wrote:To be sure, the quality of the configs and specs on the QUALCOMM site improved in the last six months, but there are still gaps; e.g. there are two distinct devices called C343, one for Verizon and one for Pelephone, each with distinct platformIDs, screen dimensions, and stability issues! You can't find that mentioned anywhere on the QUALCOMM site, and nobody's writing contracts or bug trackers that distinguish between the two.
If you check the DDS, you'll note that the Pelephone device is actually the c343i, and differs greatly from the Verizon c343. For starters, it is a BREW 2.0 phone while the Verizon phone is 1.1. For this reason, the platform IDs are different.

jhw wrote:To be sure, the quality of the configs and specs on the QUALCOMM site improved in the last six months, but there are still gaps; e.g. there are two distinct devices called C343, one for Verizon and one for Pelephone, each with distinct platformIDs, screen dimensions, and stability issues! You can't find that mentioned anywhere on the QUALCOMM site, and nobody's writing contracts or bug trackers that distinguish between the two.
If you check the DDS, you'll note that the Pelephone device is actually the c343i, and differs greatly from the Verizon c343. For starters, it is a BREW 2.0 phone while the Verizon phone is 1.1. For this reason, the platform IDs are different.

jmiller2 wrote:Not to mention the UI (oooh don't mention the UI!).
Were are certainly pre windows 3.0 with the UI --.
The UI toolkit, as I understand, is not something that is useable
for the majority of the platform id's that are in end users hands right
now.
"San Diego — June 07, 2004 — QUALCOMM Incorporated (Nasdaq: QCOM), pioneer and world leader of Code Division Multiple Access (CDMA) digital wireless technology, today announced significantly expanded support for the development of fully customized user interfaces (UI) on wireless devices via the BREW solution. Although extensive user interface development has been possible and has been achieved with the BREW solution in the past, the newly released BREW 3.1 client software and BREW UI Toolkit include enhancements and additional tools solely designed to simplify and scale the creation of a complete UI that works across multiple devices."
Brew 3.1? Please.
I couldn't even find the UI toolkit on the extranet when I searched today.Where is it anyway?
As ebrowne mentioned, the UI toolkit is in beta. It's currently being provided to strategic developers (you might want to talk with your developer relations contact if you feel you fit into this category). It will be very recognizable to those of you familiar with the Java swing libraries, and should greatly facilitate UI design.
jmiller2 wrote:
What we need is a Cntrl3d type library, with source, that works across
everything from 1.1 through the latest versions. Works consistently,
provides access to the mesage loop for proper subclassing and superclassing,
understands things like font files (across all versions remember),
owner draw, etc. Same is true for this super secret CONVERTBMP format.
The advantage is that now operators, NSTL, etc's work is significantly
reduced as users are all using a consistent framework that is tested instead
of each rolling their own.
Why are developers having to reverse engineer CONVERTBMP, write their own
UI controls, memcpy, etc?
I am waiting for the "Undocumented BREW" book to come out, but perhaps that will never happen. So I will proabably bite the bullet for one of my newer apps and try and figure out the CONVERTBMP issues, write my own text control. Allready wrote new menu code for new apps, and part of the text control.
I know its not reccomended, but I also have to compete with apps that are
getting the increased frame rate of knowing those formats.
CONVERTBMP() is used to convert an image into the native bitmap format. This native format is created by the OEM and is not released to Qualcomm - which is why we were not able to accomodate your recent request that we release this information. Unless the OEM decides to divulge this specification, the only thing we could do is reverse-engineer the format and disseminate the results - which would violate a huge number of NDAs and other legal agreements. Qualcomm is not responsible for the porting of BREW to devices. While we provide technical assistance during this process, the actual work is done by the OEM. As such, we don't typically have access to information about the internal implementation details.
jmiller2 wrote:
When Ballmer came out screaming "developers! developers!" at that microsoft conference he did appear a little insane. But, seriously, a developer evangelist is needed at this point.
Otherwise, I suppose there is some money to be made for someone to produce a reliable 3rd party UI toolit that works for the phones that are in users hands now.
Anybody?, anybody?, Bueller?
We can work at getting our own resident crazy man evangelist...I think they're all busy programming away though. ;)
Rest assured, the UI toolkit has been getting some great feedback.

jmiller2 wrote:Not to mention the UI (oooh don't mention the UI!).
Were are certainly pre windows 3.0 with the UI --.
The UI toolkit, as I understand, is not something that is useable
for the majority of the platform id's that are in end users hands right
now.
"San Diego — June 07, 2004 — QUALCOMM Incorporated (Nasdaq: QCOM), pioneer and world leader of Code Division Multiple Access (CDMA) digital wireless technology, today announced significantly expanded support for the development of fully customized user interfaces (UI) on wireless devices via the BREW solution. Although extensive user interface development has been possible and has been achieved with the BREW solution in the past, the newly released BREW 3.1 client software and BREW UI Toolkit include enhancements and additional tools solely designed to simplify and scale the creation of a complete UI that works across multiple devices."
Brew 3.1? Please.
I couldn't even find the UI toolkit on the extranet when I searched today.Where is it anyway?
As ebrowne mentioned, the UI toolkit is in beta. It's currently being provided to strategic developers (you might want to talk with your developer relations contact if you feel you fit into this category). It will be very recognizable to those of you familiar with the Java swing libraries, and should greatly facilitate UI design.
jmiller2 wrote:
What we need is a Cntrl3d type library, with source, that works across
everything from 1.1 through the latest versions. Works consistently,
provides access to the mesage loop for proper subclassing and superclassing,
understands things like font files (across all versions remember),
owner draw, etc. Same is true for this super secret CONVERTBMP format.
The advantage is that now operators, NSTL, etc's work is significantly
reduced as users are all using a consistent framework that is tested instead
of each rolling their own.
Why are developers having to reverse engineer CONVERTBMP, write their own
UI controls, memcpy, etc?
I am waiting for the "Undocumented BREW" book to come out, but perhaps that will never happen. So I will proabably bite the bullet for one of my newer apps and try and figure out the CONVERTBMP issues, write my own text control. Allready wrote new menu code for new apps, and part of the text control.
I know its not reccomended, but I also have to compete with apps that are
getting the increased frame rate of knowing those formats.
CONVERTBMP() is used to convert an image into the native bitmap format. This native format is created by the OEM and is not released to Qualcomm - which is why we were not able to accomodate your recent request that we release this information. Unless the OEM decides to divulge this specification, the only thing we could do is reverse-engineer the format and disseminate the results - which would violate a huge number of NDAs and other legal agreements. Qualcomm is not responsible for the porting of BREW to devices. While we provide technical assistance during this process, the actual work is done by the OEM. As such, we don't typically have access to information about the internal implementation details.
jmiller2 wrote:
When Ballmer came out screaming "developers! developers!" at that microsoft conference he did appear a little insane. But, seriously, a developer evangelist is needed at this point.
Otherwise, I suppose there is some money to be made for someone to produce a reliable 3rd party UI toolit that works for the phones that are in users hands now.
Anybody?, anybody?, Bueller?
We can work at getting our own resident crazy man evangelist...I think they're all busy programming away though. ;)
Rest assured, the UI toolkit has been getting some great feedback.

mohlendo wrote:Well, the burden partly lies on developers to report device issues that are not yet documented. If no one reports it, how are we to know that it exists? .
I understand that. However, certain things like going through every size circle in IGraphics, testing suspends on receiving a call, etc it would seem to me should be part of a test suite application that would get run against each new handset.
In addition this would/could provide some needed statistics immediately to the manufacturer in terms of speed, etc. As an example, do you realize that the A650 appears to be SLOWER than the a530, which is a year and a half older?
Basic control functionality like ITextControl and IStatic control should not be broken on a handset. The fact that they even CAN differ so much from handset to handset really confuses me, as a UI element should be written on top of base code that doesn't change. Thats what developers are doing when they implement their own versions. All a text control needs to function is
BitBlt. Putting text into a text control should never cause a memory overwrite
or otherwise crash the handset.
For lower level functions like BitBlt, CONVERTBMP, etc I understand how different
handsets need different code. But a text control?? A menu? Fonts?

mohlendo wrote:Well, the burden partly lies on developers to report device issues that are not yet documented. If no one reports it, how are we to know that it exists? .
I understand that. However, certain things like going through every size circle in IGraphics, testing suspends on receiving a call, etc it would seem to me should be part of a test suite application that would get run against each new handset.
In addition this would/could provide some needed statistics immediately to the manufacturer in terms of speed, etc. As an example, do you realize that the A650 appears to be SLOWER than the a530, which is a year and a half older?
Basic control functionality like ITextControl and IStatic control should not be broken on a handset. The fact that they even CAN differ so much from handset to handset really confuses me, as a UI element should be written on top of base code that doesn't change. Thats what developers are doing when they implement their own versions. All a text control needs to function is
BitBlt. Putting text into a text control should never cause a memory overwrite
or otherwise crash the handset.
For lower level functions like BitBlt, CONVERTBMP, etc I understand how different
handsets need different code. But a text control?? A menu? Fonts?

jmiller2 wrote:I understand that. However, certain things like going through every size circle in IGraphics, testing suspends on receiving a call, etc it would seem to me should be part of a test suite application that would get run against each new handset.
In addition this would/could provide some needed statistics immediately to the manufacturer in terms of speed, etc. As an example, do you realize that the A650 appears to be SLOWER than the a530, which is a year and a half older?
We have a benchmarking suite as part of our handset review process. The handsets are actually assessed in terms of quantifiable performance, and carriers typically do not accept handsets that don't perform within a certain tolerance threshold of the reference values. As for automated testing, there is indeed quite a bit of it that goes on. We are catching quite a few errors; though ultimately it's the carrier who decides whether or not a handset is launched, bugs or no bugs. Qualcomm's recommendations are not always followed, and not all bugs are discovered prior to launch. Such is the nature of the beast. :mad:
jmiller2 wrote:
Basic control functionality like ITextControl and IStatic control should not be broken on a handset. The fact that they even CAN differ so much from handset to handset really confuses me, as a UI element should be written on top of base code that doesn't change. Thats what developers are doing when they implement their own versions. All a text control needs to function is
BitBlt. Putting text into a text control should never cause a memory overwrite
or otherwise crash the handset.
For lower level functions like BitBlt, CONVERTBMP, etc I understand how different
handsets need different code. But a text control?? A menu? Fonts?
This is also left primarily to OEM discretion, and you may indeed see interesting results when the OEM decides to modify the BREW reference control implementation to add a layer of customization. We typically fight against many of these changes, but at the end of the day it's a decision made by the carrier. :(

jmiller2 wrote:I understand that. However, certain things like going through every size circle in IGraphics, testing suspends on receiving a call, etc it would seem to me should be part of a test suite application that would get run against each new handset.
In addition this would/could provide some needed statistics immediately to the manufacturer in terms of speed, etc. As an example, do you realize that the A650 appears to be SLOWER than the a530, which is a year and a half older?
We have a benchmarking suite as part of our handset review process. The handsets are actually assessed in terms of quantifiable performance, and carriers typically do not accept handsets that don't perform within a certain tolerance threshold of the reference values. As for automated testing, there is indeed quite a bit of it that goes on. We are catching quite a few errors; though ultimately it's the carrier who decides whether or not a handset is launched, bugs or no bugs. Qualcomm's recommendations are not always followed, and not all bugs are discovered prior to launch. Such is the nature of the beast. :mad:
jmiller2 wrote:
Basic control functionality like ITextControl and IStatic control should not be broken on a handset. The fact that they even CAN differ so much from handset to handset really confuses me, as a UI element should be written on top of base code that doesn't change. Thats what developers are doing when they implement their own versions. All a text control needs to function is
BitBlt. Putting text into a text control should never cause a memory overwrite
or otherwise crash the handset.
For lower level functions like BitBlt, CONVERTBMP, etc I understand how different
handsets need different code. But a text control?? A menu? Fonts?
This is also left primarily to OEM discretion, and you may indeed see interesting results when the OEM decides to modify the BREW reference control implementation to add a layer of customization. We typically fight against many of these changes, but at the end of the day it's a decision made by the carrier. :(

Thanks for the reply.
Please don't take a little venting as any kind of attack
personal or otherwise....
mohlendo wrote:Qualcomm is not responsible for the porting of BREW to devices. While we provide technical assistance during this process, the actual work is done by the OEM. As such, we don't typically have access to information about the internal implementation details.
Yee ouch. The whole thing? There isn't a top layer that is
consistent across all handsets? Wow, that explains a lot.
mohlendo wrote:
CONVERTBMP() is used to convert an image into the native bitmap format. This native format is created by the OEM and is not released to Qualcomm - which is why we were not able to accomodate your recent request that we release this information. Unless the OEM decides to release this information, the only thing we could do is reverse-engineer the format and relase the information - which would violate a huge number of NDAs and other legal agreements
My recent understanding is that this format is identical accross all handsets except for one. What is so secret about that?
mohlendo wrote:
We can work at getting our own resident crazy man evangelist...I think they're all busy programming away though. ;)
Rest assured, the UI toolkit has been getting some great feedback.
So, I guess this is going to be that top layer I thought was there
already. OK.
Does it work with Brew 1.1 and 2.x?

Thanks for the reply.
Please don't take a little venting as any kind of attack
personal or otherwise....
mohlendo wrote:Qualcomm is not responsible for the porting of BREW to devices. While we provide technical assistance during this process, the actual work is done by the OEM. As such, we don't typically have access to information about the internal implementation details.
Yee ouch. The whole thing? There isn't a top layer that is
consistent across all handsets? Wow, that explains a lot.
mohlendo wrote:
CONVERTBMP() is used to convert an image into the native bitmap format. This native format is created by the OEM and is not released to Qualcomm - which is why we were not able to accomodate your recent request that we release this information. Unless the OEM decides to release this information, the only thing we could do is reverse-engineer the format and relase the information - which would violate a huge number of NDAs and other legal agreements
My recent understanding is that this format is identical accross all handsets except for one. What is so secret about that?
mohlendo wrote:
We can work at getting our own resident crazy man evangelist...I think they're all busy programming away though. ;)
Rest assured, the UI toolkit has been getting some great feedback.
So, I guess this is going to be that top layer I thought was there
already. OK.
Does it work with Brew 1.1 and 2.x?

jmiller2 wrote:Thanks for the reply.
Please don't take a little venting as any kind of attack
personal or otherwise....
No problem, everyone has to vent sometime. :)
jmiller2 wrote:
Yee ouch. The whole thing? There isn't a top layer that is
consistent across all handsets? Wow, that explains a lot.
A reference implementation is provided, but an OEM will typically modify certain aspects to meet their needs - for example, native address book integration with BREW is typically device-specific. OEMs may also seek to provide a certain level of customization to the BREW interfaces to differentiate themselves from other companies. This meets with varying degrees of success. :rolleyes:
jmiller2 wrote:
My recent understanding is that this format is identical accross all handsets except for one. What is so secret about that?
I honestly can't speak to this, because I don't have access to this information. As I said, it's not exactly floating around for anyone to look up.
jmiller2 wrote:
So, I guess this is going to be that top layer I thought was there
already. OK.
Does it work with Brew 1.1 and 2.x?
The UI Toolkit will support BREW 2.0+.

jmiller2 wrote:Thanks for the reply.
Please don't take a little venting as any kind of attack
personal or otherwise....
No problem, everyone has to vent sometime. :)
jmiller2 wrote:
Yee ouch. The whole thing? There isn't a top layer that is
consistent across all handsets? Wow, that explains a lot.
A reference implementation is provided, but an OEM will typically modify certain aspects to meet their needs - for example, native address book integration with BREW is typically device-specific. OEMs may also seek to provide a certain level of customization to the BREW interfaces to differentiate themselves from other companies. This meets with varying degrees of success. :rolleyes:
jmiller2 wrote:
My recent understanding is that this format is identical accross all handsets except for one. What is so secret about that?
I honestly can't speak to this, because I don't have access to this information. As I said, it's not exactly floating around for anyone to look up.
jmiller2 wrote:
So, I guess this is going to be that top layer I thought was there
already. OK.
Does it work with Brew 1.1 and 2.x?
The UI Toolkit will support BREW 2.0+.

mohlendo wrote:The UI Toolkit will support BREW 2.1+.
Does it come with source?
Aren't 90+ percent of the handsets that are in
end user's hands today Brew 1.1 and 2.0.x?
Is there any way to port back some of the UI toolkit to support
the previous Brew versions? Or make a scaled-down version?
Please?
;)

mohlendo wrote:The UI Toolkit will support BREW 2.1+.
Does it come with source?
Aren't 90+ percent of the handsets that are in
end user's hands today Brew 1.1 and 2.0.x?
Is there any way to port back some of the UI toolkit to support
the previous Brew versions? Or make a scaled-down version?
Please?
;)

jmiller2 wrote:Does it come with source?
Aren't 90+ percent of the handsets that are in
end user's hands today Brew 1.1 and 2.0.x?
Is there any way to port back some of the UI toolkit to support
the previous Brew versions? Or make a scaled-down version?
Please?
;)
It's provided as an extension, along with some sample applications. As far as support goes, apparently this has changed recently - it now lists support for BREW 2.0...1.1 support is highly unlikely though.

jmiller2 wrote:Does it come with source?
Aren't 90+ percent of the handsets that are in
end user's hands today Brew 1.1 and 2.0.x?
Is there any way to port back some of the UI toolkit to support
the previous Brew versions? Or make a scaled-down version?
Please?
;)
It's provided as an extension, along with some sample applications. As far as support goes, apparently this has changed recently - it now lists support for BREW 2.0...1.1 support is highly unlikely though.

mohlendo wrote:It's provided as an extension, along with some sample applications. As far as support goes, apparently this has changed recently - it now lists support for BREW 2.0...1.1 support is highly unlikely though.
OK, thanks for the info.

mohlendo wrote:It's provided as an extension, along with some sample applications. As far as support goes, apparently this has changed recently - it now lists support for BREW 2.0...1.1 support is highly unlikely though.
OK, thanks for the info.

jhw wrote:I also agree with Dragon's .sig; BREW is way to old to not have matured enough for us to have proper emulation of an on-hardware runtime environment, especially considering that ARM processor hardware emulators are abundant. Wouldn't it be nice to do proper profiling and performance tuning with flexible tools? Wouldn't it be nice to get most of your big-endian issues cleaned up without wrestling with NokiaAppLoader.dll?
Yes, it would definitely be nice to simply have a software environment that accurately reproduced the mobile device. However, this isn't merely a matter of hardware emulation. The whole trick to creating an emulator that behaves identically to the handset lies in simulating the various ideosyncrasies of the BREW device port, not the underlying hardware. As I've mentioned elsewhere in the thread, this porting process is carried out by the OEM and can vary hugely between devices. Creating a device skin that faithfully mimics the entire port is more or less technologically infeasible. :(

jhw wrote:I also agree with Dragon's .sig; BREW is way to old to not have matured enough for us to have proper emulation of an on-hardware runtime environment, especially considering that ARM processor hardware emulators are abundant. Wouldn't it be nice to do proper profiling and performance tuning with flexible tools? Wouldn't it be nice to get most of your big-endian issues cleaned up without wrestling with NokiaAppLoader.dll?
Yes, it would definitely be nice to simply have a software environment that accurately reproduced the mobile device. However, this isn't merely a matter of hardware emulation. The whole trick to creating an emulator that behaves identically to the handset lies in simulating the various ideosyncrasies of the BREW device port, not the underlying hardware. As I've mentioned elsewhere in the thread, this porting process is carried out by the OEM and can vary hugely between devices. Creating a device skin that faithfully mimics the entire port is more or less technologically infeasible. :(

You know Max, I'll get off your back here for a minute after reading all this because you are a genuinely nice guy who's really trying to cut through the bull.
However, I will say this. After reading all this, I think Qualcomm needs to take more control over the implementation and needs to cre3ate more restrictive guidelines instead of letting OEMs go wild left and right. Microsoft does essentially the same thing with Windows Mobile as Qualcomm does with BREW and yet, they manage to make sure the handsets that are released are absolutely compliant with their guidelines and virtually free of implementation bugs. I have yet to find a Pocket PC or Smartphone that has comparable problems as any Brew phone currently in the market - and there are comparably many different PPC models as there are Brew phones, each with unique specs. Maybe that's something to bring to the table in a company meeting some time, because I think with all these issues Qualcomm is doing itself a huge disservice.

You know Max, I'll get off your back here for a minute after reading all this because you are a genuinely nice guy who's really trying to cut through the bull.
However, I will say this. After reading all this, I think Qualcomm needs to take more control over the implementation and needs to cre3ate more restrictive guidelines instead of letting OEMs go wild left and right. Microsoft does essentially the same thing with Windows Mobile as Qualcomm does with BREW and yet, they manage to make sure the handsets that are released are absolutely compliant with their guidelines and virtually free of implementation bugs. I have yet to find a Pocket PC or Smartphone that has comparable problems as any Brew phone currently in the market - and there are comparably many different PPC models as there are Brew phones, each with unique specs. Maybe that's something to bring to the table in a company meeting some time, because I think with all these issues Qualcomm is doing itself a huge disservice.

Incoming calls can be monitored through the ITapi interface by registering a callback through ITAPI_OnCallStatus (). This method is useful for many Motorola’s who do not send events on ignored calls. Unfortunately, this workaround will not work for SMS messages. More info can be found in the API.

Incoming calls can be monitored through the ITapi interface by registering a callback through ITAPI_OnCallStatus (). This method is useful for many Motorola’s who do not send events on ignored calls. Unfortunately, this workaround will not work for SMS messages. More info can be found in the API.

Jonathan wrote:Incoming calls can be monitored through the ITapi interface by registering a callback through ITAPI_OnCallStatus (). This method is useful for many Motorola’s who do not send events on ignored calls. Unfortunately, this workaround will not work for SMS messages. More info can be found in the API.
Since the handsets (260 and 265) are pre-commercial why don't you just fix the problems and have them properly send suspend messages when these events occur?

Jonathan wrote:Incoming calls can be monitored through the ITapi interface by registering a callback through ITAPI_OnCallStatus (). This method is useful for many Motorola’s who do not send events on ignored calls. Unfortunately, this workaround will not work for SMS messages. More info can be found in the API.
Since the handsets (260 and 265) are pre-commercial why don't you just fix the problems and have them properly send suspend messages when these events occur?

Another heads up for those dealing with this issue - a phone call (assumedly with a MIDI ringtone) will kill any midi sounds you may have playing at the time.

Another heads up for those dealing with this issue - a phone call (assumedly with a MIDI ringtone) will kill any midi sounds you may have playing at the time.

We've been working with the V260 for a month or so now and here's the list of stuff we've come up with (I would bet that all of these are problems on the V265 also):
1. The SUSPEND/RESUME thing, of course...
2. Closely related, if an app is running during the "Incoming Calls" screen it will not get any EVT_KEY_RELEASE events that occur during that screen. So if a key was pressed and is held down when the "Incoming Calls" screen appears, the key is released while that screen is active, and the call then ignored, the app will only have seen the EVT_KEY event and not the corresponding EVT_KEY_RELEASE event. I imagine this might happen with EVT_KEY and EVT_KEY_PRESS also.
3. Any sounds (at least, the ones we've tried) that an app plays as it runs in the background during the "Incoming Calls" screen will kill the ringer. The app has the power to vibrate the phone too during that time, which seems like it could cause confusion.
4. In our games we've noticed two distinct levels of volume, a louder and a softer level. The volume toggle (left side of the phone) changes this, but it isn't completely consistent how the change works and it seems most of the time to work in the opposite way expected. For instance, turning the volume up to 7 usually sets the volume to soft, then moving it down one notch to 6 sets it to loud. This is a little odd.
5. AEE_FONT_LARGE is smaller than AEE_FONT_NORMAL and AEE_FONT_BOLD. This is noted in the phone specifications, which we eventually saw, but really doesn't seem to make sense. We had a problem because we thought that the NORMAL font was the smallest (it is really very big compared to the screen size) and so didn't imagine to look at LARGE, which I thought would just be horrendous if NORMAL was so big. LARGE is of course really what we wanted.
6. If a phonecall interrupt is accepted, then ended with the END key, and then the END key is pressed again while the “Call Ended” screen is displayed, the phone will exit to the desktop without terminating the app. Returning to the BREW menu and attempting to enter the app again will not work as the app is already running, but since the app is most likely not expecting this situation it cannot activate itself from the background. This prevents the app from reopening. It also seems really pretty serious.
We're notifying BREW support about this stuff but I wanted to throw it out there and see if anyone else is having these issues, or to let people know so that they can try it for themselves and see if any of this will cause problems for them.
Jonathan: Thanks for the ITAPI suggestion. I'll try that out.
Andrew Seidman
Deployment Engineer
JAMDAT Mobile

We've been working with the V260 for a month or so now and here's the list of stuff we've come up with (I would bet that all of these are problems on the V265 also):
1. The SUSPEND/RESUME thing, of course...
2. Closely related, if an app is running during the "Incoming Calls" screen it will not get any EVT_KEY_RELEASE events that occur during that screen. So if a key was pressed and is held down when the "Incoming Calls" screen appears, the key is released while that screen is active, and the call then ignored, the app will only have seen the EVT_KEY event and not the corresponding EVT_KEY_RELEASE event. I imagine this might happen with EVT_KEY and EVT_KEY_PRESS also.
3. Any sounds (at least, the ones we've tried) that an app plays as it runs in the background during the "Incoming Calls" screen will kill the ringer. The app has the power to vibrate the phone too during that time, which seems like it could cause confusion.
4. In our games we've noticed two distinct levels of volume, a louder and a softer level. The volume toggle (left side of the phone) changes this, but it isn't completely consistent how the change works and it seems most of the time to work in the opposite way expected. For instance, turning the volume up to 7 usually sets the volume to soft, then moving it down one notch to 6 sets it to loud. This is a little odd.
5. AEE_FONT_LARGE is smaller than AEE_FONT_NORMAL and AEE_FONT_BOLD. This is noted in the phone specifications, which we eventually saw, but really doesn't seem to make sense. We had a problem because we thought that the NORMAL font was the smallest (it is really very big compared to the screen size) and so didn't imagine to look at LARGE, which I thought would just be horrendous if NORMAL was so big. LARGE is of course really what we wanted.
6. If a phonecall interrupt is accepted, then ended with the END key, and then the END key is pressed again while the “Call Ended” screen is displayed, the phone will exit to the desktop without terminating the app. Returning to the BREW menu and attempting to enter the app again will not work as the app is already running, but since the app is most likely not expecting this situation it cannot activate itself from the background. This prevents the app from reopening. It also seems really pretty serious.
We're notifying BREW support about this stuff but I wanted to throw it out there and see if anyone else is having these issues, or to let people know so that they can try it for themselves and see if any of this will cause problems for them.
Jonathan: Thanks for the ITAPI suggestion. I'll try that out.
Andrew Seidman
Deployment Engineer
JAMDAT Mobile

Out of curiosity, did the suggested workaround work for this/these handset(s)?
I'm concerned because our app receives app-directed SMS messages, and checks an "I'm suspended" flag (which is set on EVT_APP_SUSPEND and cleared on EVT_APP_RESUME, obviously) to determine whether or not to beep/vibrate, display an alert screen, and start a timer. I'm guessing it'd be bad to do all that right as a call is coming in.
Thanks!
-bill!

Out of curiosity, did the suggested workaround work for this/these handset(s)?
I'm concerned because our app receives app-directed SMS messages, and checks an "I'm suspended" flag (which is set on EVT_APP_SUSPEND and cleared on EVT_APP_RESUME, obviously) to determine whether or not to beep/vibrate, display an alert screen, and start a timer. I'm guessing it'd be bad to do all that right as a call is coming in.
Thanks!
-bill!