Is it possible to reference the javax.script.ScriptEngine library when developing an android application?
If not is there anyway possible to evaluate a javascript expression in android?
For the classes javax.script.ScriptEngine, javax.script.ScriptEngineFactory and so on, you can add the jsr223.jar to your Android project: just copy the .jar file to your libs directory, and add it from Properties->Java Build Path.
These class will allow your JSR 223-compliant engines to compile. You can then do new SomeScriptEngienFactory().getScriptEngine() to get an engine. I've managed to do this with JNLua 1.0.4 and Rhino 1.7R2.
The file jsr223.jar can be downloaded from http://www.java2s.com/Code/Jar/j/Downloadjsr223jar.htm, a direct link is http://www.java2s.com/Code/JarDownload/jsr223/jsr223.jar.zip.
javax.script.ScriptEngine is not a default part of android, but you could easily jar up any libraries you need(assuming the size is reasonable, I'm not sure) and include them in your project.
According to this post, javax.script.ScriptEngine is not available in Android SDK. You can try the steps below to include the library, but the code may not run, even though it will compile.
Using Android Development Toolkit in Windows, I performed the following steps to get javax.script library.
Right-clicked on the project, went to Properties (Project).
Under the Java Build Path, I chose Libraries tab.
Select Add Library located on the middle right of the Tab
Select JRE System Library under Add Library and click Next...
Select Workspace Default JRE (jre 7)
Click Finish.
Click Ok on the Java Build Path to exist project properties.
Javax.script was then loaded.
If you want to evaluate some code in JS in android
1) to your gradle dependencies add (rhino):
compile 'org.mozilla:rhino:1.7R4'
2) write some code like this to get the result of JS evaluation
Context rhino = Context.enter()
// turn off optimization to work with android
rhino.optimizationLevel = -1
String evaluation = "2+2"
try {
ScriptableProject scope = rhino.initStandardObjects()
String result = rhino.evaluateString(scope, evaluation, "JavaScript", 1, null).toString()
} finally {
Context.exit()
}
3) You can write more complex scripts in JS to run in the android app also (functions etc.)
Related
I'm writing some tests for my React-Native application (using JS) in a NodeJS environment. In one scenario, I need to attach to an already-running Windows application. In order to attach to this Application, I need to know the NativeWindowHandle value.
For example, if you open Inspect.exe on a window, you'll find the "NativeWindowHandle" hex value.
Is there anyway I can find this value programmatically?
What I've Tried:
I'm able to find the PID of the app using:
const exec = require('child_process').exec;
exec('tasklist', function (err, stdout) {
....
}}
However, I haven't been able to turn that into the window handle. Does anyone have any ideas here? Is this possible?
This can be reliably accomplished by writing a native (C++) node addon which calls the appropriate Windows API functions and passes the results back to JS land.
eg you might want to call FindWindowEx and Windows will find and return the HWND (native window handle) of the matching open window. Or use one of the enumeration functions if you need to do the search yourself.
I did a quick search of npm and it looks like there might be a few packages that have done this work already, but you'll need to evaluate them.
If none of the npm packages will work, you'll need to write it yourself. This isn't too hard if you have a little C++ knowledge, but alternatively you might be able to get away with using node-ffi, which lets you write everything in JS and marshals the native calls for you.
(Using ffi will be a little slower than writing the native module yourself, but for your purposes that doesn't really matter. Either native or ffi will be much faster than spawning child processes.)
I am working on a ScriptManager class for a project that was created many years ago. The original code read scripts from a database, and these scripts are different depending on the customer and installation (the application is a desktop app that uses Chrome Embedded Framework to display web pages). The code would read custom JavaScript code and eval() it, which of course is highly undesirable.
I am replacing this code with a ScriptManager class that can support dynamically inserted code, and the ScriptManager is capable of loading code as a module using JavaScript's dynamic import() command, or loading code as pure script by creating a script tag dynamically in the document.
My problem is that there are many different possible custom code blocks in the database, and not all are modules; some will be pure script until those can be converted to modules at a later time. My code can handle this as described above, but I need a way to detect if the script code from the database is a module, so I can either use the import() command or insert a script tag if it is not.
I am solving this temporarily by making sure any module script code has "export const isModule = true", and checking this after calling import(). This works, but any code that is pure script still results in a module variable, but with no exports in it. If possible I don't want the other developers to have to remember to add isModule = true to any modules they develop in the future.
Is there a way to check that code is a module without having to do complex analysis of the code to check if there are exports in it? Since import() still returns an object and throws no errors if there are no exports, I don't know how to detect this.
UPDATE: Here are some examples of how this is intended to work:
// Not real code, pretend that function gets the string of the script.
let code = getSomeCodeFromTheDatabase();
// Save the code for later loading.
let filename = 'some-filename.js';
saveCodeToFile(code, filename);
// Attempt to dynamically import the script as a module.
let module = await import(filename);
// If it is NOT a module, load it instead as a script tag.
// This is where I need to be able to detect if the code is
// a module or pure script.
if (!module.isModule) {
let scriptTag = document.createElement('script');
scriptTag.src = filename;
document.head.appendChild(script);
}
So if you look here How can I tell if a particular module is a CommonJS module or an ES6 module? you will see I answered a similar question.
So the thing is Sarah, modules are defined by the way that they resolve. Module-types resolving differently is what, not only makes them incompatible with one another, but it is also why we name them differently. Originally Transpillers like Babel & TypeScript were invented because of differences in ECMA-262 Specifications, and the desire to support people who didn't have the updated specifications, as well as supporting the newer features for those who did.
Today transpilers are still being used, conceptually, much the same way. They still help us maintain a single code base while supporting older specifications, and features in newer specifications, at the same time, but the also have the added benefit of being able to generate multiple different builds from a single code base. They use this to support different module types. In node.js, the primary module-type is CJS, but the future lies in ESM modules, so package maintainers have opted to dual build the projects. The use the TypeScript Compiler (aka Transpiler) to emit a CJS build, and an ESM build.
Now this is where things get complicated, because you cannot tell just by looking at a module if it CJS or ESM in this situation, **you absolutely have to inspect its code, and check if it has more than one tsconfig.json file (because it would need at-least 2 to maintain a bi-modular build (which are becoming increasingly common with the turn of each day)
My Suggestion to You:
Use well documented packages. Good packages should be documented well, and those packages should state in their README.md document, what type of package/module they are, and if the package supports more than one module type. If in doubt you can either come and ask here, or better yet, you can ask the maintainer by creating an issue, asking them to add that information to their README.md document.
You can check that there are no export after import. In chrome import() added empty default for non module.
function isNotModule(module) {
return (!Object.keys(module).length) || (!!module.default && typeof module.default === 'object' && !Object.keys(module.default).length)
}
import('./test.js')
.then((module) => {
console.log('./test.js',isNotModule(module))
})
May be it's better to check source code via regex to check if it contains export
something like this
const reg = new RegExp('([^\w]|^)export((\s+)\w|(\s*{))')
reg.test(source)
We have some QUnit javascript tests running in Visual Studio using the Chutzpah test adapter. Everything was working fine until we changed our api (the one being tested by the js files) recently, and added some validations over the UserAgent http header. When I tried to update the tests to change/mock the user agent I realized it was not directly possible even by overriding the default browser property.
After a few days of scavenging, I finally found what exactly is happening. Chutzpah is creating a phantomjs page object for the test files to run on. This is being done on a base javascript file (chutzpahRunner.js) located at the Chutzpah adapter installation path. These are the last lines on the file, that effectively start the tests:
...
// Allows local files to make ajax calls to remote urls
page.settings.localToRemoteUrlAccessEnabled = true; //(default false)
// Stops all security (for example you can access content in other domain IFrames)
page.settings.webSecurityEnabled = false; //(default true)
page.open(testFile, pageOpenHandler);
...
Phatomjs supports changing the user agent header by specifying it in the page settings object. If I edit this chutzpahRunner.js file in my machine, and manually set the user agent there, like this:
page.settings.userAgent = "MyCustomUserAgent";
My tests start to work again. The problem is that this is not in the project itself, and thus cannot be shared with the rest of the team.
Is it possible to change the properties of the phantomjs objects created by Chutzpah to run the tests? I'd like to either change them from inside my own tests, or from another script file I could embed on the pipeline.
Without a code change in Chutzpah it is not possible to set those properties on the PhantomJS object. Please file an issue at https://github.com/mmanela/chutzpah asking for this functionality and then fork/patch Chutzpah to add it (or wait for a developer on the project to hopefully get to this).
Update:
I pushed a fix for this issue. Once this is released you can use the following in a Chutzpah.json file:
{
"userAgent": "myUserAgent"
}
I need this because the license information, I'm looking a way to know if the app is running in debug or production mode.
If the app is running in debug mode, I need to use Windows.ApplicationModel.Store.CurrentAppSimulator otherwise I need to use Windows.ApplicationModel.Store.CurrentApp
So, I'm looking for a implementation of the function isDebug:
var currentAPP;
if (isDebug()) {
currentApp = Windows.ApplicationModel.Store.CurrentAppSimulator;
} else {
currentApp = Windows.ApplicationModel.Store.CurrentApp;
}
Any tricks?
Debug.debuggerEnabled tells you if a debugger is attached.
Note that this isn't the same as "It was compiled as debug" -- since JS isn't compiled that isn't really a meaningful indicator.
Take a look at WinJS are there #DEBUG or #RELEASE directives?
The answer there references a handy NuGet package (https://www.nuget.org/packages/WinRT-JsDebugSymbols/1.0.0) which once added and referenced in your app enables a simple check to see if it was compiled with the Debug profile:
if (Debug.isDebugBuild) {
//spot to put debug build only code
}
Given that both these methods are not entirely reliable, there is another approach through which you pick up the build target setting directly from Visual Studio, and then use that to bring in a debug or release file.
Here's how. Create two .js files in the project (debug.js and release.js in a js-buildinfo folder) and make sure to exclude them from the end package by setting their Package Action to None instead of Content (right click, select Properties, and you'll see the actions under Solution Explorer).
Here are basic file contents:
debug.js:
(function () {
"use strict";
WinJS.Namespace.define("BuildInfo", {
isDebugBuild: true,
isReleaseBuild: false,
config: "Debug",
currentApp: Windows.ApplicationModel.Store.CurrentAppSimulator
/*
* Include debug-only data, service URIs, access tokens, accounts, etc.
*/
});
})();
release.js:
(function () {
"use strict";
WinJS.Namespace.define("BuildInfo", {
isDebugBuild: false,
isReleaseBuild: true,
config: "Release",
currentApp: Windows.ApplicationModel.Store.CurrentApp
/*
* Include release-only data, service URIs, access tokens, accounts, etc.
*/
});
})();
You'd then use BuildInfo.* anywhere in your code you need to differentiate. Better still, encapsulate build-specific stuff in these files as much as you can, e.g. the CurrentApp vs. CurrentAppSimulator, calls to WinJS.Log.startLog, etc.
Then use an MSBuild task to selectively copy one or the other file to a common name in the package (e.g. buildinfo.js). To do this, it’s necessary to add a BeforeBuild action in the project file. At present, VS doesn’t allow custom build configuration for JS projects through the UI, so you have to do the following:
Right click and Unload Project in VS
Right click and Edit the project manually
Make the changes below
Right click and Reload project
Editing the .jsproj file I added the following entries under the ItemGroup with the project files:
<ItemGroup>
<BuildFlagSource Include="js-buildinfo \$(Configuration).js" />
</ItemGroup>
<ItemGroup>
<BuildFlagDestination Include="js\buildinfo.js" />
</ItemGroup>
And then farther down there’s a section that’s commented--you uncomment it and add the element shown here:
<Target Name="BeforeBuild">
<Copy SourceFiles="#(BuildFlagSource)" DestinationFiles="#(BuildFlagDestination)" OverwriteReadOnlyFiles="true" SkipUnchangedFiles="true" />
</Target>
<Target Name="AfterBuild">
</Target>
<PropertyGroup>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
</PropertyGroup>
Ideally you’d make buildinfo.js read-only in the project to prevent editing what will be overwritten in the build.
And the you can just have this line in whatever HTML files need it (usually before other .js files that would use the BuildInfo properties):
<script src="/js/buildinfo.js"></script>
Things I like about this solution:
It’s extensible as you can add anything you want to the debug.js and
release.js files.
The BuildInfo namespace can include methods to do build-specific work, which is sometimes necessary.
It enables isolation of all build-specific code in these files, rather than littering it throughout the rest of the app as you would with just a simple flag. I still have a flag in here as an option, but you wouldn’t have to use that at all.
It works no matter how an app is deployed.
It’s not dependent on any compiled VS extension that you’d have to produce for x86, x64, and ARM.
A few downsides:
Have to hand-edit a project and do some one-time configuration like adding a buildinfo.js and making it read-only.
You have to make sure that the debug.js and release.js files define the same stuff.
It feels a bit fragile given the manual steps.
But it does work and is the closest I've come to precompilation directive with other languages.
Right off the bat, this is not your standard "I can't get javascript IntelliSense to work in Visual Studio." For the record:
I'm using Visual Studio 2008
I have installed SP 1
I have installed the hotfix for -vsdoc.js documentation files KB958502
I am developing a suite of interrelated jQuery plugins to be packaged as resources in a class library. So within a directory, I have (as an example):
jquery-vsdoc.js
core.js
plug1.js
plug2.js
In core.js, I have the following at the top of the file:
/// <reference path="jquery-vsdoc.js" />
Then in each of the plug#.js, I have:
/// <reference path="jquery-vsdoc.js" />
/// <reference path="core.js" />
The IntelliSense works initially, even including the additions from core.js when working in the plugins. However, sometimes the slightest change, even adding and removing a space from the reference XML tags, or pressing Ctrl-Shift-J, results in the dreaded "Error updating JScript IntelliSense: Client-side script IntelliSense information was not generated due to an error in an external script reference." Except it was working with that external script reference just a second ago!
For the jquery-vsdoc.js, I am using Comment Version 1.3.2b (that's what it says in the file) from http://jqueryjs.googlecode.com/files/jquery-1.3.2-vsdoc2.js. I am omitting the version number from the file so that I don't have to change a bunch of references when it's inevitably updated.
So what could be the problem? Restarting Visual Studio is proving to be a horribly inelegant (and time-consuming) workaround.
Have you tried increasing the IntelliSense timeout?
By default, every IntelliSense request
is only allowed 15s to execute. This
is to prevent IntelliSense from
scripts with infinite loops. If you
have a large script or slower machine,
it may make sense to increase the
timeout limit. The timeout value
store within following registry keys
(depending on if your are using
Express or the full product). The
value is in milliseconds so choose
something greater than 15000.
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\HTML
Editor\JsFailsafeTimeout
HKEY_CURRENT_USER\Software\Microsoft\VWDExpress\9.0\HTML
Editor\JsFailsafeTimeout
Does closing and opening the file reset the state?
Open the task manager and watch the processes. Do you see a process called "typelibbuilder.exe" get started when you press Ctrl-Shift-J?
I'm trying to image what sort of problems might require a restart of VS. The processing of references (to which that message pertains) is done in a new and separate process every time you press Ctrl-Shift-J (unless processing has been disabled in which case you would see a different message). It almost sounds like the communication between VS and typelibbuilder or some other necessary component is failing.
In SP1, you shouldn't need to reference the "-vsdoc" files directly. If you reference "foo.js" and there is a "foo-vsdoc.js" file next to it, then VS will use the vsdoc version to generate intellisense. I doubt that is related to your problem though.
I know this isn't much consolation, but we've drastically improved performance and reliability of Javascript Intellisense in Visual Studio 2010. Beta1 is currently available to MSDN subscribers (although it is beta and there are still some bugs in it).
If you can get reliable repro steps, you could also file a bug report at http://connect.microsoft.com/.
I dont know if this will help you, but I've encountered the following bug in VS 2008 JS intellisense:
When adding jQuery as a reference in an external file, and then I update JS I get:
'XmlHttpRequest is undefined' on the line:
return window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();
It seems like the JS intellisense engine is actually executing some of the jQuery code (more than likely to inspect it so it can provide some more information about it). However it looks like window.ActiveXObject is null to the engine, and so it falls into the 'new XMLHttpRequest()' block - which also fails.
I hacked a workaround that breaks all browsers except IE - so not a good solution. My fix changes the following:
xhr: function()
{
// hack to fix VS 2008 intellisense... note this breaks any browser
// except IE
var objXhr = { open: function() { },
setRequestHeader: function() { }
};
return window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : objXhr;
},
Now my intellisense works.
You may want to disable JavaScript intellisense in Visual Studio.
When SP1 is installed you can disable JavaScript intellisense.
Go to Tools, Options...
The Options dialog will show up.
Navigate to the following node in the left hand sided panel:
Text Editor :: JScript :: General
Disable the following options (in the group Statement Completion):
* Auto list members
* Parameter information