Debug fixes when CLI is used as a library#3113
Merged
Merged
Conversation
…during debug In case we are unable to start application on iOS device just before attaching a debugger, CLI will raise unhandled rejection. The problem is that we want to start two actions in parallel - start of application and attaching a debugger. We do not await the start application and when an error is raised in it, Unhandled Rejection is raised. In order to prevent this, use Promise.all - this way in case any of the operations fail, we'll receive it as error in the same method.
In LiveSync service we attach to deviceLost event in order to stop LiveSync operation in case device is detached. However we are attaching it on every change, so at some point CLI prints warning: `Warning: Possible EventEmitter memory leak detected. 11 deviceLost listeners added. Use emitter.setMaxListeners() to increase limit ` Fix this by attaching only once.
In case you are using iOS Simulator with version < 10, every second LiveSync operation does not start the app on device. The problem is that calling `simctl terminate` is not killing the app immediately. However the action is executed, so we call start application. After its been called, the terminate succeeds and kills the app. So the app is not running. When a change is applied we detect app is not running and just start it. So it works. Next change calls terminate and again the app seems like it has not been started. The fix is in ios-sim-portable, so update its version.
…he method In PlatformService we create a canExecute method that does not work correctly in cases when CLI is used as a library. The problem is that in this case methods like `deployPlatform` and `startApplication` receive the device on which to execute the action through their arguments. However, the canExecute method relies on the `devicesService.getDeviceByDeviceOption()` method, which works with the `$options.device`. The last is never set in cases when CLI is used as a library. So the canExecute is changed and now it will work only in case it receives deviceIdentifier as argument. This requires changes in `startApplication` and `deployPlatform` methods, so they will send the deviceIdentifier to canExecute method.
Mitko-Kerezov
approved these changes
Sep 8, 2017
Mitko-Kerezov
left a comment
Mitko-Kerezov
left a comment
Contributor
There was a problem hiding this comment.
Looks all right to me
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix UnhandledRejection error when failed to start application on iOS during debug
In case we are unable to start application on iOS device just before attaching a debugger, CLI will raise unhandled rejection. The problem is that we want to start two actions in parallel - start of application and attaching a debugger. We do not await the start application and when an error is raised in it, Unhandled Rejection is raised. In order to prevent this, use Promise.all - this way in case any of the operations fail, we'll receive it as error in the same method.
Fix attaching multiple times on deviceLost event
In LiveSync service we attach to deviceLost event in order to stop LiveSync operation in case device is detached. However we are attaching it on every change, so at some point CLI prints warning:
Warning: Possible EventEmitter memory leak detected. 11 deviceLost listeners added. Use emitter.setMaxListeners() to increase limitFix this by attaching only once.Fix application is not started on iOS Simulator every other time
In case you are using iOS Simulator with version < 10, every second LiveSync operation does not start the app on device. The problem is that calling
simctl terminateis not killing the app immediately. However the action is executed, so we call start application. After its been called, the terminate succeeds and kills the app. So the app is not running. When a change is applied we detect app is not running and just start it. So it works. Next change calls terminate and again the app seems like it has not been started. The fix is in ios-sim-portable, so update its version.Fix executing of deploy/start app on device, which is not passed to the method
In PlatformService we create a canExecute method that does not work correctly in cases when CLI is used as a library. The problem is that in this case methods like
deployPlatformandstartApplicationreceive the device on which to execute the action through their arguments. However, the canExecute method relies on thedevicesService.getDeviceByDeviceOption()method, which works with the$options.device. The last is never set in cases when CLI is used as a library. So the canExecute is changed and now it will work only in case it receives deviceIdentifier as argument. This requires changes instartApplicationanddeployPlatformmethods, so they will send the deviceIdentifier to canExecute method.