DecSoft App Builder incorporates an internal debugger browser based in Chromium (an open source derived from Google Chrome) ready to be use to debug your apps. The debugger show your app running and also a complete developer console which you can use to debug your apps, integrating such browsers' icons in the DecSoft App Builder IDE toolbar, as you can see below.
In the DecSoft App Builder IDE main toolbar, you can see the below four buttons, that must be well explained, from left to right:
The Run button is intended to launch the app in the internal debugger browser without save nor compile it first. In other words, the Run button launch the latest compilation of the app, if any. Just this can be useful, because allows to launch the app as fast as possible, since is not saved nor compiled before launch.
However, the Run button is particularly useful because DecSoft App Builder allows to open the compiled "app.js" in the code editor (Main Menu -> App -> Open app.js). So the point is that you can perform changes in the "app.js" file, save it, and then launch the app using the Run button.
Since the app is not compiled, what you can see running when the app is launched, is your modify "app.js" file. And that's exactly wnat you wanted: made some changes in the "app.js" and then launch the app is a very good way to debug some specific things.
Not too much to say, the Stop button just stop the internal HTTP Server and close the debugger internal browser window.
The Compile button compile the app without save it firstly. Sometimes you don't want to debug the very latest changes, but the "current state" of the app, to say like that, so you can press the Compile button, without firstly save the app.
The Compile button is what you must use when want to deploy the app, that is, to made the "to be deployed" compilation of your app, you must save it first, and then, press the Compile button. What you get is an app compilation ready to be deployed, without including any debug code related.
The Debug button save the app, if it's modified, then compile the app, including some debug related stuff, and finally launch the app in the internal debugger browser. Note that compile the app means also that the "app.js" is rewrited: if you modify it first to debug something... you must use the Run button (see above) instead the Debug button.
Probably you set some external browser to be used to debug the app (see below). The buttons for these external browsers appear at the right of the Debug button, and, when you press one of them, what that button do is the same than the Debug button, except that additionally launch the app in the specified browser.
Many times the internal browser is enough to debug the app, so, we can simply use it as you can see in the below animated GIF image:
Just press in one of the established debugger browsers and then the right browser is opened with the app ready to be debugged. Commonly you can use the F12 key to show the developer console, this is what you can see in the below animated GIF image:
You probably already know that the DecSoft App Builder produces apps using the VueJS framework. This framework offers the "Vue.js devtools" extension for the modern browsers, in order to enhance their developer consoles.
With this useful extension installed we can browse the runtime information of the app components, like the app controls and their properties. Take a look at the below animated GIF image, which uses the Mozilla Firefox browser with the VueJS extension installed:
Most of the time its enough to debug the app using the browser: almost all the time we can be sure that something that works in the browser, can works in the same way once our app has been compiled with Apache Cordova.
Sometimes, however, we must debug something only available when the app is running in a device like an Android smartphone. In our experience, the best way to debug this kind of things is by using the "Run Batch file" that DecSoft App Builder generates, firstly attaching a device to the computer.
So you attach a device to the computer via USB, for example, and then execute the "Run Batch file", so the app is going to be compiled with Apache Cordova and then launched in the attached device. It's possible to use emulators too, but, using a device is probably better, and, for sure faster.
After the app is launched in the attached Android device (or emulator) the "Run Batch file" starts the debug console, so we can start to receive information from our app. You can use the "window.console.info()", "window.console.debug()" and "window.console.error()" methods to send your own messages to the debug console.
In the same way than is preferible to debug the app using the browser instead of the device (because it's more faster), when you are debugging an Apache Cordova compiler app, probably can be a good idea to try in just one platform, for example debug the app in an Android device.
The idea is that something that works in an Android device, must works in the same way in an Apple iOS device, for example, since the Apache Cordova stuff is the same. In some cases certain Apache Cordova plugin is only available in one platform, so you must debug it in that platform, of course.