I need to delete files from Google Drive using com.google.android.gms.drive. From what I've read here and across the web there is no support for file deletion in the "new API". Is that (still) correct? I mean the API isn't that new anymore ...
I also read about the "clear contents and forget"-strategy, but I'd like not to follow that approach.
Part 2 of the question: Given it's still impossible to delete files via the API mentioned above; is there any easy way to combine the REST API w/ the code I've already written? Something like
get token from GoogleApiClient
fire DELETE request w/ token and file id
???
profit
edit: The new Google Play Services (version 7.0.0 / March 2015) finally features a trash() method. See https://developer.android.com/reference/com/google/android/gms/drive/DriveResource.html for further details.
.
edit2: Apparently you cannot use trash() on files from the app folder: Cannot trash App Folder or files inside the App Folder. :((
edit3: As of May 28th, it's now possible to actually delete files.
UPDATE (May 2015)
Addition of trash / delete functionality to GDAA 7.5 renders the answer below irrelevant.
ORIGINAL ANSWER:
The sequence is:
Get DriveId from GDAA (file or folder)
Get ResourceId from DriveId.getResourceId() (may be null if file/folder is not committed yet)
use ResourceId (rsid) in this REST call:
com.google.api.services.drive.Drive.files().trash(rsid).execute()
com.google.api.services.drive.Drive.files().delete(rsid).execute()
finally realize that you can't do it since you'll see the file in GDAA long after it has been deleted / trashed. You can even write in it, create files in that folder you've just trashed, ... That's why people introduced the "clear contents and forget" strategy nobody likes.
Needless to say, this applies to any delete / trash action you may perform outside of GDAA universe (manually trash/delete using web interface etc...)
So, to wrap it up. 'pinoyyid' is right, each of the APIs is different and the GDAA can not replace the REST (yet). You'll quickly realize it when you try to work a little deeper, like getting thumbnail url, fighting latency issues etc... On the other hand GDAA has advantages, since it can work off-line without your app handling it. When using REST, your app should do all the Drive calls in some kind of sync service to separate your UI actions from network issues (delays, off-line, ...). GDAA handles this for you, but on it's own timing terms. And with no delete functionality.
I put a piece of code on github, that has both these API's used side-by-side and you may use it to play with different scenarios before committing yourself to one of them.
It would be nice to hear clearly from Google what the final strategy is, i.e.
Is GDAA going to replace REST one day, after all the REST functionality is in?
Will they retire the REST afterwards?
Good Luck
Delete is supported by the Google Drive Android API as of Google Play services 7.5 using the DriveResource.delete() method.
Delete is permanent, and recommended only for App Folder content, where trash is not available.
Related
I've been working on a project that use filenet for multiple parts of the project.
I've been asked to remove a boatload of file's that need to be removed. The reason why I was asked is because the assumtion was made we could remove the data through a java application.
And so far so good honestly. I've been able to use code left by former project members to create a delete application. However, i've come to a single problem in this issue: the retention date.
When I delete a file it will display the error message: Content Engine cannot delete or move content because the retention period for the item has not yet expired. Current time: 9/16/21 8:43 AM; Storage period: 20-12-99 1:00.
I've created code that does change this. However the above error is still appearing. I;ve doubled checked the retentiondate property in the specifice file, and this has been changed.
I've looked through all the properties of the file and have not spotted anything that includes this date.
So my questions is, what am I missing? Is this something from filenet?
The retention period is probably additionally set on the storage device and the storage device is not aligned with filenet.
What type of storage backend are you using.
Please check this doc https://www.ibm.com/docs/en/filenet-p8-platform/5.2.1?topic=objects-retention-limitations-constraints
And this https://www.ibm.com/docs/en/filenet-p8-platform/5.2.1?topic=objects-security-permissions-required-setting-modifying-retention
Sure that you have enough permissions for the principal that you are using for API calls.
And check this page https://www.ibm.com/docs/en/filenet-p8-platform/5.2.1?topic=sweeps-deleting-objects-sweep and this https://www.ibm.com/docs/en/filenet-p8-platform/5.2.1?topic=sweeps-updating-object-retention as alternative way to delete objects without API and custom app.
Here the problem: my app will generate some files, and I want to give to the users the opportunity to exchange these files between them.
This requires 3 steps:
Saving the data: easily done in Storage implementing the
functions required by the Externalizable class;
Sharing the data: done (probably, right now it's impossible to check if the
result is correct because the missing step 3) with the sharing
methods offered by the framework, as soon as I understood I needed
to use as mimetype "application/octect-stream";
importing the downloaded data (shared by another user): this one I can't manage to
find a way to make it work. Loading the files from the app's Storage
is easy, but accessing to the folders out of the app's Storage is
something I can't manage to do.
I used FileSystemStorage in the hope of gaining access at least to the Download folder that (mostly) every phone has, but apparently I can't manage to accomplish the task
Using the FileSystemStorage on Android, for example, I have access to
/storage/emulated/0
/storage/emulated/legacy
file:///system
The first two being related to the Storage of the app.
Acceding to file:/// I obtain a long list of folders, a partial list including
media
logs
sdcard
Removable
...
root
...
But when I try to access some of these, they all appear to be empty. Either I make some mistake or the app can't see their content.
So I wonder if there is a way to accomplish the task, namely to have access to the files (probably in the Download folder) the user has downloaded, to import them.
Phone apps live in isolation within the phone. Android literally creates a separate Linux user for every app so they don't step on each other and damage the phone. iOS does similar tricks.
As a result apps can't just write a file to downloads and can't just list all the files there. This would violate the users privacy. So the native API to share a file is usually separate from the files API. We do have a share API in the CN class which lets you share images etc. to an arbitrary OS app. See isNativeShareSupported and share.
Ok, maybe I found a solution for reading the files from the Download folder in an extension of CodenameOne called FileChooser.
According to this blog post it should give access to, between the others, the Download folder (at least in Android).
I'm going to try it and, when everything is ready and tested, edit this reply to say how it worked out for me.
I want to write a client application for a site (e.g. to read smth from site, add some comments, likes etc). I haven't got access to site sources and there isn't any API for work with it. So at my Android application I decided to parse this site (it has static pages) using : JSOUP Library
And using this library I'm going to write unofficial, but API for my purposes to work with this site, and then use it in my Android application.
Can somebody tell me, is this good practice or there are better ways to do? Is this good idea at all to parse site in Android device.
As I wrote in comment - in general building your own application on top of the third party www service is not a good idea. If you want to do it anyway you have 2 options:
Use jSoup (or any other html parser if exists) and parse third party content on the device
Set up some middleware server to parse content and serve it in some more convenient way.
The second option has a little advantages - you can fix application without forcing users to update it and probably you'll save a bit of device's bandwidth. Of course disadvantage is that you have to pay for server.
General problem with applications like that is that every single change with layout, skin, server configuration can cause your application to stop working, as well as parsing html needs much more work that just connect to existing API.
More over - publishing your application can cause some legal issues (copyright) and is against Google Play's policy:
Do not post an app where the primary functionality is to: Drive
affiliate traffic to a website or Provide a webview of a website not
owned or administered by you (unless you have permission from the
website owner/administrator to do so)
I have read allot about Google drive integration and I want to save STRING into Google drive and also to retrieve, I have used this demo but it is giving me errors.
please anyone provide me demo for my requirement
First, let's clear the confusion here. Your original question refers to a demo that uses the original RESTful API (aka DriveSDKv2), where Simple Plan mentions a different API, the new Google Drive Android API (GDAA).
The GDAA, does not have the full functionality at the moment, but it can be combined with the DriveSDKv2 to supplement what's missing (delete, description, indexable, ...). On the other hand, the GDAA takes care of all synchronization, offline and caching issues. You just create, retrieve, update the files as if they were local and the magic of up/down synchronization is left to GDAA. And the missing functionality is promised soon.
If you decide to dive into GDAA, there are 3 demos available on Github at the moment:
quick start
full-blown demo
trivial example with wrapper class to create, retrieve files/folders
Both demo and trivial examples have the create functionality with a text written to a file. If you pull any of them and step through, you'll get the idea.
I'm working on a web application. There is one place where the user can upload files with the HTTP protocol. There is a choice between the classic HTML file upload control and a Java applet to upload the files.
The classic HTML file upload isn't great because you can only select one file at a time, and it's quite hard to get any progress indication during the actual upload (I finally got it using a timer refreshing a progress indicator with data fetched from the server via an AJAX call). The advantage: it's always working.
With the Java applet I can do more things: select multiple files at once (even a folder), compress the files, get a real progress bar, drag'n'drop files on the applet, etc...
BUT there are a few drawbacks:
it's a nightmare to get it to work properly on Mac Safari and Mac Firefox (Thanks Liveconnect)
the UI isn't exactly the native UI and some people notice that
the applet isn't as responsive as it should (could be my fault, but everything looks ok to me)
there are bugs in the Java UrlConnection class with HTTPS, so I use the Apache common HTTP client to do the actual HTTP upload. It's quite big a package and slows down the download of the .jar file
the Apache common HTTP client has sometimes trouble going through proxies
the Java runtime is quite big
I've been maintaining this Java applet for a while but now I'm fed up with all the drawbacks, and considering writing/buying a completely new component to upload theses files.
Question
If you had the following requirements:
upload multiple files easily from a browser, through HTTP or HTTPS
compress the files to reduce the upload time
upload should work on any platform, with native UI
must be able to upload huge files, up to 2gb at least
you have carte blanche on the technology
What technology/compontent would you use?
Edit :
Drag'n'Drop of files on the component would be a great plus.
It looks like there are a lot of issues related to bugs with the Flash Player (swfupload known issues). Proper Mac support and upload through proxies with authentication are options I can not do without. This would probably rule out all Flash-based options :-( .
I rule out all HTML/Javascript-only options because you can't select more than one file at a time with the classic HTML control. It's a pain to click n-times the "browse" button when you want to select multiple files in a folder.
I implemented something very recently in Silverlight.
Basically uses HttpWebRequest to send a chunk of data to a GenericHandler.
On the first post, 4KB of data is sent. On the 2nd chunk, I send another 4K chunk.
When the 2nd chunk is received, I calculate the round trip it took between first and 2nd chunk and so now
the 3rd chunk when sent will know to increase speed.
Using this method I can upload files of ANY size and I can resume.
Each post I send along this info:
[PARAMETERS]
[FILEDATA]
Here, parameters contain the following:
[Chunk #]
[Filename]
[Session ID]
After each chunk is received, I send a response back to my Silverlight saying how fast it took so that it can now send a larger
chunk.
Hard to put my explaination without code but that's basically how I did it.
At some point I will put together a quick writeup on how I did this.
I've never used it with files of 2GB in size, but the YUI File Uploader worked pretty well on a previous project. You may also be interested in this jQuery Plugin.
That said, I still think the Java Applet is the way to go. I think you'll end up with less portability and UI issues than you expect and Drag/Drop works great. For the record, Box.net uses a Java Applet for their multi-file quick uploads.
OK this is my take on this
I did some testing with swfupload, and I have my previous experience with Java, and my conclusion is that whatever technology is used there is no perfect solution to do uploads on the browser : you'll always end up with bugs when uploading huge files, going through proxies, with ssl, etc...
BUT :
a flash uploader (a la swfupload) is really lightweight, doesn't need authorization from the user and has a native interface which is REALLY cool, me thinks
a java uploader needs authorization but you can do whatever you want with the files selected by the user (aka compression if needed), and drag and drop works well. Be prepared for some epic bugs debuggin' though.
I didn't get a change to play with Silverlight as long as I'd like maybe that's the real answer, though the technology is still quite young so ... I'll edit this post if I get a chance to fiddle a bit with Silverlight
Thanks for all the answers !!
There are a number of free flash components that exist with nice multiple file upload capability. They make use of ActionScripts FileReference class with a PHP (or whatever) receiver on the server side. Some have recently broken with the launch of FP10 but I know for certain that swfupload will work :)
Hope this helps!
What about these two
Jupload
http://jupload.sourceforge.net/
and
jumploader
http://jumploader.com/
Both are java applets but they are also both really easy to use and implement.
what about google gears?
There are HTTP/HTTPS upload controls that allow multi-file upload. Here is one from Telerik, which I have found to be solid and reliable. The latest version looks to have most if not all of your feature requirements.
You can upload multiple files with HTTP forms as well, as Dave already pointed out, but if you're set on using something beyond what HTTP and Javascript offers I would heavily consider Flash. There are even some pre-existing solutions for it such as MultiPowUpload and it offers many of the features you're looking for. It's also easier to obtain progress information using a Flash client than with AJAX calls from Javascript since you have a little more flexibility.
You may check the Apache Commons FileUpload package. It allows you to upload multiple files, monitor the progress of the upload, and more. You can find more information here:
http://commons.apache.org/fileupload/
http://commons.apache.org/fileupload/using.html
Good luck