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

Developer

Forums

In light of the new testing policy for multi-handset submissions, I'd be interested in hearing everyone's comments about how successful they've been in having one version of the .mod and .bar work across multiple platforms.

Since (for BREW 1.x) it is impossible to programmatically determine what platform ID your app. is running on, it seems to me that the only way to handle device-specific differences is by means of #ifdef blocks. This means different *looking* .mod versions may be needed to deal with the device-specific, BREW-implementation idiosyncracies we've all encountered.

Further, if you are targeting multiple devices with a graphic-intensive app., how can you keep the .bar's download size reasonable and still deal with all the screen-size differences? In other words, if you need different bitmaps for each device due to physical hardware differences, how bloated are you prepared to make your .bar(s) to avoid being charged for multiple submissions? Do you push all your image resources to separate .bmp files in the hope of incurring only the incremental testing charge?

I suppose you could use the screen dimensions from AEEDeviceInfo to differentiate hardware. As the number of devices proliferates, however, how long will it take before you regret having used this strategy?

That's just my 2 pence, what do you think?

Thanks.

Murray

I used the "screen width & screen height" check method that you describe on an application, and it worked ok for me.
I'm not sure that its that "regrettable" a strategy, because you have no idea what future platform IDs are coming out anyway. I think its actually a better method than the 2.0 platform ID method, because if they make a refresh version of the platform (i.e. T731) and change its ID number, your application will still work ok without change.
I used it to draw an overtype cursor correctly on each device, since the fonts are drawn differently and the overtype cursor needs to be placed slightly differently for each device.
Your .bmp solution sounds like a good one.
-Aaron

I used the "screen width & screen height" check method that you describe on an application, and it worked ok for me.
I'm not sure that its that "regrettable" a strategy, because you have no idea what future platform IDs are coming out anyway. I think its actually a better method than the 2.0 platform ID method, because if they make a refresh version of the platform (i.e. T731) and change its ID number, your application will still work ok without change.
I used it to draw an overtype cursor correctly on each device, since the fonts are drawn differently and the overtype cursor needs to be placed slightly differently for each device.
Your .bmp solution sounds like a good one.
-Aaron

One of the important 1.1 tricks will be to put a version number in a configuration file, not in the .bar. That because you are forced to update the version number when you make a new submission for a new device, even if the .mod and .bar would otherwise be exactly the same.
Can anyone think of other ways to save $750 on a resubmission?
-Aaron

One of the important 1.1 tricks will be to put a version number in a configuration file, not in the .bar. That because you are forced to update the version number when you make a new submission for a new device, even if the .mod and .bar would otherwise be exactly the same.
Can anyone think of other ways to save $750 on a resubmission?
-Aaron

The method I use is to have a single mod file support multiple BIDs. Then I have a different BID for each handset and match the BID to an internal device ID. This lets me remove all of the #defs and just do the same kind of stuff at run time. To say this makes the code cleaner would be a massive understatement.
As for putting the version number in an external file, what's the point? What NSTL failing bugs can you realistically fix without modifying the .bar or .mod? Maybe if it isn't a bug and you're just changing an IP address or something, but the usefullness seems pretty minor to me.
Tom

The method I use is to have a single mod file support multiple BIDs. Then I have a different BID for each handset and match the BID to an internal device ID. This lets me remove all of the #defs and just do the same kind of stuff at run time. To say this makes the code cleaner would be a massive understatement.
As for putting the version number in an external file, what's the point? What NSTL failing bugs can you realistically fix without modifying the .bar or .mod? Maybe if it isn't a bug and you're just changing an IP address or something, but the usefullness seems pretty minor to me.
Tom

We've had applications that had no bugs in them when run on a new platform, yet we had to change the .bar because of the version number requirement. We write productivity applications, so its possible that they are less demanding on hardware and thus less prone to bugs.

We've had applications that had no bugs in them when run on a new platform, yet we had to change the .bar because of the version number requirement. We write productivity applications, so its possible that they are less demanding on hardware and thus less prone to bugs.

Since the cost for passing a test and not passing a test are the same ($1000 per submission), why not just click every phone on your submission? Maybe it will pass on phones you haven't tested because they haven't been released yet, but maybe they will pass (for free). The old payment structure encouraged careful testing because you only paid on failures, but in this case, you might as well try to test on phones you don't have access to. Does anyone see a flaw in this logic?

Since the cost for passing a test and not passing a test are the same ($1000 per submission), why not just click every phone on your submission? Maybe it will pass on phones you haven't tested because they haven't been released yet, but maybe they will pass (for free). The old payment structure encouraged careful testing because you only paid on failures, but in this case, you might as well try to test on phones you don't have access to. Does anyone see a flaw in this logic?

