04-14-2009 04:03 AM
I have an ApplicationMenuItem on the SMS app menu using MENUITEM_SMS_VIEW and MENUITEM_SMS_EDIT. I am seeing some crazy inconsistencies with the context object that is being passed to the menuitem's run method. Here are some examples of what I'm finding when my menu item is invoked:
- 8320 running OS 184.108.40.206:
- 8130 running OS 220.127.116.11
- 8130 running OS 18.104.22.168
- 8330 running OS 22.214.171.124
- 9530 running OS 126.96.36.199
I'm assuming the inconsistencies are due to bugs. Is that correct? And if so, does anyone know if/when these will be fixed? I'm especially interested in a fix for OS 4.7.
04-14-2009 05:14 AM
04-14-2009 08:27 AM
04-14-2009 02:47 PM
Thank you, Simon and Rex, for your replies. I was afraid that would be the answer I received. This type of conclusion is all too common among these forums. I've been developing for the BlackBerry platform for less than a year, and I've been utterly dumbfounded by the half-baked and frustratingly limited API put-out by RIM. Using the ApplicationMenuItem class is one of the only means by which we can hook-into their built-in apps and achieve some sense of fluidity. For it to be so inconsistent, and for the most part, broken in most of their OS versions, is just inexcusable. I sure hope this type of API negligance is improving. I can't imagine it being much worse.
Rex, since you have products which rely on this broken feature, how do you deal with it? Telling the end-user that it's a bug in RIM's API is certainly not going to make them any less frustrated toward your product. How do you code around something like this when there's no other way to access the information that, according to their documentation, is supposed to be passed to your run method?
04-14-2009 06:39 PM
For most of these, we just post work-arounds in our product forum. There really isn't much more to do. We used to advocate OS upgrades, but we had several folks who went from 4.3 to 4.5 (to work around issues with the call long), and wound up being completely unsatisfied with the new release for other reasons. So we stopped doing that. We just note (for folks who report the issue) that "such and such was fixed by RIM on such and such release".
I agree that it is frustrating. The response like "this was fixed in 188.8.131.52" - is not accepted by 90% of folks who never upgrade their phones. It is basically like saying "live with it".
All of our software runs in trial mode for a couple of weeks, so people either live with the work-arounds, or they let the trial expire.
04-15-2009 02:15 AM
04-15-2009 09:05 AM
Thanks again to both of you for your insight. This really is unfortunate as it makes the experience much worse for the end user, not to mention the frustration for developers who have to try and compensate for it in other ways.
I just had someone test this on OS 184.108.40.206 and it is still broken. So, what is the proper way of submitting these bugs to RIM and requesting a fix? I'm sure they know about it, but how can I make my voice heard to try and get this on their radar? What is the proper procedure?
04-17-2009 09:52 AM
04-17-2009 10:41 AM
I appreciate your response, Mark. Is there any way I can track the progress of this issue to know when a fix might be available? If not, then what about a change log for each OS release and the API issues that were addressed? Is there any such thing available to us?
Thank you for verifying this issue and submitting it to the dev team.