Can't initialize Vuforia about argon HOT 11 OPEN

Hmm... seems to be, not a mistake, but perhaps some code that can lead to a problem in the Vuforia demo (TypeScript). Here's the issue:

app.vuforia.isAvailable().then(function(available) {
    // vuforia not available on this platform
    if (!available) {
        console.warn("vuforia not available on this platform.");
        return;
    } 

// tell argon to initialize vuforia for our app, using our license information.
app.vuforia.init({

I put the app in an instance variable and so I called it with this.app. And that broke because the isAvailable promise handler doesn't use fat arrow syntax. That could be avoided if the demo code started with this:

app.vuforia.isAvailable().then((available) => {

I guess if there's a takeaway, it's a little unfortunate that "the wrong this" manifested as the cryptic __proto__ error instead of the app.vuforia.init function returning a failed promise with a useful error message.

from argon.

So, just to help me understand, in are you actually trying to use this.app inside the promise returned from init and/or isAvailable, or is the promise failing in some other way? I would agree with you that using the fat arrow syntax in the sample might be good, for all the reasons the fat arrow was created. (For example, if I go and look at my argon-aframe code right now, I have the usual var self = this; at the top of various functions that use callbacks, and then use self inside them).

Of course, in some of those cases, I'm using this and self because I need the object that triggers the callback, but in promises we can just use that syntax, right? (Also, since we're using Typescript, we don't have to worry about browsers not supporting the ES6 syntax because we target ES2015).

from argon.

@speigg do you agree, I think we should change the various promise callback functions in the Typescript samples to use fat arrow syntax, just to avoid this sort of thing when people repurpose the code.

from argon.

Yes, I have code like, er, this (copied from the example but with some this. prefixes added):

this.app.vuforia.isAvailable().then(function(available) {
    // vuforia not available on this platform
    if (!available) {
        console.warn("vuforia not available on this platform.");
        return;
    } 
    // tell argon to initialize vuforia for our app, using our license information.
    this.app.vuforia.init(...).then(...);
});

The non-fat-arrow syntax on the first line causes the "this.app" on the second-to-last line to result in the error mentioned all the way above:

ERROR Error {
  __proto__: Error
}

So the solution for my specific case is to change that first line to use fat arrow syntax (which fixed the problem).

But that leaves two other questions:

1. Can the Vuforia example be changed to use fat arrow on that first line, just to avoid the kind of problem I had when tweaking it a bit?
2. Can the library be changed so that calling app.vuforia.init with the wrong "this" makes the returned promise throw a descriptive error, instead of having the returned promise never resolve and emitting the not-very-helpful __proto__: Error?

from argon.

This really just amounts to a bug in the way we display errors in the console. app.vuforia.init doesn't have to be changed, as in your case it was never actually being called (let alone resolved), since this.app was undefined. So that cryptic error was instead supposed to be an error telling you that this.app is undefined on the line where you had this.app.vuforia.init. We'll fix that (in the Argon browser).

For the samples, we can certainly switch to the fat arrow functions.

from argon.

ok, I'm changing the vuforia sample. Not sure how to change the library to help; if you can see how, perhaps submit a PR?

from argon.

Well, maybe I'm confused by where the error is originating.

If "this.app" was undefined, I would have expected an error more like "property vuforia doesn't exist on 'undefined' when calling 'this.app.vuforia.init' ". I feel like I've seen that sort of thing a lot. Maybe it's more browser-dependent than I realize, though?

from argon.

If "this.app" was undefined, I would have expected an error more like "property vuforia doesn't exist on 'undefined' when calling 'this.app.vuforia.init' "

Yeah, that's exactly what the error should have been. This is a bug in how we are handling and presenting errors in the browser. We'll see if we can figure out why that is and fix it.

from argon.

I'm having the same issue with my app .
I try to initialize vuforia but i get nothing in the argon4 console .
My code is as follows :
app.vuforia.isAvailable().then((available) => {
// vuforia not available on this platform
if (!available) {
console.warn("vuforia not available on this platform.");
return;
}
// tell argon to initialize vuforia for our app, using our license information.
this.app.vuforia.init({
encryptedLicenseData: "my encrypted licence"
}).then((api) => {console.log('yes');},
(err) => {console.log('no');
});
});

The object returnded by "app.vuforia.isAvailable()" seems to be empty.

from argon.

Without seeing the actual code it's impossible to say what might be wrong. Can you please post a link to something that does this?

Obvious questions are: is argon initialized? What other errors / messages are there? How do you know it's returning an empty object (and what does "empty" mean?)?

from argon.

The code is the same as the vuforia sample , with my licence key .(nothing else has been changed)
There are no errors or warnings .
By "empty" i mean that when i put the object in console.log it shows an empty object .
this is my code https://argon-denisdautllari.c9users.io/docs-gh-pages/code/4-vuforia/app.js

from argon.