Quote:Originally posted by Murray Bonner
it seems to me that the only way to handle device-specific differences is by means of #ifdef blocks.Since you'll want your code to run on multiple devices, device-specific code for all devices must be in the executable (you'd use if-then blocks or subclassed methods or whatever).
Quote:Further, if you are targeting multiple devices with a graphic-intensive app., how can you keep the .bar's download size reasonable and still deal with all the screen-size differences?Download resources at runtime. I'm guessing we'll have to trade off the $1000 cost of adding a new handset to an existing application versus maintaining a server that allows the app to download the device-specific resources it needs.
Quote:Do you push all your image resources to separate .bmp files in the hope of incurring only the incremental testing charge?Will they allow that? That would be great if they allow it.
Quote:I suppose you could use the screen dimensions from AEEDeviceInfo to differentiate hardware. As the number of devices proliferates, however, how long will it take before you regret having used this strategy?Screen_dimensions + BREW_version + platformID(on 2.0+) will identify hardware. You KNOW which hardware the app was submitted for, so there won't be any regrets.
However, the BREW Testing Policy indicates that adding a new handset to an existing application will incur a full test charge! This is the only thing I will complain about in the new policy. If my app never fails, and I architect my app to use the same MOD/BAR files for all devices, I still won't get a $250 resubmission charge for new handsets. I am charged a full $1000 per handset as if it is a completely changed app. This is BRAIN-DEAD.
J2ME was already more open than BREW, but now this seals it. Testing, of all things, is clearly going to allow J2ME to kill BREW. Hopefully in the future J2ME apps for the BREW platform will not cost as much to test as BREW C/C++ apps, and thus will solve this issue.
--t

Quote:Originally posted by Murray Bonner
it seems to me that the only way to handle device-specific differences is by means of #ifdef blocks.Since you'll want your code to run on multiple devices, device-specific code for all devices must be in the executable (you'd use if-then blocks or subclassed methods or whatever).
Quote:Further, if you are targeting multiple devices with a graphic-intensive app., how can you keep the .bar's download size reasonable and still deal with all the screen-size differences?Download resources at runtime. I'm guessing we'll have to trade off the $1000 cost of adding a new handset to an existing application versus maintaining a server that allows the app to download the device-specific resources it needs.
Quote:Do you push all your image resources to separate .bmp files in the hope of incurring only the incremental testing charge?Will they allow that? That would be great if they allow it.
Quote:I suppose you could use the screen dimensions from AEEDeviceInfo to differentiate hardware. As the number of devices proliferates, however, how long will it take before you regret having used this strategy?Screen_dimensions + BREW_version + platformID(on 2.0+) will identify hardware. You KNOW which hardware the app was submitted for, so there won't be any regrets.
However, the BREW Testing Policy indicates that adding a new handset to an existing application will incur a full test charge! This is the only thing I will complain about in the new policy. If my app never fails, and I architect my app to use the same MOD/BAR files for all devices, I still won't get a $250 resubmission charge for new handsets. I am charged a full $1000 per handset as if it is a completely changed app. This is BRAIN-DEAD.
J2ME was already more open than BREW, but now this seals it. Testing, of all things, is clearly going to allow J2ME to kill BREW. Hopefully in the future J2ME apps for the BREW platform will not cost as much to test as BREW C/C++ apps, and thus will solve this issue.
--t

My guess is the J2ME testing costs on BREW will be exactly the same as for native BREW apps. I don't think they really care what language you used to develop an application, just that it passes the test.

My guess is the J2ME testing costs on BREW will be exactly the same as for native BREW apps. I don't think they really care what language you used to develop an application, just that it passes the test.

Quote:Originally posted by aisaksen
My guess is the J2ME testing costs on BREW will be exactly the same as for native BREW apps. I don't think they really care what language you used to develop an application, just that it passes the test. Perhaps you're right, but J2ME certification can be done more cheaply because it's a safer language.
Automated testing of J2ME apps is easily possible to ensure that the app will not crash the device. Not so for ARM binaries. The only question is if the J2ME app will perform properly, but at least liability issues are eased.
In any case, it's reasonable for them to charge for testing. However, they should change the policy so we are eligible for an incremental retest fee on new handsets if we don't change the MOD/BAR of an app that already passed TBT.

Quote:Originally posted by aisaksen
My guess is the J2ME testing costs on BREW will be exactly the same as for native BREW apps. I don't think they really care what language you used to develop an application, just that it passes the test. Perhaps you're right, but J2ME certification can be done more cheaply because it's a safer language.
Automated testing of J2ME apps is easily possible to ensure that the app will not crash the device. Not so for ARM binaries. The only question is if the J2ME app will perform properly, but at least liability issues are eased.
In any case, it's reasonable for them to charge for testing. However, they should change the policy so we are eligible for an incremental retest fee on new handsets if we don't change the MOD/BAR of an app that already passed TBT.

