Eclipse’s Tools for Debugging - Smartphone Development
As a developer, you will find that creating applications for the BlackBerry smart phone device is not only fun and exciting, but relatively easy as well. That being said, sometimes the apps you create will not behave, or perform, the way you’d like them to. Keep reading for the solution.
Once you have your app up and running on Eclipse, you will need to click Run/Debug, which can be reached by pushing the F11 button. It should be pointed out that the run/debug command usually requires the simulator to take a longer time while launching, but on the bright side, it provides developers with a number of different tools they can utilize while troubleshooting on their app. Also, Eclipse allows users to rearrange their workspace in a number of different ways, so some of the buttons or tools we discuss here may not be immediately apparent, depending on your layout. Typically, at the top of your screen you will be able to see where the Java button is; next to it should be a debug button that enables users to switch their view to the debug screen.
The typical debug layout features a debug tab, which shows your running threads. If the simulator is not currently running, most of the windows available in the layout will be empty. Below the layout is where the source code is located, which is also where you can add breakpoints either before or during the simulation. When the simulator hits the breakpoint you’ve inserted, it will stop execution of your application. Below the source code window is typically where the console window will be located. The output from the simulator, as well as the messages from your own app, will be shown there.
The console window can give developers a wide array of very useful messages from the JVM, but it also enables them to write their own custom messages. For example, adding the message “System.err.println(x)” will ensure that the x inserted will be displayed in the console window. So how is this helpful? Using what is commonly referred to as “try-catch blocks” enables developers to catch exceptions and print as much information as they need. This is particularly beneficial during the debugging process, as it allows users to print out a custom error number, exception name, and stack.
The variables and debugging windows allow developers to view the values of the local variables after the app has hit the breakpoint and stopped. The variables window, of course, will feature the values of every local variable at the breakpoint. Usually, on the upper right hand corner of the debug window, there will be control icons. These icons enable users to resume their app or step into or over their code. This feature will prove to be particularly useful, as it enables users to see every step of what’s going on with their application. The debug window also features areas where users can view running threads, pause and resume their app manually, and set up as well as apply filters.
Developers can explore various views by clicking on window/show view/other/expand BlackBerry. Some of the viewpoints include memory statistics view, objects view, and profiler view. To use memory statistics view, a user must set up two breakpoints, and when the app stops at the first breakpoint, pushing refresh will enable them to save the data. Essentially, this allows a developer to have a snapshot of the app that they can reference later. When the app stops at the next breakpoint, the BlackBerry memory statistics view should be refreshed again. Pressing the compare button afterward will enable the system to show all of the changes.
A similar process takes place when using the objects view option. Wait until the app hits a breakpoint, refresh the BlackBerry objects view when it does, and voila -- the objects view will show you all objects. Keep in mind that it won’t just display objects from your app, but it will also include objects from all running apps. Saving this data will enable you to use the snapshot to compare objects between the two breaking points, which can help to find memory leaks.
Lastly, the profiler view is intended to illustrate where your app spends its time. The summary view will display the percentage of time the application spends in idle, code execution, and garbage collection stages.
Now that you’re familiar with the tools offered by Eclipse, debugging should be just about as easy as writing apps for BlackBerry devices.