谷歌云端硬盘Android API：删除文件夹仍然存在查询 [英] Google Drive Android API: Deleted folder still exists in query

问题描述

运行低于code，我创建一个谷歌平板电脑云端硬盘Android API的文件夹。几秒钟后，从PC上远程位置删除该文件夹。当我重新运行code，该API仍然认为MyFolder的'存在，尽管它已被删除，并在平板电脑上的谷歌云端硬盘应用不可见。该文件夹持久性最终消失一段时间后和code按预期工作。是云驱动器这一预期的行为？

 查询查询=新Query.Builder（）
        .addFilter（Filters.and（Filters.eq（
                SearchableField.TITLEMyFolder中），
                Filters.eq（SearchableField.TRASHED，FALSE）））
        。建立（）;
Drive.DriveApi.query（getGoogleApiClient（），查询）
        .setResultCallback（新ResultCallback＆LT; D​​riveApi.MetadataBufferResult＆GT;（）{
    @覆盖
    公共无效onResult（DriveApi.MetadataBufferResult结果）{
        如果（！result.getStatus（）。isSuccess（））{
            showMessage（不能在根目录中创建文件夹。）;
        }其他{
            布尔isFound = FALSE;
            对于数据（Metadata玛：result.getMetadataBuffer（））{
                如果（！isFound）{
                    如果（m.getTitle（）。等于（MyFolder文件））{
                        showMessage（文件夹存在）;
                        isFound = TRUE;
                    }
                }
            }
            如果（！isFound）{
                showMessage（文件夹中没有发现;创造它。）;
                MetadataChangeSet变更=新MetadataChangeSet.Builder（）
                        .setTitle（MyFolder文件）
                        。建立（）;
                Drive.DriveApi.getRootFolder（getGoogleApiClient（））
                        .createFolder（getGoogleApiClient（），变更）
                        .setResultCallback（新ResultCallback＆LT; D​​riveFolder.DriveFolderResult＆GT;（）{
                    @覆盖
                    公共无效onResult（DriveFolder.DriveFolderResult结果）{
                        如果（！result.getStatus（）。isSuccess（））{
                            showMessage（错误尝试创建文件夹）;
                        }其他{
                            mThwingAlbertFolderId = result.getDriveFolder（）getDriveId（）。
                            showMessage（创建的文件夹：+ mThwingAlbertFolderId）;
                        }
                    }
                }）;
            }
        }
    }
}）;
 

解决方案

您所看到的，是的 GDAA ，可如果你看一下接近，说明一个驱动文件的生命周期图。（警告：我从来没有见过源$ C ​​$ C，从我观察到的只是假设）

看，GDAA，不像 REST 的API，创建会尽力创建图层缓存和网络通信优化。所以，当你操纵从外部（如Web应用程序），该GDAA层的文件/文件夹没有，直到它启动同步，由它自己的逻辑控制的事实知识。我自己原来假设GooDrive具有此控制下通过调度某种通知回GDAA，但它显然不是这样。此外，一些Google员工提到的<一个href=\"http://stackoverflow.com/search?q=%5Bgoogle-drive-android-api%5D%20requestSync\">'requestSync()'作为一个治愈，但我从来没有成功地使其工作。

你认为你正在做的，什么是轮询GooDrive。但实际上，你是轮询GDAA（本地GooPlaySvcs），其驱动器Id仍然有效（未更新），不像一个已经消失的真正GooDrive对象。

这是一件事，没有明确的文档说明。 GDAA并不是适用于所有应用程序最好阿比。它的缓存机制，是伟大的透明管理在线/离线状态，网络流量优化。电池寿命，......但在你的​​情况，你的可能的是通过使用REST API，因为你得到的回应反映了当前GooDrive状态更好。

