Using the developer version of video.js 4.0 I'm able to reinitialize a video by simply emptying the players variable before the reinitialization: videojs.players = {};.
However, this is not possible using the minified video.js variant, as the variable's name is minified too. This leads me to the assumption, that what I'm trying to achieve is supposed to be done another way.
How do you solve this issue?
UPDATE
Since version 4.1, the variable videojs.players ist exported. However, the reinitialization does not succeed using the original minified js file. Can anyone confirm that?
Related
I've working on modification of the 'shoutem.notification-center' extension using as a guide this tutorial and I'm having some issues.
At first I tried to use the Extend the extension approach, but like I've posted on this issue, didn't quite work.
So I've tried the Directly modify approach, which works fine on my local phone, but once I use the command shoutem push to send my modifications to the server, the instance on Appetize never stops the 'Building your application' message.
The major problem is that there's no error code or feedback.
That was not the first time that happened, I had the same issue modifying other extensions. Any idea why this is happening?
The issue is likely one of two things.
New native dependencies were added that the Builder preview cannot process due to it's predefined binary.
Your directly modified extension works locally, but not on the Builder because locally it's path is still AppName/extensions/shoutem.extName, but on the Builder it's AppName/extensions/yourDevName.extName, so it fails.
The first one can be resolved by either using a non-native solution as a replacement for the native dependency you were using, or to simply use a local emulator for previewing purposes.
The second can be resolved by making sure all extensions that reference the one you directly modified are edited to now reference your new directly modified extension instead of shoutem.extName.
If you could shoot me your app ID in a comment I can let you know which one it is and what the best steps to fix it would be.
I'm trying to get Enquire.js working for legacy browsers. I'm using the Deep support method from the docs:
Modernizr.load([
{
test: window.matchMedia,
nope: "media.match.min.js"
},
"enquire-2.0.0.min.js",
"plugins.js", // jquery plugins
"main.js" // enquire-triggered functions + general code
]);
The problem with this is I am using Modernizr+Respond from initializr.com, so the test always passes. This triggers a JS error in enquire.js in IE8/9.
By removing respond.js and just using plain Modernizr the test fails, Media.match loads, and the JS error is solved. However, I lose my Media Query support in IE8.
What's the best method to get everything working together? I have tried loading respond.js at the same time as Media.match via Modernizr. If I load it first, I see the same JS error as before. If I load it second, media queries don't work. I've also tried just loading that INSTEAD of Media.match, but the JS error returns.
Thanks.
EDIT:
Shortly after posting this I rolled back to enquire 1.5.6, used Respond.js, the shouldDegrade option, and no Modernizr tests. No JS errors in IE8/9, and everything seems to be working fine so far.
I am still interested to know if there's a way to get this working with 2.0, or if I should stick with the 1.5.6 for now?
I ran into the same problem with Enquire v2.0.2. My workaround was to remove the inclusion of matchMedia from respond.js, and then load media.match and enquire.js after loading respond.js. I haven't tested this with modernizr yet, but I was able to get media query support and enquire.js to work in IE7 and 8 with no JS errors.
I guess the actual problem is that in respond.js you do have the matchMedia polyfill but without the matchMedia.addListener plugin. So the modernizr test for plain matchMedia succeeds but then results in the error you probably get with enquire (Object doesn't support this property or method).
I myself wouln't like to customize respond.js not to include matchMedia but rather just load the matchMedia.addListener plugin separately after respond.js.
Tim,
A little late but did you see this yet? I think it's what you are looking for.
enquire.js legacy support
Does anybody know what if direct update updates everything that lives in the common directory structure. I used the same code base for multiple apps, the only change being certain settings within a js file that tells the application how to act. Is there a directory i can put that js file that would be safe from the direct update feature?
I cant seen to find any specific information on IBM's website.
I think you guys need to be careful which terms you are using in order to not confuse people who may be looking for similar help.
Environments are specific to the OS you are using. iOS, Blackberry, Android, and etc. environments.
Skins are based on the environment, and aren't generic to all platform. When you create a skin you must choose which environment you are running in.
So to correct some, direct updates will update all skin resources in targeted environments.
For example: You have an app with Android and iOS versions
When you create skins, you are creating essentially a responsive type of design to your parameters. For instance, if you have a 2.3 vs 4.2 Android OS, you can set a look and feel for both. However, these utilize a single web resource base. The APK would be the same for both versions of the app (by default) and have 2 available skins. On runtime utilizing IBM Worklight's 'Runtime Skinning' (hence the name) it goes through the parameter check for the OS and loads that skins overriding web code.
You could technically override all of the web code to be completely different for both skins, but that would be bulky and inefficient.
When you direct update you are updating all the resources of that particular environment (to include both skins), not the common folder/environment.
So an updated Android (both skins) would have updated web resources (if you deployed the android wlapp) and an iOS version would stay the same.
If you look at the Android project after build (native -> assets -> www -> default or skin) you can find the shared web resources generated by the common environment. However that is only put there every time you do a new build.
In the picture, I have an older version of the Android built for both skins on the left. On the right is a preview of the newer common resources after deploying only the common.wlapp. So you can see that they are separate.
Sorry if it was long winded, but I thought I would be thorough.
To answer the original question, have you thought of having all the parameters of the store loaded from user input or a setup? If you are trying to connect to 3 different store, create some form for settings control that will access different back ends or specific adapters. You could also create 3 different config.js that load depending on the parameters that you set so that you set. The other option is to set different versions of your apps specific to the store.
Example. Version 1.11, 1.12,1.13 can be 3 versions of the same app for store 1, 2, & 3. They can be modified and change and have 3 sets of web resources. When you need to update, jump up to version 1.21, 1.22,1.23. It seems a bit of a work around, but it may be your best bet at getting 3 versions of the same app to fall within the single application category. (keep 3 config.js types for modifying for the 3 stores).
To the best of my knowledge Direct Update will update every web resource of the skin you're using (html, css, js). However, I'm no expert with it.
If you're supporting only Android and iOS applications and need a way to store settings I recommend JSONStore. Otherwise look into Cordova Storage, Local Storage or IndexedDB.
Using a JSONStore collection called settings will allow you to store data on disk inside the app's directory. It will persist until you call one of the removal methods like destroy or until the application is uninstalled. There are also ways of linking collections to Worklight Adapters to pull/push data from/to a server. The links below will provide further details.
the only change being certain settings within a js
Create a collection for your settings:
var options = {};
options.onSuccess = function () {
//... what to do after init finished
};
options.onFailure = function () {
//... what to do if init fails
}
var settings = WL.JSONStore.initCollection('settings',
{background: 'string', itemsPerPage: 'number'}, options);
You can add new settings after initCollection onSuccess has been called:
settings.add({background: 'red', itemsPerPage: 20}, options);
You can find settings stored after initCollection onSuccess has been called:
settings.findAll({onSuccess: function (results) {
console.log(JSON.stringify(results));
}});
You can read more about JSONStore in the Getting Started Modules. See Modules: 7.9, 7.10, 7.11, 7.12. There is further information inside the API Documentation in IBM InfoCenter. The methods described above are: initCollection, add and findAll.
Since version 5.0.3 I think, direct update will not update all the webresources, only those of the skin you are using.
say you have skin def and skin skin2
you are on def
make change to def on the server -> you will get a direct update for
def only
make change to skin2 on server-> no direct update for you.
you are on skin2:
make change to skin2 on server -> direct update for skin2 only
make change to def javascript which also resides on skin2 ( and therefor end result is def+skin2 concatination), update only skin2
make change to def,just to a picture(also checking pic extension from application-descriptor: ") -> no direct update
Thats how direct update works.
Please also share some more details about what is the problem, I see you use a js file, where do you change it? what do you mean excatly, give a better (simplified) real life example, because it is unclear what you are trying.
I'm trying to follow the basic cometd example here: http://dojotoolkit.org/reference-guide/1.7/dojox/cometd.html
It's using the old module loader so I tried the equivalent as follows:
require(["dojo/ready","dojo/io/script","dojox/cometd","dojox/cometd/callbackPollTransport"], function(ready, dontcare, cometd) {
ready(function(){
cometd.init('http://localhost:8080/MyCometD/cometd');
comted.subscribe("/test", function(msg){
console.debug(msg);
});
});
});
This doesn't work and I think it has to do with loading modules - there is some sort of silent error as the code within the ready function does not execute at all. What I found is that when the "dojox/cometd" require statement is present, the code within the ready function does not execute.
Running example: http://jsfiddle.net/Q9W8f/2/
Example with dojox/comted removed: http://jsfiddle.net/mMs2h/4/
I haven't worked with the new module loader that much so I bet I just have some simple misconception.
Help!
It seems like youre correct and that there is a 'wait-loop' for a module requirement that never gets loaded. This may be any of the requirements inside dojox.cometd and you'd need to rewrite the codebase for a fix.
I have had similar issue with the RollingListPane, also in dojox repository - and the developers are saying 'we are 100% AMD compliant with 1.7' however the X in dojox is short for experimental. The developement of dojox modules is not done by the core djtk team and there are still glitches..
Try for starters to avoid using CDN which has performed a >>built macro on every single module. This tends to fail at times whilst using AMD. Instead download the tarball and use a local copy - Not compressed (dojo-release-1.7.2-src)
You can find the hello world example in cometD and ExtJs at following link:
http://jksnu.blogspot.in/2013/08/network-reliability-by-cometd-hellow_16.html
I'm trying to use groovy scripts in my application. The problem is that GroovyScriptEngine#run always compiles the script, even if it was compiled in previous runs and hadn't changed since. Even if I set a physical output folder to save compilation results in the configuration.
What is the best way of working around this? The optimum for me is that I'm able to send the script with a folder containing precompiled results and no compilation is done (unless the script is modified of course)
Grails 1.3.5 is using Groovy 1.7.5. In that Groovy version, GroovyScriptEngine.run(..) calls the following methods: createScript(String, Binding) --> loadScriptByName(String) --> isSourceNewer(ScriptCacheEntry).
isSourceNewer(ScriptCacheEntry) is defined as (unfortunately, I didn't find a matching source file on the web):
protected boolean isSourceNewer(ScriptCacheEntry entry)
throws ResourceException {
// ...
for (String scriptName : entry.dependencies) {
// ...
return true; // without any further condition!
}
return false;
}
Which implements the (queer) logic "if a script has dependencies, it is newer than the cached script (and needs to be re-compiled)". That's not what the code is supposed to do; it's supposed to decide by modification time.
In newer versions of GroovyScriptEngine, this has been corrected (there've been massive changes to the logic), but for now, you'd need to subclass GroovyScriptEngine and overwrite isSourceNewer(ScriptCacheEntry) to fix the logic yourself.
Edit: The bug has been reported and fixed in Groovy 1.7.6. - So try using Groovy 1.7.6 in your Grails lib folder.
The solution (hack) I used at last was to stream out the scriptCache variable using xstream and to read it back and set it in the object
Not sure if this helps you, but you can alter GroovyScriptEngine's behaviour using CompilerConfiguration (see GroovyScriptEngine.setConfig). There's an option CompilerConfiguration.setRecompileGroovySource, which can be used to set whether the sources will be reloaded and recompiled if they change. You can read more about CompilerConfiguration here (page 282).