success doesn't mean success about google-apis HOT 10 CLOSED

Can you provide a reduce test case?

from google-apis.

Hi Eric,

It's is a bit tricky for me to reduce my app to something simple, but I've tried here :

https://github.com/davidmaxwaterman/google-api-loader-test

It's not working yet, but you can at least see something similar to what I'm trying to do. It is simple, so I hope you can spare the time to take a look at it and make comment.

Note that in my real app, I'm getting the access token from the background script using the chrome.identity api. That works fine, but trying to use that in the google-api-loader is proving unreliable, mostly due to the google-api-load signal being fired even though the api isn't yet added - though it depends on timing, so it might.

Note also that my real app is an extension and has a content script add polymer elements onto a web page, and it is in this latter context that these elements are running. The elements are added just fine - I know some have claimed this technique doesn't work, but I have many of them and they all work as expected, so that isn't the problem.

I'm using promises. This is mainly because I have to wait for the access_token from the background script, which is delivered via an event, and also I have to wait for the google-api-load event from the loader. Multiple events shout promises to me, and my element's method also has to return a promise, so I might as well use them.
When I get the access_token, I set it on the auth object - I've tried via self.$.auth.setToken() and also directly on the gapi.auth object. I'm not sure if there's any difference in the two, but I'm preferring the former in case the polymer elements are doing anything extra when it gets the token.

Like I say, I have a version where the timing works fine, but change anything significant and I find that the drive object actually isn't there (yet) even though I've received the google-api-load event.

Any ideas?

from google-apis.

Hey, I found this :

http://stackoverflow.com/questions/11315962/google-drive-api-javascript

and when I use gapi.client.request() directly, instead of gapi.client.drive.files.list(), or self.$.drive.api.files.list(), then everything seems much more predictable.

Is there some problem with the api, or is this some caching problem?

from google-apis.

Not entirely sure, but could it be because you're adding the event handler in within the promise? If you use declarative event handling instead, does it always work?

<google-api-loader on-google-api-load="{{gapiLoaded}}">

from google-apis.

No, it has the same problem - I was doing what you suggest before I switched to promises, basically setting a flag to say I'd received the event and checking the other one before calling a function that needs both.

Basically, imo, the api loaded event fires too early.

from google-apis.

Due to the permissions/tokens/etc of the real app, I don't think it's too easy to make a reduced test case that will just work - you would need to set up the developer's console/etc. and all that.

Actually, I think the issue is actually not polymer related since the same issue occurs when using the gapi apis directly - as per the SO question and top-rated answer. If you use that answer for polymer, it is also successful (presumably for declarative event handlers too, though I've not tried it).

With that in mind, I'm wondering how to take this forward. Perhaps this should be closed, and moved to somewhere else...any idea where should issues with gapi be filed?

from google-apis.

Maybe https://code.google.com/p/google-api-javascript-client/issues/list?

from google-apis.

thanks Eric...that'll do nicely. I think this can be closed then.

from google-apis.

FWIW, https://code.google.com/p/google-api-javascript-client/issues/detail?id=171
Feel free to add any other thoughts since my understanding of the apis is limited.

from google-apis.

More...I determined that even the workaround mentioned in SO isn't reliable, and I've basically switched to using the http interface via core-ajax, and that seems to be reliable (after a couple of days).

from google-apis.