Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Undocumented Methods in Field

@haagmm

 

"I would drop a little knowledge on you here"

 

Yes please!   Smiley Happy

 

Never really got into paintBackground - thought it was for a Screen object and not a Field.  Just to simplify,, the issue I had with setPadding was in a Field that was added to a Manager.  The Manager's background was an image, but the padding on the Field did not seem to get repainted.  I was probably using it incorrectly, but since there is no documentation I didn't how to correct the problem. 

 

I have seen the KB article and was at the session at DevCon when the presenter said setPadding could be used.  I was not saying that that you should not use it, and in fact I do use it in some places (where there is no background to worry about).  What I was trying to say is that perhaps these things have not been released because they are not 100% finished or stable or there are some funny quirks that RIM would find it difficult to document. 

 

But thanks for suggesting I try paintBackground.  Next time I need some padding on a screen/manager with a background, I will try it!

Developer
Posts: 178
Registered: ‎07-29-2008
My Device: Not Specified

Re: Undocumented Methods in Field

Yea, setPadding + paintBackground were how you put a rounded border around things pre 4.6. The other things to know, paint() gets the Graphics object the size of setExtent() paint background gets the setExtent plus setPadding

Developer
Posts: 1,305
Registered: ‎01-21-2009
My Device: Not Specified

Re: Undocumented Methods in Field

 


simon_hain wrote:

i am knot working for RIM. official statement is: do not use them. my own statement is: do it at your own risk.


 

 

I find RIM's official position irritating because they violate it themselves so often. For instance, you can view an "official" RIM webcast (or at least still download the slides) here that publicly recommends using getPadding/setPadding!

 

I (sort of) agree with Simon, though: use at your own risk. Just because an API has been there for ages, does exactly what you need, and is (apparently) relied on internally by RIM, it may still disappear in the next software release. (Of course, documented APIs are frequently deprecated and sometimes unavailable in new releasese, too. But at least then we can righteously claim that RIM broke their API contract.)




Solved? click "Accept as solution". Helpful? give kudos by clicking on the star.
Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Undocumented Methods in Field

"they violate it themselves so often".

 

Is this really justified?  set/getPadding is the only occasion that I am aware of, where RIM have said that an undocumented API can be used.  Can you point us at any others? 

Developer
Posts: 16,992
Registered: ‎07-29-2008
My Device: Z10 LE, Z30, Passport
My Carrier: O2 Germany

Re: Undocumented Methods in Field

when i look at the sorry state the API documentation was when i started, and that it was only improved a bit recently, i rather think that some of these methods are not documented because nobody checked the docs AND saw it. Or: RIM is a big company, there may be one department thinking it safe to use (and showing it on webinars), others think its not safe and don't include it in the docs.

 

You can speculate around but it won't change a thing.

----------------------------------------------------------
feel free to press the like button on the right side to thank the user that helped you.
please mark posts as solved if you found a solution.
@SimonHain on twitter
New Contributor
Posts: 5
Registered: ‎03-18-2010
My Device: 9000
My Carrier: E-Plus

Re: Undocumented Methods in Field

Speaking for me I have seen setPadding(int arg0, int arg1, int arg2, int arg3) in Eclipse. I thought that this method could be handy for me and wanted to know which side of the component which parameter is referring to.

Usually Eclipse takes the Javadoc or the source code (if available) into account to show the real parameter names and  the rest of the documentation. Not here, obviously.

So finding this was rather a coincidence - I am not actively comparing the jar files to the APIs.

Highlighted
Developer
Posts: 1,305
Registered: ‎01-21-2009
My Device: Not Specified

Re: Undocumented Methods in Field


peter_strange wrote:

"they violate it themselves so often".

 

Is this really justified?


No, it's not justified. I retract what I wrote.

 

I think that my overstatement was born of an irritation that I definitely feel. It seems to me that there is a steady trickle (just a trickle, but steady nontheless) of inconsistent information from RIM. The most recent example that comes to mind is someone from RIM advising us on this forum to use the preprocessor variables that are set by the Eclipse plug-in when switching target JDE versions. When asked where these variables were documented, someone from RIM explained that they weren't actually available to us.

 

I also stand by my statement that documented APIs aren't an ironclad guarantee. For instance, the requirements for the Bitmap in "new Graphics(Bitmap)" are incompatible between 4.6 (Bitmap.COLUMNWISE_MONOCHROME or the default type of the device), 4.7 (Bitmap.ROWWISE_MONOCHROME or the default type of the device), and 5.0 (default type of the device only). Sadly, after 4.7 there appears to be no (documented) way to create a Graphics for drawing into a monochrome Bitmap when running on a color device. (I have a bee in my bonnet about this because it tripped me up.)

 

The quality of RIM's documentation might be acceptable if they were putting out a relatively new product. But huge parts of the API have been around for years and some of the bad documentation (like broken links in the crypto api docs) ought to be fixed by now.

 

Enough of my complaining. Here's a suggestion. RIM should set up the documentation as community-based, wiki-like documents, with some mechanism for the entire BlackBerry development community to contribute. After all, anything that makes the community as a whole more productive will benefit not only us but RIM's bottom line.




Solved? click "Accept as solution". Helpful? give kudos by clicking on the star.