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
New Developer
Posts: 16
Registered: ‎11-17-2008
My Device: Not Specified

Strategies for Debug Logging

We have an application that we will be starting a beta on next week.  The biggest problem I can forsee is getting debug information from users.  I would like to have a debug log file on the device that I can write to and then upload to our servers with a menu option if the user is experiencing problems.  Of course, if they cant connect to the servers, that is another issue altogether.

 

Is there some way to create a debug log that a user can get to to email to our support staff?  What strategies have others used for debug logging?

Developer
Posts: 5,339
Registered: ‎09-20-2008
My Device: ***
My Carrier: ***

Re: Strategies for Debug Logging

[ Edited ]
  1. Do not use Exception class in catch section of try-catch structure. Use Throwable instead. It preserves the exception stack trace.
  2. Use EventLogger RIM API class to log actions into the device log. To open device log: click on Alt hold it and press LGLG When you open a log event in device log list there is a menu available: "Copy event". Use this functionality to copy/paste log record and send email directly from the device.

Message Edited by tbilisoft on 09-01-2009 06:34 PM
Developer
Posts: 1,415
Registered: ‎07-30-2008
My Device: Not Specified

Re: Strategies for Debug Logging

Have you figured out how to explain to a teenage girl trying to download a ringtone  

how to use the registry editor ? LOL.

This is why I was asking for a progamatic way to get a stack trace. Asking a user, esp an annoyed and

frustrated user, to do anything is a problem. I've had pretty good luck with the "mail me an internal

state dump" approach so far. Usually you still have a functioning menu system but without stack info,

I finally resorted to debug dummy variables so the code has a bunch of junk like debpos=xxx

and then my log has something like "Exception foo with debpos=bar" instead of a stack.

 

Usually the reason for an "interesting event" is obvious or you can get details from the emulator.

If not, the dump can be specialized for iterative debugging with the effected phone.

 

In any case, I don't think I'd ever just call "System.err.println" as sending all the debug info through a

special method or two can be helpful. Also, if you maintain your own debug vectors, you can set "break points"(

conditional statements that execute on the target phone) ,

etc, more easily if it comes to iterating remotely on a real phone.

 

 

 

 

 

 

 

Developer
Posts: 5,339
Registered: ‎09-20-2008
My Device: ***
My Carrier: ***

Re: Strategies for Debug Logging

[ Edited ]

In general an application/product should not cause customers to be annoyed.

 

There is no elegant way to get a full stack exception dump from an annoyed teenager. And it is not a goal in this case.

 

In some cases the application may collect and send exception stack to the developer - but in this case new important points occur. Privacy, privacy and privacy.

 

It is not easy task to explain someone that you are sending only technical data. And by default such actions are disabled on devices.

 

 

 

Message Edited by tbilisoft on 09-01-2009 09:44 PM
Highlighted
Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Strategies for Debug Logging

We use the EventLogger to log actions - this is very useful because then you get interaction with other processing.  As noted in other posts, if you ask nicely, a user might copy and paste this into an email. 

 

At the same time, we maintain the last 100 or so trace entries (which includes the 'Info' ones that won't go in the EventLogger Trace because the default severity is Warn) that came from our application.  In an error situation, we offer to send an email to support, which includes this trace information and anything else that might be useful for the error.

 

However even with this, by far the best source of information is the user.  So in your beta deployment, I recommend that you are careful with who ends up using the product.  If you think it might break, give your product to people who are going to be able to give you good information.