Quote:Originally posted by aisaksen
Since the cost for passing a test and not passing a test are the same ($1000 per submission), why not just click every phone on your submission? Maybe it will pass on phones you haven't tested because they haven't been released yet, but maybe they will pass (for free). The old payment structure encouraged careful testing because you only paid on failures, but in this case, you might as well try to test on phones you don't have access to. Does anyone see a flaw in this logic? Yes, and maybe this is why they're charging $1000 for adding a new handset to an existing app.
FAILURE SHOULD INCUR A COST.
And it should be a heavier cost than success. Otherwise they're setting up a strange economy. But I can see that they're striving for simplicity and that's why they didn't want to distinguish between apps that fail and apps that pass. It'd be a pain to police that policy.
But already, the 3 free submissions are a loophole. Since $3000 is more expensive than $400 authentication plus the couple hundred to set up a corp, some people may create a production company for each title.

Quote:Originally posted by aisaksen
Since the cost for passing a test and not passing a test are the same ($1000 per submission), why not just click every phone on your submission? Maybe it will pass on phones you haven't tested because they haven't been released yet, but maybe they will pass (for free). The old payment structure encouraged careful testing because you only paid on failures, but in this case, you might as well try to test on phones you don't have access to. Does anyone see a flaw in this logic? Yes, and maybe this is why they're charging $1000 for adding a new handset to an existing app.
FAILURE SHOULD INCUR A COST.
And it should be a heavier cost than success. Otherwise they're setting up a strange economy. But I can see that they're striving for simplicity and that's why they didn't want to distinguish between apps that fail and apps that pass. It'd be a pain to police that policy.
But already, the 3 free submissions are a loophole. Since $3000 is more expensive than $400 authentication plus the couple hundred to set up a corp, some people may create a production company for each title.

Quote: Originally posted by Murray Bonner
it seems to me that the only way to handle device-specific differences is by means of #ifdef blocks.
Quote:
Tom's response:
Since you'll want your code to run on multiple devices, device-specific code for all devices must be in the executable (you'd use if-then blocks or subclassed methods or whatever).
...
Screen_dimensions + BREW_version + platformID(on 2.0+) will identify hardware. You KNOW which hardware the app was submitted for, so there won't be any regrets.
What if a popular, new BREW 1.1 device comes out with exactly the same screen dimensions as a previous device? Since you CANNOT access the Platform ID to uniquely identify the handset, you'll have to #ifdef your way out of any API implementation snafus specific to the new device.
That's my point about potential regret for relying on the screen dimensions to identify hardware. As the number of devices increases, the more likely it becomes that you'll end up with device-specific .mod's. If we had access to the platform ID, a simple if()...else could, as you suggest, be added to the code to accommodate the new device's peculiarities.

Quote: Originally posted by Murray Bonner
it seems to me that the only way to handle device-specific differences is by means of #ifdef blocks.
Quote:
Tom's response:
Since you'll want your code to run on multiple devices, device-specific code for all devices must be in the executable (you'd use if-then blocks or subclassed methods or whatever).
...
Screen_dimensions + BREW_version + platformID(on 2.0+) will identify hardware. You KNOW which hardware the app was submitted for, so there won't be any regrets.
What if a popular, new BREW 1.1 device comes out with exactly the same screen dimensions as a previous device? Since you CANNOT access the Platform ID to uniquely identify the handset, you'll have to #ifdef your way out of any API implementation snafus specific to the new device.
That's my point about potential regret for relying on the screen dimensions to identify hardware. As the number of devices increases, the more likely it becomes that you'll end up with device-specific .mod's. If we had access to the platform ID, a simple if()...else could, as you suggest, be added to the code to accommodate the new device's peculiarities.

Quote:Originally posted by Murray Bonner
What if a popular, new BREW 1.1 device comes out with exactly the same screen dimensions as a previous device? Since you CANNOT access the Platform ID to uniquely identify the handset, you'll have to #ifdef your way out of any API implementation snafus specific to the new device.I think we have to separate concerns of a common codebase versus an unmodified MOD file. You know what devices you've submitted the MOD file for, so you don't have to worry that someone is going to suddenly run it on a new device.
The new testing policy charges you $1000 to add a new device to your existing app, so the result is that it's no big deal to recompile your app for a new device. And yes, you're right, in that case you could use an #ifdef, but you could also use if-then blocks based on a device flag in a configuration file.
The original discussion was about how to use a single MOD/BAR for as many devices as possible, so I was thinking of how to make a single MOD to support as many devices as possible.
You're right though, I wasn't thinking that OEMs would continue developing 1.1 devices, but it's completely possible if the carriers don't care. I hope OEMs switch to 2.0+ and drop 1.1 asap.

