Livesync debugging support

[sitefinitysteve]

@Infrid on slack brought up this suggestion, and it makes sense to me... ability to debug, fix the bug, and have livesync reload me instantly seems like a super powerful concept.

[rosen-vladimirov]

@sitefinitysteve may I ask for the expected scenario here, for example calling:

$ tns debug android --watch

And when a change is applied in any file, what's the expected behavior - restart the whole debug session?

[sitefinitysteve]

@rosen-vladimirov I'm just passing on the request, but... I mean yeah, and if the --brk option to pause on debug start could be eliminated that would be big as well... its another (usually) unneeded step\pause.

How about this (it's been suggested before)

Remove livesync and make tns run just do livesync on the watch command, the same with debug.

[georgejecook]

Hi guys.

this is a vitally important part of a mobile developers tool chain. We need to get the most of our compilation and deployment cycles, and break-point debugging is an absolute must in mobile development as often we'll be testing some kind of bug/scenario which is driven by (And potentially totally related to) user interface behaviour that is really hard to test, with all the SOLID design principles in the world.
Having to re-deploy the app every time just to get hold of break-points would be hell, as it's a slow process.
Conversely, being able to have the speed of livesync as it is now; but with breakpoint debugging enabled, will be streets ahead of even Xamarin Studio. Which is to say, not doing is a huge disappointment, where as doing it is a massive win.

[georgejecook]

and count me as a +1 on the unnecessary break on startup.. if we could have that available; but default to off, that'd be great. royal pita if you ask me.

[sitefinitysteve]

@georgejecook 1000% initial breakpoint on start is only handy if you need to debug from app start, which is not often

[rosen-vladimirov]

Ok, let's separate this into parts:

1. tns debug <platform> - in case you do not want to stop on the initial break point, just pass --start option. It requires the application to be deployed and running on device.
2. Livesync + debug. It's a kind of tricky here. I fully understand your needs and requirements, but I'll have to check this with the people who work on the debuggers. I'm still not sure how could we handle the following case:

• your application has 5 pages. You navigate from first to second and than to the third page.
• you have placed a breakpoint in the view-model of the third page (for example on button's tap event handler
• tap the button, breakpoint is hit. You go to the next line and see the problem. Debugger is still attached.
• apply fix in the code. As --watch option is passed to debug command, CLI will detect the change and sync the file. As the change is in JavaScript code, the app will be restarted and you'll have to navigate to the third view again.

Now let's consider the change is in the .css or .xml of the third view - we'll not restart the application, but I'm not sure the breakpoint will be hit again.

As you know, livesync of .js files is restarting the application, so I'm really not sure how we could keep the current state of the debugger.

@KristinaKoeva , @blagoev what do you think. Do we have a chance to provide this feature?

[sitefinitysteve]

1. IMO tns debug was better before it assumed --brk by default, the app would just start and hit your set breakpoint.
2. I personally don't need to maintain state in a livesync debug, not sure about @georgejecook ...if the app restarted and I went through my sequence of events again, thats fine... would be running through with my fixed code. Maybe just step 1, but saves me from stopping the app, then re-starting the debugger manually.

[rosen-vladimirov]

@sitefinitysteve , we can always set --start as default option and only when --debug-brk is passed, we'll stop at the initial breakpoint. Does it sound reasonable?

As per the second approach - I believe we can easily do this, just integrate the logic for restarting when file is changed. If that's what you need, we'll be glad to add it :)

[sitefinitysteve]

@rosen-vladimirov

1. I mean ping others, but this would make me SO SO SO happy, I swear there's already a git issue on this, no? Consider removing --debug-brk parameter #1376

2. Again, get more feedback, but a debug livesync scenario would be awesomely handy

[rosen-vladimirov]

@sitefinitysteve thanks for the feedback. I believe tns debug had never worked without --debug-brk. In fact in the past when you do not pass --debug-brk or --start I believe CLI was showing an error. After that we decided to set --debug-brk as default option.

Anyway, thanks for the feedback. We'll be waiting for more input on these questions.

[georgejecook]

Absolutely no need to maintain state on a refresh. That is absolutely not what I want. I prefer a re-connect the debugger solution for live sync to breakpoint debugging as it gives me a new know state when debugging tricky things.

So each refresh == new debug session. Just keep the break points, that's all. Ide plugins should do that anyhow.

Sent from my iPhone

On 3 Mar 2016, at 16:09, Rosen Vladimirov notifications@github.com wrote:

@sitefinitysteve thanks for the feedback. I believe tns debug had never worked without --debug-brk. In fact in the past when you do not pass --debug-brk or --start I believe CLI was showing an error. After that we decided to set --debug-brk as default option.

Anyway, thanks for the feedback. We'll be waiting for more input on these questions.

—
Reply to this email directly or view it on GitHub.

[georgeedwards]

+1 for a livesync debug option! State preservation is again not of interest.

[enchev]

Hey folks,

Just to let you know that I've made pull request with no --debug-brk by default:
#1801

We will research how to implement debugging with lyvesync as well!