Android google drive api example

Android-google-drive-api-example-featured.png

Last week’s launch of Google Drive, a cloud-based platform offering 5GB of free storage, might have been large news, but possibly bigger was the synchronised launch of the connected Drive API and many Drive-enabled applications within the Chrome Online Store. The move suggests that Drive isn’t just another Google product, but one step toward developing a bigger ecosystem of online applications backed by Google services.
Gossips about &ldquoGDrive&rdquo happen to be circulating during the last six years, but after rivals like Dropbox, Box.internet, and Microsoft’s SkyDrive had already developed cloud storage, Google Drive’s large reveal might have appeared just a little anticlimactic. Possibly anticipating this, Google joined with several &ldquolaunch partners&rdquo (including Tigard-based collaboration startup Revisu) to showcase applications which demonstrate the utility from the Drive API.

The issue, for the time being, is the fact that only web applications may use the Google Drive API, and individuals applications should be installed in the Chrome Online Store. (Google has a Drive Android application, and states they are &ldquoworking hard&rdquo with an iOS application.) The Drive API documentation notes that &ldquo[a]uthorization alone isn’t sufficient to provide your application use of users’ files &mdash application installation can also be needed. Applications won’t have any API use of files unless of course customers have first installed the application in Chrome Online Store.&rdquo However, this does not limit customers towards the Chrome browser it’s simply a way to authenticate customers and authorize access.

Another caveat for designers is the fact that Drive applications is only going to have the ability to access files that have been produced or opened up with that application. The second may appear just like a catch-22-how can you open a brand new file, if you’re able to only open files you’ve already opened up?-however it means the Drive API continues to be pretty bare-bones, and is dependent on specific file IDs for access. To obtain a listing of the user’s existing Drive files, you will need to feel the primary Drive UI, the Google Picker API, or even the Google Documents List API. The chances are the Drive API will expand to provide more functionality later on.

UPDATE (May fourth, 2012): Google Developer Advocate Steven Bazyl offers clarification around the above problem:

The brand new Drive API deliberately includes a more limited security model to safeguard users’ data. Instead of grant use of all documents once the user authorizes with OAuth, we added one more layer of security which necessitates the user to clearly choose which files to talk about. This is accomplished by opening files using the application with the Drive UI (either drive.google.com or even the embedded picker widget.) Approved applications may also create new files on their own. Within this situation, the general OAuth permission is enough. Any files the application produces can, obviously, be re-opened up with that application directly, presuming the consumer has not suspended the app’s permission/uninstalled it. There’s additionally a lower-level API, the older Documents List API, which creates files in Drive. We are encouraging applications to maneuver up to the more limited model whenever you can, but larger access can be obtained for individuals applications that really require it. We may then add middle-ground options (e.g. folder-level access) afterwards once we get feedback around the new API & security model from designers.

On the Google Drive API on ProgrammableWeb. Official documentation will come in the Google Drive SDK.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>