How do you mainly develop and debug your apps?

What do you use the most?

  • B4A-Bridge (WiFi or Bluetoooth)

    Votes: 9 45.0%

  • USB degugging

    Votes: 9 45.0%

  • Android emulator

    Votes: 2 10.0%
  • Total voters
    20

LucaMs

Expert
Licensed User
Longtime User

ac9ts

Active Member
Licensed User
Longtime User
I use both debuggers. What I like about the legacy debugger is it will stop on an error where the rapid debugger just shuts down. I'll use the legacy debugger to find the the line/sub causing the error, set a breakpoint, then use the rapid debugger to modify the code on the fly.

I saw (someplace) that the legacy debugger will be phased out. If there is not a technical reason, I would vote to keep it as it is still very useful.
 

canalrun

Well-Known Member
Licensed User
Longtime User
ac9ts said:
I saw (someplace) that the legacy debugger will be phased out. If there is not a technical reason, I would vote to keep it as it is still very useful.
Click to expand...

Yes, I hope the legacy debugger stays.

Something I found related to Peter Simpson's earlier post: (I'm sure most are already aware)



If I trace Into some subroutine by mistake, I noticed over on the bottom left there is a "stack trace" of previous routines. Click on the second item and you are back to where you came from. You can put a breakpoint at the next statement and then "run", executing out of the subroutine.

I agree "step into" and "step over" are very useful. In one IDE I used years ago they also had a "step out of" which was handy.

Barry.
 
Last edited:

Peter Simpson

Expert
Licensed User
Longtime User
So the B4A-Bridge and USB debugging are neck and neck at the moment. We need more votes to try and separate them for a definitive answer

My money is on
 
Last edited:
S

sorex

Expert
Licensed User
Longtime User
I use and voted USB wired aswell, the other method (bridge) requires too much interactions.

At work I might boot up Genymotion tho since that machine can run it and this netbook can't.
 

canalrun

Well-Known Member
Licensed User
Longtime User
Peter Simpson said:
So the B4A-Bridge and USB debugging are neck and neck at the moment. We need more votes to try and separate them for a definitive answer

My money is on
Click to expand...

B4A bridge!

All of my devices work with the B4A bridge, but some devices don't work with USB despite much trying. if I switch the USB connection to different ports on the hub or directly to PC USB ports, other devices work, but the first set doesn't work anymore. Too much messing around. The B4A bridge always works.

Barry.
 
T

Troberg

Well-Known Member
Licensed User
Longtime User
I use B4A-Bridge and wifi, simply because I run on many different devices and it makes it simpler to switch.

As for the devices, it's my current phone and tablet, then my old phone and tablet, as well as a pile of old phones from family and friends. Seriously, if people around you know that you are interested in old Android devices, the devices will flow to you in a steady stream as your friends upgrade and wants to get rid of old stuff. No need to be super rich.

I switch between debuggers. Mostly, I use the fast debugger, but, as others have said, the ability to stop on the line where an error occurs makes legacy indispensable. Also, occasionally, changes made to the code does not seem to take effect, and switching between the debuggers, building in both, takes care of this. If fixes were made to address those issues, legacy could be dropped as far as I'm concerned, but, until then, I prefer it very much if it remains.
 
T

Troberg

Well-Known Member
Licensed User
Longtime User
By the way, I mostly run as release build until I run into a problem, then I switch to one of the debug builds.

Erel said:
I'm not familiar with this issue. However you can always force the rapid debugger to "delete its caches" by clicking on Tools - Clean Project.
Click to expand...

To be quite honest, I'm not sure about the details, I've only seen it a couple of times and has not been able to reproduce it consistently. It sounds like "Clean project" might work, though, and, if not, changing to release build and back does.
 

RandomCoder

Well-Known Member
Licensed User
Longtime User
@Erel I agree with @ac9ts and tend to use the rapid debugger most of the time but still on the odd occasion I revert back to the legacy debugger, mostly for fault finding.
 

Informatix

Expert
Licensed User
Longtime User
I belong to the school of guys that never use a debugger and rely only upon Log() so I have no opinion on the B4A debugger. I cannot use it when I develop libraries or multithreaded apps so I never tried to understand how it works. LogColor() has been a better addition to B4A for me than the Rapid debugger. Although I think that using it or not is a matter of taste and past experience, I wonder how people can know the subs where their code is passed through or the different values of a variable during the execution with a debugger, and how they can debug without these informations.

I have 8 devices to test my code (via USB) and I am a big user of Genymotion emulators. The most useful devices that I own are a 8" tablet with a 4/3 ratio (it's unusual in the Android world and create new constraints for your layout design) and a Kindle Fire HD (with Amazon's Fire OS which is a fork of Android). I run frequently my code on two devices at once with CustomBuildActions (I'd prefer to select them in the Compile window, so I'm going to repost this wish) to ensure that a change on a certain device doesn't break anything on a different device.
 

JakeBullet70

Well-Known Member
Licensed User
Longtime User
I have switched to wireless USB debugging and use that now. Mostly rapid debugger with, as stated above switching to the legacy debugger when needed. I too wish the rapid debugger would not just puke when it hits an error.
 

Erel

B4X founder
Staff member
Licensed User
Longtime User
JakeBullet70 said:
I too wish the rapid debugger would not just puke when it hits an error.
Click to expand...
More details please...

The rapid debugger should print the error message with the line that caused the error and then terminate. What are the advantages of pausing the program execution at that point?
The important information should be there (position and error message).
 

JakeBullet70

Well-Known Member
Licensed User
Longtime User
Here is the errors on a bug I am working with now. Its the BringAppToFront bug. (I think the activity_resume is not firing but that's another issue)

Legacy debugger: Also notice I can still look at var values.


Rapid debugger. Same bug. Not a line of code changes:



Thanks Erel
 

canalrun

Well-Known Member
Licensed User
Longtime User
I think I've noticed this in the past, but I'm not sure.

The advantage of staying in the app when there's a program error is that you can still look at the value of the variables that likely caused the error.

I greatly prefer being able to hover over variables to see the value pop-up. If the program exits, the variable values at that state are no longer available.

As our local car dealer says: "This is HUUGGE".

Barry.
 

lemonisdead

Well-Known Member
Licensed User
Longtime User
USB debugging and real devices. Too used to have things working on debuggers and not working on devices. And too much thrilling not to be able to explain why to clients.
 
You must log in or register to reply here.
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…