Ember.js Namespace Issues - ember.js

I have an Ember.js application I have been developing and which has been working great. I am now attempting to integrate in a SIP over Websockets library called JsSIP. Both my Ember app and a separate proof-of-concept SIP app work great independently; however, as soon as I integrate the two together I start seeing weird errors in the SIP library. I finally narrowed things down to the fact that it's a namespace issue between the 2 APIs
I have seen at least one other SO question regarding namespace conflicts between Ember.js and other libraries which do any sort of DOM manipulation (such as JQuery Mobile). To my knowledge, the SIP library I'm using is doing very little if any actual manipulation of the DOM. I have seen some suggestions for using RequireJS, although I really didn't want to have to modulize my client and don't even know if it would solve the namespace conflicts. Would wrapping things in an Ember.Namespace help?
I've created a super simple JSFiddle which demonstrates the core issue. Any suggestions on how I might go about solving this issue between the 2 libraries are greatly appreciated. Here's the bare bones code which is included in the Fiddle:
// JsSIP code
try
{
var configuration = {
'uri': "example#sip2sip.info",
'password': "password",
'trace_sip': true,
'ws_servers': "ws://example.com"
};
myPhone = new JsSIP.UA(configuration);
myPhone.start();
}
catch(e)
{
console.log(e.message);
}
// Ember code
window.App = Ember.Application.create();

The construction of JsSIP.UA is transforming ws_servers into an array and iterating over it with for(element in array), which trips in extensions to the Array prototype made by Ember.js. You can disable that with the following code for your SIP library to work out of the box (add it before including the Ember script):
window.Ember = {};
Ember.EXTEND_PROTOTYPES = false;
This can have a big impact on your Ember app, though. Read this documentation page to learn more: http://emberjs.com/guides/configuring-ember/disabling-prototype-extensions/

Related

Disable fake GPS location using ionic2 typescript

I am creating an application using Ionic2 with angular2 and Typescript2. the main idea of the application is to detect the user location.
and due to the need to make sure that this data is correct we need to make sure that users don't fake their locations.
after a lot of search I found the following answer Detect or avoid mock GPS location but this answer can't help me a lot because this plugin uses javascript not typescript and i am facing a problem in using it
So, Is it possible to check or preventing a user from faking their GPS location?
Typescript IS JavaScript.
You have three options to operate the plugin and let typescript compile
Declare it as a known javascript var
declare var plugins;
plugins.fakeLocation.check(function(IsEnabledMockLocations){
console.log(IsEnabledMockLocations);
});
Writing a custom typing for it
declare namespace plugins {
export namespace fakeLocation {
export function check(callback: Function): void;
}
}
Use any casting
(<any>window).plugins.fakeLocation.check(function(IsEnabledMockLocations){
console.log(IsEnabledMockLocations);
});

Ember CLI test intermittently failing