Quote:Originally posted by Murray Bonner
What if a popular, new BREW 1.1 device comes out with exactly the same screen dimensions as a previous device? Since you CANNOT access the Platform ID to uniquely identify the handset, you'll have to #ifdef your way out of any API implementation snafus specific to the new device.I think we have to separate concerns of a common codebase versus an unmodified MOD file. You know what devices you've submitted the MOD file for, so you don't have to worry that someone is going to suddenly run it on a new device.
The new testing policy charges you $1000 to add a new device to your existing app, so the result is that it's no big deal to recompile your app for a new device. And yes, you're right, in that case you could use an #ifdef, but you could also use if-then blocks based on a device flag in a configuration file.
The original discussion was about how to use a single MOD/BAR for as many devices as possible, so I was thinking of how to make a single MOD to support as many devices as possible.
You're right though, I wasn't thinking that OEMs would continue developing 1.1 devices, but it's completely possible if the carriers don't care. I hope OEMs switch to 2.0+ and drop 1.1 asap.

Just out of curiosity, has anyone from Qualcomm actually confirmed that it is a requirement to use one MOD and BAR file for in order to be eligible for the single-charge submission fee.
I agree that there is a hint of that in their new outline, but it is fairly wishi-washi and unclear. Although I am under the impression that no one from Qualcomm is actually reading these new-policy related posts, maybe it would be time for someone to step out of the shadows and make it clear to us, how the new policy deals with this particular issue.
Kevin...??? Anynone?

Just out of curiosity, has anyone from Qualcomm actually confirmed that it is a requirement to use one MOD and BAR file for in order to be eligible for the single-charge submission fee.
I agree that there is a hint of that in their new outline, but it is fairly wishi-washi and unclear. Although I am under the impression that no one from Qualcomm is actually reading these new-policy related posts, maybe it would be time for someone to step out of the shadows and make it clear to us, how the new policy deals with this particular issue.
Kevin...??? Anynone?

You can put more than one bar in your submission, but all of them will be sent to the device when downloaded. This is useful for products that work in multiple languages: you just make the bar filename that you pass to the ISHELL Resource functions a variable instead of a constant.
But that probably doesn't help for gamers who have to support different graphics, because its likely too much to send all the .bars.
Another problem with the testing model is when developing applications with sound: people on the Motorola T720 need .mmf audio files for sound effects but on other devices you need .qcp files...
-Aaron

You can put more than one bar in your submission, but all of them will be sent to the device when downloaded. This is useful for products that work in multiple languages: you just make the bar filename that you pass to the ISHELL Resource functions a variable instead of a constant.
But that probably doesn't help for gamers who have to support different graphics, because its likely too much to send all the .bars.
Another problem with the testing model is when developing applications with sound: people on the Motorola T720 need .mmf audio files for sound effects but on other devices you need .qcp files...
-Aaron

After some extensive testing, I was able to get one mod and one bar to work fairly well for many devices. However, the bar file is a bit more bloated because I had to duplicate a few images for handsets with very small screens.

After some extensive testing, I was able to get one mod and one bar to work fairly well for many devices. However, the bar file is a bit more bloated because I had to duplicate a few images for handsets with very small screens.

As I correctly assumed, no one from Qualcomm evidently deems it necessary to clarify the situation on the submission requirements, as discussed above...

As I correctly assumed, no one from Qualcomm evidently deems it necessary to clarify the situation on the submission requirements, as discussed above...

Quote:Originally posted by Dragon
As I correctly assumed, no one from Qualcomm evidently deems it necessary to clarify the situation on the submission requirements, as discussed above...
I did a ton of submissions last week.
To cover all the phones that the lab tests for,
requires a minimum two tests for the released phones
(one for color and one for 4-color and mono),
and an additional test for each pre commercial phone.
I was surprised to find out that each pre commercial phone
must be a seperate submittal.
But as long as the apps keep getting done, I think the new policy will stay.
Several of my sumissions were really rushed (trying to beat the deadline), so I hope that the majority pass.
BTW does anyone know the proper forum to post press releases in?

Quote:Originally posted by Dragon
As I correctly assumed, no one from Qualcomm evidently deems it necessary to clarify the situation on the submission requirements, as discussed above...
I did a ton of submissions last week.
To cover all the phones that the lab tests for,
requires a minimum two tests for the released phones
(one for color and one for 4-color and mono),
and an additional test for each pre commercial phone.
I was surprised to find out that each pre commercial phone
must be a seperate submittal.
But as long as the apps keep getting done, I think the new policy will stay.
Several of my sumissions were really rushed (trying to beat the deadline), so I hope that the majority pass.
BTW does anyone know the proper forum to post press releases in?