我自己也面临着类似的情况，不得不从GDAA切换回REST（带私人GCM基于通知系统取代轮询）。不用说，通过使用REST API，应用程序越来越复杂，通常需要同步适配器/服务做数据同步，管理网络状态，......所有的东西GDAA为您提供免费的）。结果
如果你想用2 API来发挥并排有两个相同的CRUD实现，你可以使用（ GDAA ，< A HREF =htt​​ps://github.com/seanpjanson/RESTDemo在Github> REST ）。

好运

Running the code below, I create a folder with Google Drive Android API on a tablet. After a few seconds, delete that folder from a remote location on a PC. When I re-run the code, the API still thinks 'MyFolder' exists, even though it was deleted and not visible in the Google Drive app on the tablet. The folder persistance finally disappears after a while and the code works as expected. Is this expected behavior for Cloud drives?

Query query = new Query.Builder()
        .addFilter(Filters.and(Filters.eq(
                SearchableField.TITLE, "MyFolder"),
                Filters.eq(SearchableField.TRASHED, false)))
        .build();
Drive.DriveApi.query(getGoogleApiClient(), query)
        .setResultCallback(new ResultCallback<DriveApi.MetadataBufferResult>() {
    @Override
    public void onResult(DriveApi.MetadataBufferResult result) {
        if (!result.getStatus().isSuccess()) {
            showMessage("Cannot create folder in the root.");
        } else {
            boolean isFound = false;
            for(Metadata m : result.getMetadataBuffer()) {
                if(!isFound) {
                    if (m.getTitle().equals("MyFolder")) {
                        showMessage("Folder exists");
                        isFound = true;
                    }
                }
            }
            if(!isFound) {
                showMessage("Folder not found; creating it.");
                MetadataChangeSet changeSet = new MetadataChangeSet.Builder()
                        .setTitle("MyFolder")
                        .build();
                Drive.DriveApi.getRootFolder(getGoogleApiClient())
                        .createFolder(getGoogleApiClient(), changeSet)
                        .setResultCallback(new ResultCallback<DriveFolder.DriveFolderResult>() {
                    @Override
                    public void onResult(DriveFolder.DriveFolderResult result) {
                        if (!result.getStatus().isSuccess()) {
                            showMessage("Error while trying to create the folder");
                        } else {
                            mThwingAlbertFolderId = result.getDriveFolder().getDriveId();
                            showMessage("Created a folder: " + mThwingAlbertFolderId);
                        }
                    }
                });
            }
        }
    }
});

解决方案

What you are seeing, is a 'normal' behavior of the GDAA, that can be explained if you look closer at the 'Lifecycle of a Drive file' diagram (warning: I've never seen the source code, just assuming from what I observed).

See, the GDAA, unlike the REST Api, creates a layer that does its best to create caching and network traffic optimization. So, when you manipulate the file/folder from the 'outside' (like the web app), the GDAA layer has no knowledge of the fact until it initiates synchronization, controlled by it's own logic. I myself originally assumed that GooDrive has this under control by dispatching some kind of notification back to the GDAA, but it apparently is not the case. Also, some Googlers mentioned 'requestSync()' as a cure, but I never succeeded to make it work.

What you think you're doing, is polling the GooDrive. But effectively, you're polling the GDAA (local GooPlaySvcs) whose DriveId is still valid (not updated), unlike the real GooDrive object that is already gone.

This is one thing that is not clearly stated in the docs. GDAA is not the best Api for EVERY application. It's caching mechanism is great for transparently managing online/offline states, network traffic optimization. battery life, ... But in your situation, you may be better off by using the REST Api, since the response you get reflects the current GooDrive state.

I myself faced a similar situation and had to switch from the GDAA back to the REST (and replaced polling with a private GCM based notification system). Needless to say, by using the REST Api, your app gets more complex, usually requiring sync adapter / service to do the data synchronization, managing network states, ... all the stuff GDAA gives you for free).
In case you want to play with the 2 apis side-by side, there are two identical CRUD implementation you can use (GDAA, REST) on Github.

Good Luck

这篇关于谷歌云端硬盘Android API：删除文件夹仍然存在查询的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！