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

Developer

Forums

Forums:

Hi everybody,

We've noticed that many of you are somewhat less than satisfied with the current documentation of handset specific known issues. So we thought we'd present you all with an opportunity to give us your suggestions on how to make it better.

Just to get things started:

What additional information, if any, would you like to see?
How would you like the data to be organized?
What's your biggest complaint with the current documentation?

Now go, discuss. We'll be around as well to give our insiders' perspective on your suggestions.

I think currently the information is simply too inaccessible being too spread out across countless documents.
Some time ago I have started creating a database with issues but eventually ran out of time to continue - though I may start the project back up as part of my upcoming GDC lecture.
I would definitely suggest to get away from the individual document approach and instead create a searchable database. It would be great if it would not be locked away behind the Extranet login so that you can directly get to it very quickly and conveniently.
The database should contain all sorts of erros and issues as well as work-arounds wherever known. Users should be able to search for particular handsets and get a list of known issues that can be filtered by API, so that for example I can see which issues with the ISOUNDPLAYER API I can expect on the vx6000 - just as an example. I am usually not interested in all errors across the board because I use only a handful of API subsets and this filtering would be EXTREMELY helpfuly. Filtering across handset families would also be welcome - list all these erros but only for Motorola handsets, for example.
At the same time, one should be able to go in there and say "Show me all the problems inherent in the ISOUNDPLAYER API" and the database should bring up a list of ALL issues across all handsets so that it is easy to get an overview over the issues and over how *dangerous* it is to use that particular API.
I think for a start that would be extremely helpful. Add to that the ability so that people can submit new issues directly through that webpage would be very cool as well as the opportunity for people to add additional information to existing issues, such as additional work-arounds etc. that way you would allow the database to grow with the help of the developer community.

I think currently the information is simply too inaccessible being too spread out across countless documents.
Some time ago I have started creating a database with issues but eventually ran out of time to continue - though I may start the project back up as part of my upcoming GDC lecture.
I would definitely suggest to get away from the individual document approach and instead create a searchable database. It would be great if it would not be locked away behind the Extranet login so that you can directly get to it very quickly and conveniently.
The database should contain all sorts of erros and issues as well as work-arounds wherever known. Users should be able to search for particular handsets and get a list of known issues that can be filtered by API, so that for example I can see which issues with the ISOUNDPLAYER API I can expect on the vx6000 - just as an example. I am usually not interested in all errors across the board because I use only a handful of API subsets and this filtering would be EXTREMELY helpfuly. Filtering across handset families would also be welcome - list all these erros but only for Motorola handsets, for example.
At the same time, one should be able to go in there and say "Show me all the problems inherent in the ISOUNDPLAYER API" and the database should bring up a list of ALL issues across all handsets so that it is easy to get an overview over the issues and over how *dangerous* it is to use that particular API.
I think for a start that would be extremely helpful. Add to that the ability so that people can submit new issues directly through that webpage would be very cool as well as the opportunity for people to add additional information to existing issues, such as additional work-arounds etc. that way you would allow the database to grow with the help of the developer community.

Good suggestions,
Id like to suggest a straight list of unsupported (or broken) functions for a device. And if you could look up a function and get a list of the devices that dont support it, that would be great too.
-Tyndal

Good suggestions,
Id like to suggest a straight list of unsupported (or broken) functions for a device. And if you could look up a function and get a list of the devices that dont support it, that would be great too.
-Tyndal

slightly oftopic, but maybe a simple request , i hope, is for a simpler way to download the device specs, i usually grab all the latest ones, its a hassle going through the different pages and grabbing them.
a directory we could spider, or one long html page for those that want it
i'd also prefer a different format to pdf, we convert all that to a db, a csv, or xml or whatever of the docs in a known format would be sweet, not really interested in the pretty formatting,and it cuts down on any translation errors
so a downloadable csv/xml/whatever of all the known issues and/or device specs please! :)