I'm having a problem where when running my Ember tests. Once in every 3-5 tries it hits errors before running any tests. When I run in server mode I can see this output:
ReferenceError: Can't find variable: EmberENV at http://localhost:7357/3256/tests/index.html?hidepassed, line 42
ReferenceError: Can't find variable: define at http://localhost:7357/assets/test-loader-53146f185443881bff29aab3e80079e2.js, line 3
ReferenceError: Can't find variable: define at http://localhost:7357/assets/tests-a72d35574ec0d1ab014d4af21210a23a.js, line 1
When I look at the offensive files referenced, they looks like this:
/* globals requirejs, require */
(function() {
define("ember-cli/test-loader",
[],
function() {
"use strict";
var moduleIncludeMatchers = [];
var moduleExcludeMatchers = [];
function addModuleIncludeMatcher(fn) {
moduleIncludeMatchers.push(fn);
};
etc...
As I understand, define() is a function introduced by requirejs, so it seems like it's just not loading before the tests begin. Any idea why this would be, and if there is any way to ensure things are loaded in the proper order?
Other important things; this doesn't seem to be an issue with the individual tests, as deleting them, especially the first which would be hit doesn't make a difference. This looks like it started happening occasionally after a big check in, where among other things, we went from 130 to 174 tests, but nothing particularly strange seems to have been introduced. I've also tried cutting out pieces of the new code with no change, BUT if I revert to the previous version it seems to still work correctly every time. It could just be a matter of the codebase growing larger.
For versions of dependencies:
EmberCLI: 1.13.13
node: 5.4.1
PhantomJS: 2.1.1
Anything else that would be helpful to provide? Thanks.
Forgot to report back here that it has been fixed in my case.
First of all this issue was reported here: https://github.com/ariya/phantomjs/issues/14173, and it's likely caused by some inline import #import url(...) used in css.
The fix in my case is to write an alternative test runner which ignore the network request, similar to what #wagenet suggested in the above issue.
Hopefully that works for other use cases.
We had the same issue and were able to fix it by updating qunit to 1.20.0 in bower.json
"qunit": "~1.20.0",

ember-cli fails on --environment=production (Uncaught Error: Could not find module)

I am using ember-cli and have a problem with selecting the production environment. Specifically, everything works when I run ember serve --environment=development and I get a blank page when I run ember serve --environment=production. In the console, I see:
Uncaught TypeError: undefined is not a function
Uncaught Error: Could not find module simple-auth/authenticators/base
All other things are equal, and all dependencies are up to date. I'm a total noob so I don't even know where to begin on how to debug: is it ember? ember-cli? broccoli? Any help would be appreciated.
I had exact the same problem, and James_1x0 is correct, it is an broccoli issue.
After debugging it occurs, that the "undefined" error apears on "Ember.handlebars.compile" which lead to other research.
It seems, that in production envrironment "handlebars.js" is replaced by "handlebars.runtime.js" in the ember-cli build process, which seem to be a problem for broccoli at this time.
Other devs had the same problem but with other libraries as well:
https://github.com/stefanpenner/ember-cli/pull/675#issuecomment-47431195
Here the solution was to add:
var index = app.legacyFilesToAppend.indexOf('bower_components/handlebars/handlebars.runtime.js');
if(index) {
app.legacyFilesToAppend[index] = 'bower_components/handlebars/handlebars.js';
}
into your Brocfile.js to replace the "handlebars.runtime.js" with the "handlebars.js".
This also fixed the problem for me.
It sure has the drawback that the whole handlebars file is deployed but its a workarround for now, until the problem is fixed.
Solution is mentioned on Ember CLI website:
This is somewhat non-standard and discouraged, but suppose that due to a requirement in your application that you need to use the full version of Handlebars even in the production environment.
Basically, you can pass vendorFiles option to your EmberApp instance which will force CLI to include full version of Handlebars.
Example of explicitly requiring handlebars.js , in Brocfile.js:
var app = new EmberApp({
vendorFiles: {
'handlebars.js': {
production: 'bower_components/handlebars/handlebars.js'
}
}
});
This is recommended way of solving this issue(discussion on GitHub).

Loading bar that tracks completed HTTP requests for Ember.js

I've been looking around, and short of writing a basic one myself, I couldn't find a library that already exists for Ember that displays a small loading line at the top of the page that completes when all the http requests have completed for a page transition (whether that be images loading, JSON being fetched etc).
There's this for Angular: http://chieffancypants.github.io/angular-loading-bar/, but wondering if Ember has any options already.
Cheers.
EDIT: I've found this article as well about a jQuery plugin, which I imagine could be adapted: http://tutorialzine.com/2013/09/quick-tip-progress-bar/. Still keen on hearing if anyone knows of anything already integrated into the Ember request lifecycle though.
You can use fantastic javascript component NProgress (http://ricostacruz.com/nprogress)
and then you can initialize it in Application.ready event using jQuery like this
window.App.ready = function () {
$(document).ajaxStart(function () {
NProgress.start();
});
$(document).ajaxStop(function () {
NProgress.done();
});
};

AngularJS mocking $logProvider in config block

Is there a way to inject providers when writing unit tests using Karma(Testacular) and Jasmine in angular?
Our team decided recently to use angularjs $log to write debugging details to the console. This way we can leverage the ability to disable the logging via the $logProvider.debugEnabled() method.
angular.module("App", ["prismLogin", "ui.bootstrap"])
.config(["$routeProvider", "$logProvider",
function ($routeProvider, $logProvider) {
$routeProvider
//routes here edited for brevity
//This is the offending line, it breaks several pre-existing tests
$logProvider.debugEnabled(true);
}]);
However after adding the $logProvider.debugEnabled(true); line several of our tests no longer execute successfully, failing with the following message:
TypeError: Object doesn't support property or method 'debugEnabled' from App
So my question again, is it possible to mock the $logProvider? Or should I provide my own configuration block for the test harness?
I attempted searching for a way to mock the app module with no luck. It seems to me that using the concrete app module instead of a mock is very brittle. I would like to avoid reworking tests associated with the app module every time a change is made in the app or run configuration blocks.
The tests that are failing are units of code with no relation to the $logProvider? I feel as if I a missing something here and making things much harder than they should be. How should one go about writing tests that are flexible and are not affected by other side effects introduced in your application?
It appears that this is a know issue with angular-mocks.
Until the issue is addressed , I was able to resolve the issue by adding the following method to the angular.mock.$LogProvider definition in angular-mocks.js at line 295.
this.debugEnabled = function(flag) {
return this;
};