I am currently trying to debug a blackberry application on a real device.
I find the setup time to be ludicrous!
Here is my workflow:
Uninstall the application using Blackberry Desktop Manager (BBDM)
it takes about one minute to select the options to uninstall the app...
BBDM needs to connect to the device and load the application list
you need to find and uncheck the application
BBDM takes about 30 seconds to uninstall the application and its submodules
the blackberry bold 9700 now spends 2 minutes rebooting...
Use eclipse to start debugging
eclipse installs the app
wait for the debugger to attach itself to the device
Start the app manually
All in all, a single debugging run can take more than 10 minutes to execute.
If I miss a breakpoint, I have to start all over again.
Is there a way to optimize this workflow to make debugging on a blackberry device more efficient ?
You don't need to uninstall the application. When you redeploy, it will simply replace the previous version with the new one. Unfortunately it won't avoid the reboot - that's something you'll just have to live with. The good news is that reboot times are getting better on newer devices - it only takes about a minute for my Torch 9800 to fully boot up.
One can only hope that RIM will bring the "hot swap" capability of the simulators into the actual devices.
If you do not use Peristance and the application is not running, you can remove it and then reload it without a reboot.
Furthermore, rather than using the application manager you can use the javaloader.exe file that comes with the eclipse sdk, its located in the bin dir of the sdk to remover or load the cods
Example .bat file
cd C:\Program Files\Eclipse\plugins\net.rim.ejde.componentpack6.0.0_6.0.0.29\components\simulator
java -jar "C:\Program Files\Eclipse\plugins\net.rim.ejde.componentpack6.0.0_6.0.0.29\bin\SignatureTool.jar" -a -c -p myPassword *.cod
"C:\Program Files\Eclipse\plugins\net.rim.ejde.componentpack6.0.0_6.0.0.29\bin\javaloader" -u load myCodFiles.cod
Also personally I debug with the JDE because it is much less laggy then eclipse, but that is a personal choice.
There is some trick to make debugging more efficient in eclipse.
1.You must create fake empty project.
2.And start debugging for it instead of your real project.
3.When debugger has attached, you can run real application on device and debug it without rebooting.
I am using Debug as-> Blackberry Device to debug the application on my Blackberry Torch 9800. It is doing OK most of the times although I admit that debugging in blackberry is not as fast as in iPhone(much faster) or Android(just fine).
Related
I am new to Kony enterprise edition. I tried to run my app using the Android emulator, always its showing unknown error (code 100-ref img), when I click OK, its closing app, I check the Support x86 devices in the settings. I install the apk using cmd, app installed but when I tried to open the app is showing the kony animation with launching icons. I tried to used local host in the kony app but no use. I am unable to guess the what is the error, and what went wrond. Requesting great help to run the app, and kony editor is taking very long period to build in at least in one platform (like android, desktop etc). Its killing my time for building app rather than development. Appreciate any tips to build as fast as possible and track errors.
You can check the error's cause in DDMS(WINDOWS key+R -> DDMS -> press Enter). It should log the message for the cause of your error. Change the debug level to Error if there're too many messages.
As for making the build faster, it's mostly system-dependent, although you can make a few changes that might positively affect build times. Do this: go to your Kony studio's installation folder and find the eclipse.ini file. Open it and change the values of parameters like -Xmx and -XmsMaxPermSize to a higher number. e.g from -Xmx512m to -Xmx1024m. Now restart Kony studio. As an aside, a machine with a minimum of 8GB ram is recommended, with as less programs running as possible apart from Kony.
Lastly, and this is my opinion, Kony preview is basically a sub-optimal feature that's rarely used by any Kony dev I've ever met. You're better off running the final build on a device.
I have developed an QML application (Mingw). I want to deploy this app to other Windows system. My instructions are:
Building app in Release mode
Run windeployqt.exe for necessery dlls and folders.
Adding missing dll.
Problem is, when I start my app, it seems to work in background and no window appears. I have wasted a lot of time on this.
I know it's an old question. For anyone to get here looking for an anwser, try using:
windeployqt.exe . --qmldir <\project\folder\>
I've got 2 stations, one for development and another one for testing. I'd like to be able to run and debug targets that were built under release mode (the code is stripped) on the testing station.
Since the code may not be copied to the testing station for security reasons, I've tried remote debugging as described in the following link - http://lldb.llvm.org/remote.html.
Since both sides of the debugging runs OS X, the settings instructions specify that my local (development) station should run 'lldb-server' along with 'debugserver', and remote (testing) side should run 'platform'.
Unfortunately, I couldn't find all those tools inside the Xcode bundle. I also tried to download lldb source code and create those executable by myself, but I'm still missing the lldb-server target.
I wish I had some clear and comprehensive guide about how to do lldb remote debugging properly from A to Z.
Make sure that Xcode is installed on both machines. (Different versions are OK!)
On the remote machine (running the executable):
Start the app you want to debug
Start debugserver, attach to your app, and listen for connections from the other Mac:
/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework/Versions/A/Resources/debugserver development-mac.local:16000 --attach="Photo Booth"
On the development machine:
Start lldb by typing lldb
Connect to the debug server:
process connect connect://test-mac.local:16000
On the test machine, you should now see the message Waiting for debugger instructions for process 0. After a short while, the (lldb) prompt should appear on your development machine, and you can start debugging as normal.
Unfortunatly, I'm not sure how to connect from Xcode.
Please give feedback for Apple to update their documentation here
In the mean time, I'm getting more milage using hopperapp with app disassembly. http://hopperapp.com/ There's a free trial - and it has a remote debugger available.
I'm running some local application on a mini-PC and lately it has started freezing about once a week. When it's freezing the OS seems to still respond (most of the times). Internet explorer freezing with the message that "Internet Explorer is not responding".
The application is built using HTML/JS/PHP and MySQL. It runs on Internet Explorer using WAMP. (Assume that there is no way to modify the application at the moment).
I want to to find a way to reduce Windows 8.1 resource consumption to minimum. It won't matter how the graphic may look. If possible, only leave the necessary services for running Internet explorer and the localhost application.
I want to take those saved resources and "invest" them in Internet Explorer.
I believe this solution will solve, or at least improve the behavior of the application because when the application is ran on a stronger PC, it simply never crashes even without doing anything to the OS.
Also, if there is a way to do your suggestion with a CMD command so I can make a handy .bat file, it will be great.
I'm sorry if I'm asking the wrong thing in stackoverflow, but I've come to my wits end dealing with Blackberry. Documentation, site organization, general levels of support have all come together to the point that I haven't been able to do a whole lot of actual work in this environment.
I currently have the Eclipse environment downloaded from the blackberry developer's area website. I can run the simulator and everything else without issue. What I'm trying to do now is to move from debugging on the simulator to debugging on the device itself. This is an important step for me, but I haven't found a satisfactory way to do it...
What I've found are some posts saying that I should package an ALX (of which I'm still not sure on how to do), and using the BDM to install it. This, however, means I won't be able to use the debugger...
If someone could direct me to a resource that will give me step by step instructions from coding to release of blackberry development, this would be awfully helpful.
Thanks so much!
Yes, please test your code on a device. Basic stuff works the same between both, but especially when you get into networking, media, etc. the devices are different.
You can debug on your device through Eclipse. I can't provide you with an end-to-end guide on SO, but here's the quick debug guide.
Build (sign if necessary) and load your app onto the device. You can do this with the desktop manager, or with the command-line javaloader tool that comes with the JDE (look in the bin directory), or even OTA (over the air)
After loading, make sure the Desktop Manager is NOT running (it'll interfere with on-device debugging)
From Eclipse, create a new debug configuration, in the Debug Configurations dialog click on BlackBerry Device, and then click on the new configuration icon. Default settings should be fine.
Make sure your device is plugged into your USB port and start your new debug configuration. You'll probably get a lot of prompts about things missing (because actual devices don't have debug info for any built-in stuff, generally) but click through those and you should be fine to debug.
This is something we struggled with a lot at my old company. I don't think it's possible to do with Eclipse, you have to use the BB JDE, creating the necessary project files against the same code base. I could be wrong on that one as we weren't using the RIM Eclipse plugin, just building it all with Ant.
Personally I never managed to get passed "debugger attaching..." on the device, although I believe a colleague got it to connect but found it too slow to be usable (if you think how slow the emulator can be sometimes...). I know our ant build file had a target for building a version specifically for the JDE profiler, although that was only against the emulator.
In the end we resorted to using our own function debugging code that manually logged entries, exits, parameters and run times, sending the result to a special server.
Sorry if that doesn't help much, but that was our experience.
Never needed to debug on the device itself, I've always found that the apps i've written work on the device, same as on the handset.
As for generating an ALX, in eclipse right click on the project inside the Package Explorer and select "Generate ALX File".