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

renaming files in a directory using python or R -

c# - ajax - How to receive data both html and json from server? -