新的 Google Drive Android API (GDAA) 中报告的已删除文件状态不可靠

自从新的 Google Drive Android Api (GDAA) 推出以来，这个问题就一直困扰着我。 第一的在这里讨论 http://github.com/googledrive/android-demos/issues/3，我希望它会在以后的版本中消失，但它仍然存在（截至 2014/03/19）。用户删除的文件/文件夹（指“drive.google.com”中的“删除”操作）继续出现在

  Drive.DriveApi.query(_gac, query), and  
  DriveFolder.queryChildren(_gac, query)

也

  DriveFolder.listChildren(_gac)

方法，即使与

  Filters.eq(SearchableField.TRASHED, false)

查询限定符，或者如果我对结果使用过滤构造

for (Metadata md : result.getMetadataBuffer()) {
  if ((md == null) || (!md.isDataValid()) || md.isTrashed()) continue;
  dMDs.add(new DrvMD(md));
}

Using

  Drive.DriveApi.requestSync(_gac);

没有影响。自移除以来所经过的时间差别很大，我的最后一个案例已经超过 12 小时了。而且它是完全随机的。

更糟糕的是，我什至不能依赖“drive.google.com”中的 EMPTY TRASH，它不会产生任何可预测的结果。有时文件状态会更改为“isTrashed()”，有时会从结果列表中消失。

当我不断摆弄这个问题时，我最终得到了以下超级可怕的黑客：

find file with TRASH status equal FALSE 
if (file found and is not trashed) {
  try to write content
  if ( write content fails)
    create a new file
}

即使这样也没有帮助。即使文件位于垃圾箱中，该文件也显示为正常（并且其状态通过查询和元数据测试进行了双重过滤）。它甚至可以愉快地写入，当在垃圾箱中检查时，它会被修改。

这里的结论是修复应该获得更高的优先级，因为它会使 Drive 的多平台使用变得不可靠。它会在开发/调试过程中立即被开发人员发现，并引导他们离开。

在等待来自任何人的确认时支持团队 https://developers.google.com/drive/support，我设计了一个 HACK 来解决这个问题。使用与中相同的原理SO 22295903 https://stackoverflow.com/questions/22295903/how-to-delete-a-file-on-google-drive-using-google-drive-android-api，逻辑涉及回退到 RESTful API。基本上，放弃列表/查询GDAA 的功能。

高级逻辑是：

1. 查询 RESTful API 以检索相关文件的 ID
2. 使用检索到的 ID 通过“fetchDriveId()”获取 GDAA 的 DriveId

以下是记录该过程的代码片段：

1/初始化两个GDAA'GoogleApiClient'和 RESTful 的'服务.驱动器.驱动器'

GoogleApiClient _gac;
com.google.api.services.drive.Drive _drvSvc;

void init(Context ctx, String email){
  // build GDAA  GoogleApiClient
  _gac = new GoogleApiClient.Builder(ctx).addApi(com.google.android.gms.drive.Drive.API)
    .addScope(com.google.android.gms.drive.Drive.SCOPE_FILE).setAccountName(email)
    .addConnectionCallbacks(ctx).addOnConnectionFailedListener(ctx).build();
  // build RESTFul (DriveSDKv2) service to fall back to  
  GoogleAccountCredential crd = GoogleAccountCredential
  .usingOAuth2(ctx, Arrays.asList(com.google.api.services.drive.DriveScopes.DRIVE_FILE));
  crd.setSelectedAccountName(email);
  _drvSvc = new com.google.api.services.drive.Drive.Builder(
                       AndroidHttp.newCompatibleTransport(), new GsonFactory(), crd).build();
}

2/ 查询 Drive RESTful API 的方法，返回 GDAA 的 DriveId 以供应用程序使用。

String qry = "title = 'MYFILE' and mimeType = 'text/plain' and trashed = false";
DriveId findObject(String qry) throws Exception {
  DriveId dId = null;
  try {
    final FileList gLst = _drvSvc.files().list().setQ(query).setFields("items(id)").execute();
    if (gLst.getItems().size() == 1) {
      String sId = gLst.getItems().get(0).getId();
      dId = Drive.DriveApi.fetchDriveId(_gac, sId).await().getDriveId();
    } else if (gLst.getItems().size() > 1)
      throw new Exception("more then one folder/file found");
  } catch (Exception e) {}
  return dId;
}

上面的 findObject() 方法（为了简单起见，我再次使用“await()”风格）正确返回 Drive 对象，反映已废弃的状态，没有明显的延迟（在非 UI 线程中实现）。

再次，我强烈建议不要将其保留在代码中超过必要的时间，因为它是一种 HACK，会对系统的其余部分产生不可预测的影响。