Drive API for Android is broken, right? -


as @ august 2015, 'drive api android' not functioning (loosely)documented, broken. main sore points follows:

1) app sharing same app_id , logged in same google user meant able to find , access same files as google indicate (e.g. appx on device1 creates folder named 'blahblah' (where no 'blahblah' folder exists in user's drive), appx on device2 should able find folder , upload/download files also...however not case (or if work, intermittent , not working @ all)). remains case after (many) requestsync calls , on 72hours of allowing drive sync itself.

2) trashed folder not observed trashed, after requestsync call has succeeded. such trashed folder still have istrashed==false.

3) permanently trashed folder (i.e. gone drive, never coming back). can still found , "successfully" have folders , files created within it, writing such file's contents yield failure in completion event service. again, such folder still have istrashed==false (which abysmal).

bug reports have been lodged (thanks @dalmto link) via: https://code.google.com/a/google.com/p/apps-api-issues/issues/entry?labels=type-defect,api-drive

https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=4003 https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=4004

so, question: know way around these issues?

update:

i've narrowed these problems down personal google account (or personal drive, has many, many files in it). suggests these issues symptoms of or closely related https://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3905

i can give points regarding issue 1/ (syncing on multiple devices running same app). i've been pointing out in april 2014 without satisfactory answer (actually resounding silence). switched rest api , handled myself (using syncadapter, service, ...). rest's algorithm is:

  1. create/update/delete/ .... (execute() method)
  2. dispatch resource id ('id'+message) using gcm other devices
  3. let other devices deal change through rest api (again, in service)

i've re-visited gdaa few times since , never got satisfactory results (requestsync). finally, got half-way happy when started use 'completion events' (a year later, needless say).

again algo is:

  1. create ....
  2. get resourceid completion
  3. dispatch 'resourceid'+message using gcm other devices
  4. let other devices deal change through gdaa (using resourceid)

... , point is:
during time trying make work, realized gdaa is not suited applications (like 1 we're discussing here). gdaa goes through kinds of hoops , loops make online/offline state transparent , @ same time cache data , optimize network traffic, battery use, ... creates latency, unpredictable states...

... so, in end stopped blaming gdaa not being swiss-knife , ever dreamed up. developer understand advantages / drawbacks of toolbox he/she using , decide upfront tool use. know, docs not spell out , believe me, myself got caught in magnus's excitement. still remember pinoyyid's warning in january 2014, telling me not jump in early.

good luck


Comments

Popular posts from this blog

c# - Binding a comma separated list to a List<int> in asp.net web api -

Delphi 7 and decode UTF-8 base64 -

html - Is there any way to exclude a single element from the style? (Bootstrap) -