slightly oftopic, but maybe a simple request , i hope, is for a simpler way to download the device specs, i usually grab all the latest ones, its a hassle going through the different pages and grabbing them.
a directory we could spider, or one long html page for those that want it
i'd also prefer a different format to pdf, we convert all that to a db, a csv, or xml or whatever of the docs in a known format would be sweet, not really interested in the pretty formatting,and it cuts down on any translation errors
so a downloadable csv/xml/whatever of all the known issues and/or device specs please! :)

1. Also In many APIS, along with its documentation it would be better if some small examples also chip in . ( In cases which are not very obvious to work with )
2. All latest documents should be properly categorised , named and should be accessible from One page on single click. Too many versions of same document are confusing.
3. Also if possible all ( at least some major ) issues discussed on forums and there solutions also should be added to the searchable database.
4. Sample code for MIME handlers + Some sample code for things which are added in later versions.
Thanx & Regards

1. Also In many APIS, along with its documentation it would be better if some small examples also chip in . ( In cases which are not very obvious to work with )
2. All latest documents should be properly categorised , named and should be accessible from One page on single click. Too many versions of same document are confusing.
3. Also if possible all ( at least some major ) issues discussed on forums and there solutions also should be added to the searchable database.
4. Sample code for MIME handlers + Some sample code for things which are added in later versions.
Thanx & Regards

issues should not be locked to a phone, some issues are from the brew version or from the interface
phone models are not equal to each other, and sometimes a model version has an issue that a newer version don't, so separate if it'the case
we developers should be able to submit new issues and see others submission, of course, see it as a developers submited issue, that should be checked latter by qualcomm guys, I can see that many know issues are not documented as a known issue, at least not at the proper place
I also like the idea of providing a non pdf format, so we can automate it's insertion in databases, not only the device specs, but it's relation to the operators.
also, take VZI for example, each country it operates, there are avaliable different devices, but I can't get which ones in each place, extranet shows VZI as a single operator when displaying avaliable devices, and not separated by country

issues should not be locked to a phone, some issues are from the brew version or from the interface
phone models are not equal to each other, and sometimes a model version has an issue that a newer version don't, so separate if it'the case
we developers should be able to submit new issues and see others submission, of course, see it as a developers submited issue, that should be checked latter by qualcomm guys, I can see that many know issues are not documented as a known issue, at least not at the proper place
I also like the idea of providing a non pdf format, so we can automate it's insertion in databases, not only the device specs, but it's relation to the operators.
also, take VZI for example, each country it operates, there are avaliable different devices, but I can't get which ones in each place, extranet shows VZI as a single operator when displaying avaliable devices, and not separated by country

How about being able to search for handsets by capabilities, brew versions, Hardware specs etc....
- Skavenger

How about being able to search for handsets by capabilities, brew versions, Hardware specs etc....
- Skavenger

Documentation in the format of online MSDN would be very helpful. It will allow us to go to a single location for all information including but not limited to SDK documentation, sample code, device specific issues, tutorial, user guides etc.
Currently a developer needs to refer to SDK documentation that comes with SDK, download older version of SDK (like 1.1 ) to get sample code for API usage, refer to online knowledge base, developer FAQ, and then there are mulitple documents (like how to integrate with MSVC, IWEB usage documents), online sample codes like usage of IPOSDET, GCC compiler installation issue, ARM compiler installation issues, True BREW documentation etc... In my opinior it is completely mismanaged or no one at Qualcomm cares about it. For example in documentation in every API should have an entry for the BREW version it was introduced (in 3.0 documentation there are some introductory effort).
Qualcomms background is technology provider not as developer software provider. Since Qualcomm is trying to get into that direction it would be extremely wise to build a loyal developer base (If Microsoft is successful in this area that is because of this). Like it or not(even guys in the SlashDot forum may have to agree) MSDN documentation is one of the best. (However MSDN search though improved still not upto my expectation, you can use Google for that).
Having an option of downloading the complete documentation/sample code would be added bonus. My two cents.

