Well i have just tried the sample example of real time js Google drive api. As they said in their tutorial,the application's text areas will be synced even if they are opened in different browser windows. But here the application is not doing that. It only reflects changes to the text areas of same browser window.
Here is the link: Google Drive Realtime JS API
Is there anything that i miss? I am running my application in Koding.com's vm.
Starting the quickstart app with the base url will cause it to create a new document.
To view the same document twice, you can copy-paste the full url after its loaded, which should include a document id, or open an existing document from drive with your app.
Related
I'm new to the Google APIs, and would like to write a small service class for my web application that:
creates blank Google document without user assistance
assigns a generated title
returns a URL that can be provided to multiple people to edit this document
This document mst be editable via a sharing link. Ideally it is owned/managed as part of the web service's Drive storage.
Code is welcome if it's easier than explaining, but I'm really asking for help understanding Google's service offering.
Can I fully authenticate using only credentials specific to my app? (e.g. call the Drive API without prompting an interloper/observer/user to
authenticate.)
Once authenticated, can I create documents local to my
API?
Whose quota are the created documents consuming, the person that created the API key?
Can I share
these created documents with others?
Will I be able to manage a list of
these created file URLs from a standard Google web UI?
Just to clarify what it is that you are asking. You want to be able to embed a google doc on your website A couple things that can happen here.
First, you will need to create a google doc, lets say a spreadsheet. Within that spreadsheet you will:
click File > Publish to the Web.
From here a new window will be brought up. Click Embed and Published content and settings and click the publish button. Ensure the Automatically republish when changes are made checkbox. (this will allow for your website to be automatically updated anytime that doc is changed.
Take the embedded link that is generated and plop it in your webpage and it will be live.
Now you can share the page via Google Docs and anyone that has that link can make changes to that spreadsheet. As soon as a change is made, it will update on your website with the next refresh.
Hope this is all clear, let me know if there is anything unclear.
Cheers
UPDATE: I have found a solution. This doesn't necessarily address every case, so I will leave the question open for a short time in case someone can enlighten me more. I solved it by changing the format of the url: Google Drive allows this format for downloading files:
https://docs.google.com/uc?export=download&id=FILE_ID
So I don't know if this is a problem for other URL's; nor actually exactly why the .getDownloadUrl() doesn't work ... maybe someone can explain. But for now this seems to work in the browsers that I can test ...
I have a simple WebApp script which I run on a Google Site by adding the Apps Script gadget. The gadget runs exactly as the Forms example on:
https://developers.google.com/apps-script/guides/html/communication#forms
The gadget is designed to do the following: when the page is loaded, a form is returned, and the user must enter a license key to get a link to download a product. My code serves the form OK, and gets the form submit OK; and it then validates the key, and if valid, sends back a link to download. All that works fine; and the problem is that no matter what I try to return for the download link, the caja iframe wrapper is preventing the click on the link from actually downloading the file.
My preferred URL to return is in fact via the Drive API: the download file is on the Google Drive, and I get the download link like so:
DriveApp.getFileById(downloadFileId).getDownloadUrl()
But when the returned link is clicked inside that caja iframe generated for the WebApp gadget, nothing happens. I have tried a few other URL formats pointing to that file on the Drive, but nothing is working for a download.
Is this possible?
.getDownloadUrl() method returns a temporary URL that can be used to download the file. This URL is valid only for a short period of time, after which it expires and does not return the file any more - that is probably why the links in your web app do not work. Can't remember exactly how long the URL is valid for, but I think it could be as short as 5 minutes.
Permanent download URL is stored in another file property: webContentLink. However, this property is not (yet) available through Google Apps Drive Service - you must use Advanced Drive Service to access it. You can enable Drive API under Advanced Google services in your script. After it is enabled, you can use it like so:
var file = Drive.Files.get(FILE_ID_HERE);
var dlUrl = file.webContentLink;
This will return the link just like the one you found and posted in your update. An advantage of using the Drive API to get the link, instead of hard-coding it, is that if Google ever changes the format of that URL, your code using Drive API to get the link will continue to work, while hard-coded links will not.
Full Drive Web API reference (what Advanced Drive Service uses) is at https://developers.google.com/drive/v2/reference/.
I have created a realtime document on Google Drive. When I attempt to share this file with someone who doesn't have my app installed, the file shares successfully, but when they click the file it says "Sorry, no preview is available".
This realtime document is a shortcut file. How do I get it to prompt the person to authorize my app?
I'm using the Realtime Playground as my example as I'm not sure of the specifics of your application.
App authorisation
When you created your application you visited the Google API Console and created a project with Drive API enabled. At some point you copied "Client ID" from the Google API Console into you application ID code.
In the realtime-playground case APP_ID is set in the javascript file rtpg.js (you might not be using JavaScript but there will be an equivalent step for other languages).
rtpg.APP_ID = '840867953062';
File creation
I believe that any drive realtime document/shortcut you created with your application will contain a reference to the creating application (mostly likely in the form of the client/application ID you obtained above).
File sharing
Once you can see your newly created Google Drive Realtime document/shortcut you can share this with somebody else using the normal Google Drive sharing methods. At this point they can see it but cannot do anything apparently useful with it. This is where I believe your application may differ from the realtime-playground example.
Integration with Chrome Web Store
On the GitHub repository for realtime-playground you'll notice a cws (Chrome Web Store) directory containing the stuff necessary to deploy the realtime-playground as Google Drive application in the Chrome Store including screenshots to be used. If you look at the manifest.json file you will see another reference to the client id:
"api_console_project_id" : "840867953062"
So if I share a realtime-playground file with somebody who doesn't have it installed, then clicking on the file in Google Drive will result in a "Connect app" popup which will try to locate the corresponding Chrome Web Store Drive app (using the common id as the key) and this will show something similar to what you might see if you found this application directly in the Chrome Web Store.
The manifest.json also contains:
"app" : { "launch" : {
"web_url" : "https://realtimeplayground.appspot.com/" } }
which tells Google Drive what to do when the installed app is called.
So my guess is that your application doesn't work like this as you don't yet have public visibility of your app in the Chrome Web Store.
See also: Create a Chrome Web Store Listing
I hope this helps.
That is fine. If you open your eyes, you will notice that Playground demo does not provide any preview either
Yet, you see, the associated app is available. You can click it and open-with works normally. Your app-created files operate similarly. They are associated with your app by default. You can open them by open with rather than by preview. Can you? No, you cannot. But that is another question.
Otherwise, I see no cleverness in associating your file with chrome extension rather than with your app.
How do I get it to prompt the person to authorize my app?
I recently had a similar question. Instead of linking your files with extension in chrome, pass the direct link, like http://your-app#fileId=..., as playground demonstrates to your shared fellow if open-with fails.
The preview seems to be another story.
Wait, Do you mean that I need to create a new fresh account to test how your file is unassociated with your app? How do you preview the files in your primary account? If you know how to preview you may answer my question, at least partially. But why do you associate authorization with preview?
Can a google drive application generate a preview for a file (which is not handled by google drive by default) when a file of that type is uploaded by the user, rather than creating it using that application?(Assuming the user has authorized that application)
Unfortunately, no, sorry.
The closest we have is being able to generate a third party thumbnail for a file. Your app can decide how the file will appear in the Google Drive thumbnail view by uploading the necessary image(s).
The video here explains it: http://www.youtube.com/watch?v=jG5-9zlaPL8
I've succeeded in using the filesystem API in a Chrome App on my Chromebook. But none of the examples I've found allow you to open files from Google Drive. Any number of apps on the Chromebook (supplied or added) open the exact same dialog but with Google Drive showing on the left along with Download and External Drive.
Is there a simple example App which shows how this is done?
Or am I simply missing some concept which will make even the Diff or TextEdit examples work this way if done (like pushing the App to the store, perhaps -- right now I'm just loading and packing my own off local storage)?
From reading your comment it seems that you will want to use google drive sdk in order to integrate the 'open file' dialog into your web app.
and even more to the point - the file 'picker' - In order to integrate the file picker you will need to use google JS client lib. Then you will be able to open the file dialog with a code like this:
// Use the Google Loader script to load the google.picker script.
google.setOnLoadCallback(createPicker);
google.load('picker', '1');
// Create and render a Picker object for searching images.
function createPicker() {
var picker = new google.picker.PickerBuilder().
addView(google.picker.ViewId.IMAGE_SEARCH).
setCallback(pickerCallback).
build();
picker.setVisible(true);
}
Good luck.
The answer to this is to use the <input type="file" name="somename" size="chars"> code in the browser. That is what is producing this. It creates a standard way to read in the file from disk or Google drive. It's what I've seen in multiple apps. All the API stuff is a red herring, if what one wants is to get access to this simple dialog.
However, it doesn't allow me to WRITE, just to read, since one would expect it to be returning only the content of the file, not a file handle of any sort, or even the full name. I'll play with it and figure out whether there's any hook I can find to tell me to write it to Google drive (using the links Ido provided above). If anyone has suggestions on where to snag the full path (or an interesting Google Drive path) somewhere using this, I'll love to hear them.