在新的 Google Drive Android API (GDAA) 中报告的已删除文件状态不可靠 [英] Deleted files status unreliably reported in the new Google Drive Android API (GDAA)

问题描述

自从新的 Google Drive Android Api (GDAA) 推出以来，这个问题一直困扰着我.首先在这里讨论过，我希望它会在以后的版本中消失，但它是仍然存在(截至 2014 年 3 月 19 日).用户丢弃的(指drive.google.com"中的删除"操作)文件/文件夹继续出现在两个

This issue has been bugging me since the inception of the new Google Drive Android Api (GDAA). First discussed here, I hoped it would go away in later releases, but it is still there (as of 2014/03/19). The user-trashed (referring to the 'Remove' action in 'drive.google.com') files/folders keep appearing in both the

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

还有

  DriveFolder.listChildren(_gac)

方法，即使与

  Filters.eq(SearchableField.TRASHED, false)

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

query qualifier, or if I use a filtering construct on the results

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

使用

  Drive.DriveApi.requestSync(_gac);

没有影响.自从删除以来经过的时间变化很大，我的最后一个案例是超过 12 小时.它是完全随机的.

has no impact. And the time elapsed since the removal varies wildly, my last case was over 12 HOURS. And it is completely random.

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

What's worse, I can't even rely on EMPTY TRASH in 'drive.google.com', it does not yield any predictable results. Sometime the file status changes to 'isTrashed()' sometimes it disappears from the result list.

当我一直在处理这个问题时，我最终得到了以下 superawfulhack:

As I kept fiddling with this issue, I ended up with the following superawfulhack:

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
}

即使这样也无济于事.即使文件在垃圾箱中，文件也会显示为健康(并且它的状态已通过查询和元数据测试进行了双重过滤).它甚至可以愉快地写入并在垃圾箱中检查时进行修改.

Not even this helps. The file shows up as healthy even if the file is in the trash (and it's status was double-filtered by query and by metadata test). It can even be happily written into and when inspected in the trash, it is modified.

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

The conclusion here is that a fix should get higher priority, since it renders multi-platform use of Drive unreliable. It will be discovered by developers right away in the development / debugging process, steering them away.

推荐答案

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

While waiting for any acknowledgement from the support team, I devised a HACK that allows a workaround for this problem. Using the same principle as in SO 22295903, the logic involves falling back to RESTful API. Basically, dropping the LIST / QUERY functionality of GDAA.

高层逻辑是:

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

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

here are the code snippets to document the process:

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

1/ initialize both GDAA's 'GoogleApiClient' and RESTful's '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 以供应用使用.

2/ method that queries the Drive RESTful API, returning GDAA's DriveId to be used by the app.

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 线程中实现).

The findObject() method above (again I'm using the 'await()' flavor for simplicity) returns the the Drive objects correctly, reflecting the trashed status with no noticeable delay (implement in non-UI thread).

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

Again, I would strongly advice AGAINST leaving this in code longer than necassary since it is a HACK with unpredictable effect on the rest of the system.

这篇关于在新的 Google Drive Android API (GDAA) 中报告的已删除文件状态不可靠的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！