Programmatically access Google Chrome bookmarks - google-chrome

How can I programmatically get (and manipulate) my bookmarks that are synced between different instances of Google Chrome using my Google account?

It looks like a JSON object stored in "C:\Users\\AppData\Local\Google\Chrome\User Data\Default" folder. File name is Bookmarks
You can parse it using any JavaScript, Java (or any other language) Lib.
Hope that helps!
A related thread: Manipulating Google Chrome bookmarks from external program (and make Chrome aware)?

Related

What is the internal file format of a .glink file?

I would like to add URL links into a web-based Google Drive folder. Searching online, it appears that this was once possible with files that ended in a .glink extension. I'm looking for documentation on the file format so that I can create them programmatically.
[EDIT] Why do I want to create .glink files? Because I want links (bookmarks, URLs) to be able to appear in my Google Drive web page and to be able to click on them an go to the page. Microsoft OneDrive supports this functionality.
GLINKS Files
The URL link file feature was available due to a workaround with Back Up and Sync before being deprecated with Drive for Desktop. The .glink seems to be patched and no longer available as it was also part of a third party tool no longer available. It seems it now only saves them as .URL and automatically gives it the icon for Google Docs, as it would take it as a simple file with text.
Checking the .url type file of Windows, when uploading to Drive it does not update as it should, even utilizing Drive for Desktop (as an alternative to sync data like back up and sync) the outcome is the one suggested above.
This is the main reason why there is no longer any documentation about the matter, due to this one not being an official feature and being also fully deleted, it can be confirm by the file type available when creating files with the Drive API:
https://developers.google.com/drive/api/guides/ref-export-formats
I would suggest to request a feature to allow this or to provide a new way to store URL links as before or report it to review if possible any references on how it used to work by submitting a feature request or checking the issue tracker about the matter:
https://issuetracker.google.com/issues/new?component=191650&template=824106
You can also add the details of the previous threads or discussions about the GLINKS.

Bookmark Import Extension for Google Chrome

I want to develop a chrome extension that imports new bookmarks.
It's for ~100 users. When the extension is installed they should be able to update (import) the latest bookmarks from a .html file.
The .html file is created from Google Chrome directly and stored at a Google Shared Drive for the users.
Do you think this process could be done with an extension? I saw that there is an API to modify bookmarks but I'm not sure if this is something what an extension could do :)
https://developer.chrome.com/docs/extensions/reference/bookmarks/
Many thanks and have a nice day!

When/why can file.downloadUrl be empty for a PDF file selected from Google Drive?

Using js file picker to select PDF files from Google Drive.
I'm encountering an instance when the downloadUrl is undefined.
I don't understand what can cause this.
I know downloadUrl can be empty for native Google formats, but these are PDF files.
I'd like to know what scenarios (except native Google formats) can cause an empty downloadUrl.
Thanks
You should use the Drive API to fetch the picked files' metadata in order to retrieve the downloadUrl. https://developers.google.com/drive/v2/reference/files/get
Native Google formats can be downloaded (converted and downloaded) via their exportLinks: https://developers.google.com/drive/v2/reference/files#exportLinks
The response I was receiving was 403.
And the scenario was user accessing "work" Drive (Google Drive for your domain)
Turns out Google Drive for your domain Administrators can restrict the permission to install third party apps.
https://support.google.com/a/answer/6105699?hl=en
User will still be able to allow access for the app and select files. Its just going to fail every time with a 403. Very confusing UX.

Sharing Google Drive Realtime Documents

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?

ChromeOS App: Simple example app which opens/saves to Google Drive as well as Download and External Drive

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.