Integrating with Google Drive from a Chrome packaged app - google-drive-api

Is there a way to make a Chrome packaged app integrate with Google Drive? Specifically, I'm looking to make an app that will sync user's files to Google Drive, be packaged (not hosted), and not have to rely on a secondary add-on app.
However, when a user opens a file from the Google Drive interface, I can't make Google Drive redirect to my packaged app, can I?

No, this is not possible currently. You need a hosted app to receive the redirect from the Google Drive user interface.
If you don't need to handle a redirect from the Drive user interface, you can create a Google Documents List API application that manages a user's files in their Drive. This can e a non-hosted, packaged app.

Related

How to view files added through Google service account?

I need to create .NET console app to upload/download files to a user's Google drive.
I tried it using service account authorization. But I am not able to view the uploaded files using web UI. I am able view the list of files uploaded using my console APP. But I would like to know whether User Google Drive and files uploaded using my APP are located in different location.

How to tell if user of a Google Drive SDK app installed via Chrome Web Store vs. a user whose domain admin installed it

We have an app in both the Chrome web store and the in the Google apps marketplace that interacts with Google Drive. Under the covers, they are both the same app, even though they are installed from different places.
In the Drive integration settings, we provide a URL to open Drive docs with. This URL is the same for both drive and apps users.
Is there a way to determine which type of user is hitting that endpoint we provided? Whether they are working as a user from a Google Apps domain, or if they are a consumer who is working under their own account?

Google Drive mobile offline app

I'm developing a mobile app that will have hyperlinks to a user's Google Drive documents. If the mobile device is offline, will the hyperlinks still function if the mobile device owner has installed the Google Drive Android/iOS app? i.e. does document URL retrieved online work for offline access?
Google Drive Android/iOS app downloads online files to local storage and serve from the local file system when device got offline. You should follow a similar approach.

How to use the google drive api without allowing users to install chrome webstore apps?

I've made a drive application that does some actions with files inside a google apps domain. To use the drive api in an apps domain I had to put allow users to install webstore apps on. But I don't really want users to install chrome webstore apps.
Is there a possibility to allow users to use the drive api within our domain without allowing them to install Webstore apps?
This is the error I get when it's off :
403 The domain policy has disabled third-party Drive apps.
This is not an installation issue, this is a domain issue. Your domain administrator needs to enable third party Drive Apps in their CPanel.
Once you have done that, you can request the install scope to install an application, there is no requirement on Chrome Webstore integration.

Google Drive iOS native application URL schemes

I found that native iOS app for google drive which can be downloaded from AppStore supports URL scheme:
googledrive://
Is there any documentation to this scheme or something where can I find how to authorize my application using google drive native iOS application?
Is it even possible to authorize application this way?
Is there other way to authorize then via web browser?
If you would like to integrate Google Drive into your iOS application you should use Google API's Objective-C client library which has Google Drive support.
For authorization specifically the client library will use a Web view to initiate an OAuth 2 flow.
You can have a look at the sample application that uses Google Drive.
As for the iOS native Drive application there is currently no way to interact with it. Though if we do we are likely to add these features to the Objective-C client library anyways :)