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

Question

自从新的 Google Drive Android Api (GDAA) 推出以来，这个问题一直困扰着我。首先在这里讨论，我希望它会在以后的版本中消失，但它仍然存在（截至 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));
}

使用

  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 的多平台使用变得不可靠。它会在开发/调试过程中立即被开发人员发现，引导他们离开。

Answer 1

在等待支持团队的任何确认时，我设计了一个 HACK 来解决这个问题。使用与SO 22295903中相同的原理，逻辑涉及回退到 RESTful API。基本上，放弃了GDAA 的LIST / QUERY功能。

高级逻辑是：

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

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

1/初始化GDAA的“GoogleApiClient”和RESTful的“services.drive.Drive”

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，会对系统的其余部分产生不可预测的影响。