How do you mainly develop and debug your apps?

[LucaMs]

But tech wise I spend way too much money on tech, way too much, but my customers pay for it all

Me too: https://www.b4x.com/android/forum/t...evelop-and-debug-your-apps.48407/#post-301106

but I sold 4 on eBay in the last 2 weeks

Sell the next one to me, pls (given your customers pay all, you can make me a discount of 101% )

 

[ac9ts]

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]

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.

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.

 

[Peter Simpson]

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

 

[sorex]

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]

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

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.

 

[Troberg]

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.

 

[Erel]

and switching between the debuggers, building in both, takes care of this

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.

 

[Troberg]

By the way, I mostly run as release build until I run into a problem, then I switch to one of the debug builds.

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.

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]

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.

@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]

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]

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]

I too wish the rapid debugger would not just puke when it hits an error.

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]

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]

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]

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.

 

[Informatix]

Too used to have things working on debuggers

You mean "emulators" I think.

 

[lemonisdead]

You mean "emulators" I think

Woups, Yes, emulators. Sorry

 

[JakeBullet70]

I have just recently switched to devices exclusively. So much better now.

 

[andymc]

I use Genymotion. It's faster than my actual Android phone.