Documentation in the format of online MSDN would be very helpful. It will allow us to go to a single location for all information including but not limited to SDK documentation, sample code, device specific issues, tutorial, user guides etc.
Currently a developer needs to refer to SDK documentation that comes with SDK, download older version of SDK (like 1.1 ) to get sample code for API usage, refer to online knowledge base, developer FAQ, and then there are mulitple documents (like how to integrate with MSVC, IWEB usage documents), online sample codes like usage of IPOSDET, GCC compiler installation issue, ARM compiler installation issues, True BREW documentation etc... In my opinior it is completely mismanaged or no one at Qualcomm cares about it. For example in documentation in every API should have an entry for the BREW version it was introduced (in 3.0 documentation there are some introductory effort).
Qualcomms background is technology provider not as developer software provider. Since Qualcomm is trying to get into that direction it would be extremely wise to build a loyal developer base (If Microsoft is successful in this area that is because of this). Like it or not(even guys in the SlashDot forum may have to agree) MSDN documentation is one of the best. (However MSDN search though improved still not upto my expectation, you can use Google for that).
Having an option of downloading the complete documentation/sample code would be added bonus. My two cents.

Thanks guys for the suggestions so far.
It definately sounds like improved searchability is one of the top requests.
The suggestion to allow developer-submitted issues is an interesting one. I'd like to hear how the rest of you feel about this. Would you like to see such a listing, even if the issues are entirely unconfirmed? How about developer-submitted workarounds?
A note about Dragon's request to make the known issues more easily accessible: keep in mind that we can not make these device issues public, so protecting them behind the extranet login is absolutely necessary.
For the requests to make the DDS available in a more easily parsible format: we currently create these PDFs from a Excel spreadsheet source. Would this prove more useful? I take it many developers maintain their own database of device information. Would you prefer to simply have access to a Qualcomm-managed device database (which doesn't currently exist, mind you)?

Thanks guys for the suggestions so far.
It definately sounds like improved searchability is one of the top requests.
The suggestion to allow developer-submitted issues is an interesting one. I'd like to hear how the rest of you feel about this. Would you like to see such a listing, even if the issues are entirely unconfirmed? How about developer-submitted workarounds?
A note about Dragon's request to make the known issues more easily accessible: keep in mind that we can not make these device issues public, so protecting them behind the extranet login is absolutely necessary.
For the requests to make the DDS available in a more easily parsible format: we currently create these PDFs from a Excel spreadsheet source. Would this prove more useful? I take it many developers maintain their own database of device information. Would you prefer to simply have access to a Qualcomm-managed device database (which doesn't currently exist, mind you)?

The developer-submitted request do not necessarily have to be completely unconfirmed. The submission could go to someone at QC who has it as a job priority to look, evaluate and update the database as submissions come in to make sure things are kept up to date. The operatic word here is *priority* of course. It is useless if, like right now, it takes weeks for these submissions to show up anywhere. Or better yet, make that one QC member and maybe selected, trusted volunteering members from the dev community would the supervisors of the database and could check on submissions and confirm their validity, I think that would work pretty well.
Databases with unconfirmed submissions are usually worthless as you will have too many trolls submit things they just can't figure out but that are not necessarily handset bugs. Anyone remember the divison crash bug on the t720 problem that was discussed ad nauseam some time ago? I definitely wouldn't want stuff like that suddenly show up in the database and destroy its usefulness entirely.
As for the DDS issue, I believe everyone around here would prefer an XLS handset datasheet over the current DDS PDF files.

The developer-submitted request do not necessarily have to be completely unconfirmed. The submission could go to someone at QC who has it as a job priority to look, evaluate and update the database as submissions come in to make sure things are kept up to date. The operatic word here is *priority* of course. It is useless if, like right now, it takes weeks for these submissions to show up anywhere. Or better yet, make that one QC member and maybe selected, trusted volunteering members from the dev community would the supervisors of the database and could check on submissions and confirm their validity, I think that would work pretty well.
Databases with unconfirmed submissions are usually worthless as you will have too many trolls submit things they just can't figure out but that are not necessarily handset bugs. Anyone remember the divison crash bug on the t720 problem that was discussed ad nauseam some time ago? I definitely wouldn't want stuff like that suddenly show up in the database and destroy its usefulness entirely.
As for the DDS issue, I believe everyone around here would prefer an XLS handset datasheet over the current DDS PDF files.

We're actually planning to implement a searchable XML device database, which will replace the current PDF system.

We're actually planning to implement a searchable XML device database, which will replace the current PDF system.

>What additional information, if any, would you like to see?
Status of known issues. IOW something like
1. Is feature
2. Will not ever be fixed
3. Will be fixed in next version
>How would you like the data to be organized?
Searchable database. Search/filters by phone, keyword, etc.
And a search by brew API's fully supported (and tested).
IOW search by say ICamera or IMedia.
>What's your biggest complaint with the current documentation?
NSTL often does not seem to reference it in parallel with testing.
This results in many issues where apps are failed for known
issues that do not have a work-around. For instance, the app not
suspending when SMS messages are received. This gets corrected, but it
is a time waster.

>What additional information, if any, would you like to see?
Status of known issues. IOW something like
1. Is feature
2. Will not ever be fixed
3. Will be fixed in next version
>How would you like the data to be organized?
Searchable database. Search/filters by phone, keyword, etc.
And a search by brew API's fully supported (and tested).
IOW search by say ICamera or IMedia.
>What's your biggest complaint with the current documentation?
NSTL often does not seem to reference it in parallel with testing.
This results in many issues where apps are failed for known
issues that do not have a work-around. For instance, the app not
suspending when SMS messages are received. This gets corrected, but it
is a time waster.

The problem with maintaining the status of each known issue is that we do not have any control over when or if an issue will be fixed. We can recommend, we can suggest, we can nag, we can even throw a temper tantrum over known issues, but ultimately the OEMs aren't selling any devices to us. They are selling them to the carrier, so only the carrier can demand that an issue gets fixed.
The best we can do in that regard is let the developers know when a bug has been fixed, which is something we're going to work on doing a much better job of.
The point about NSTL is well noted also. I believe that as we make the known issues easier for you the developers to use, it will become easier for NSTL to use as well. But we'll also look at what additional steps we can take to make this less of a problem.

The problem with maintaining the status of each known issue is that we do not have any control over when or if an issue will be fixed. We can recommend, we can suggest, we can nag, we can even throw a temper tantrum over known issues, but ultimately the OEMs aren't selling any devices to us. They are selling them to the carrier, so only the carrier can demand that an issue gets fixed.
The best we can do in that regard is let the developers know when a bug has been fixed, which is something we're going to work on doing a much better job of.
The point about NSTL is well noted also. I believe that as we make the known issues easier for you the developers to use, it will become easier for NSTL to use as well. But we'll also look at what additional steps we can take to make this less of a problem.

mohlendo wrote:We're actually planning to implement a searchable XML device database, which will replace the current PDF system.
That's certainly a good thing but only if it doesn't mean I have to log in three times as it is currently the norm when you do anything on the extranet that is related to XML content. The fact that the extranet doesn't even use a cookie so you don't have to enter username and password every single time is bad enough. Having to go through the process three times in a row is simply too tedious to be of any use. That's why I've never even bothered using any of the XML extracts so far.

mohlendo wrote:We're actually planning to implement a searchable XML device database, which will replace the current PDF system.
That's certainly a good thing but only if it doesn't mean I have to log in three times as it is currently the norm when you do anything on the extranet that is related to XML content. The fact that the extranet doesn't even use a cookie so you don't have to enter username and password every single time is bad enough. Having to go through the process three times in a row is simply too tedious to be of any use. That's why I've never even bothered using any of the XML extracts so far.