Skip to content

Debug on Android fails when stopped on breakpoint and change in .xml/.css/.html is applied #4227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rosen-vladimirov opened this issue Dec 13, 2018 · 2 comments

Comments

@rosen-vladimirov
Copy link
Contributor

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

  • CLI: 5.1.0
  • Cross-platform modules: 5.1.0
  • Android Runtime: 5.1.0
  • iOS Runtime: Not applicable
  • Plugin(s): Not applicable

Describe the bug
When debugging on Android, if you've stopped on a breakpoint and apply a change in .xml/.css/.html file, the change will be synced, but CLI will stuck on Sync operation in progress... for a while and after that an error will be shown: Unable to apply changes for device: <device id>. Error is: Sync operation is taking too long.

To Reproduce

  1. tns create myApp --js
  2. cd myApp
  3. tns debug android
  4. When CLI prints a Chrome URL, open it in the browser.
  5. Place a breakpoint on line 17 of main-view-model.js (inside the onTap method: this.counter--;)
  6. Tap the button on the Android device - Chrome DevTools should stop on the breakpoint.
  7. While you've stopped on the breakpoint, open your project in VSCode.
  8. Open main-page.xml in VSCode and change the title of the ActionBar from:
        <ActionBar title="My App" icon="" class="action-bar">

to

        <ActionBar title="My App 2" icon="" class="action-bar">
  1. Save the file
  2. Now check your terminal. CLI will print the following messages:
Executing before-shouldPrepare hook from <path to hook>
Preparing project...
Executing before-prepareJSApp hook from <path to hook>
Project successfully prepared (Android)
Executing after-prepare hook from <path to hook>
Successfully transferred main-page.xml on device <device id>.
Sync operation in progress...
Sync operation in progress...
Sync operation in progress...
Sync operation in progress...
Sync operation in progress...
Unable to apply changes for device: <device id>. Error is: Sync operation is taking too long.
Executing after-watch hook from <path to hook>
Stopping webpack watch

Expected behavior
CLI should sync the change and allow you to continue debugging.

Additional context
Issue is not reproducible in case you've not stopped on breakpoint.

@KristianDD
Copy link
Contributor

KristianDD commented Dec 21, 2018

The reason for that behavior is the order of operations that is executed in the Android Runtime.

When a doSync operation is send to the device it first executes a script that refreshes the application and then sends back a notification that the operation is completed. If a doSync is received, while the application is blocked by a breakpoint the thread will be blocked until the script is evaluated(hit continue of the breakpoint) and this causes a timeout on the CLI side.

We have two options to solve that, but none seems very acceptable:
1 Reorder operations - first send a notification that the application is synced and then run the script.
2 In case we are in debug scenario we can disable the operation timeout.

The first option seems wrong as we will be able to continue with next sync while the application is refreshing (we might call the refresh script while the TNS modules are still in invalid state), which will probably result in a crash or a least an unpredictable behavior.

If we use the second option, every next livesync action will be queued on the chain, but will await the first one that will finish once the breakpoint is released. Then there will be a few consecutive refreshes and potentially a few restarts of the application. (haven't tested it, but pretty sure this will happen).

@KristianDD
Copy link
Contributor

Fixed in NativeScript android runtime and not reproducible anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants