Das Problem ist, dass die 'resourceID' von ' DriveId.getResourceId () ' nicht verfügbar ist (gibt NULL zurück) für neu erstellte Dateien (Produkt von ' DriveFolder.createFile (GAC, meta, cont) '). Wenn die Datei durch eine normale Liste oder Abfrage abgerufen wird, ist die 'ResourceID' korrekt.
Ich vermute, dass dies ein Timing / Latenz-Problem ist, aber es ist nicht klar, ob es eine Anwendungsaktion gibt, die eine Aktualisierung erzwingt. Die Drive.DriveApi.requestSync (GAC) scheint keine Auswirkungen zu haben.
UPDATE (22.07.2015)
Dank der schnellen Antwort von Steven Bazyl (siehe Kommentare unten) habe ich endlich eine zufriedenstellende Lösung mit Abschluss-Events . Hier sind zwei minimierte Code-Snippets, die die ResourceId an die App senden, sobald die neu erstellte Datei an das Laufwerk weitergegeben wird:
Dateierstellung, Änderungsabonnement hinzufügen:
%Vor%Ereignisdienst, fängt den Abschluss ab:
%Vor%Unter normalen Umständen (wifi) bekomme ich fast sofort die ResourceId .
%Vor%... fertig für jetzt.
ORIGINAL POST, veraltet, hier als Referenz.
Ich lasse diese Antwort ein Jahr lang warten, in der Hoffnung, dass GDAA eine Lösung entwickelt, die funktioniert. Der Grund für mein Nörgeln ist einfach. Wenn meine App eine Datei erstellt, muss sie diese Tatsache an ihre Buddys (z. B. andere Geräte) mit einer ID senden, die aussagekräftig ist (also ResourceId). Es ist eine triviale Aufgabe unter REST Api, wo ResourceId zurückkommt, sobald die Datei erfolgreich erstellt wurde.
Ich muss sagen, dass ich die GDAA-Philosophie der Abschirmung der App von Netzwerk-Primitiven, Caching, Batching usw. verstehe. Aber klarerweise ist die ResourceID in dieser Situation verfügbar, lange bevor sie an die App geliefert wird.
Ursprünglich habe ich den Vorschlag von Cheryl Simon implementiert und einen ChangeListener in eine neu erstellte Datei eingefügt, in der Hoffnung, die ResourceID zu erhalten, wenn die Datei verbreitet wird. Verwenden Sie die klassische CreateEmptyFileActivity von android-demos habe ich den folgenden Testcode zusammengeschmuggelt:
%Vor%... und hat auf etwas gewartet. Die Datei wurde innerhalb von Sekunden ohne Probleme auf das Google Drive hochgeladen, aber kein Ereignis onChange () . 10 Minuten, 20 Minuten, ... Ich konnte keinen Weg finden, den ChangeListener aufzuwecken.
Die einzige andere Lösung, die ich vorschlagen konnte, bestand darin, das GDAA anzustoßen. Also implementierte ich einen einfachen Handler-Poker, der die Metadaten kitzelt, bis etwas passiert:
%Vor%Und voila, 4 Sekunden (geben oder nehmen) später liefert der ChangeListener eine neue glänzende ResourceId. Natürlich wird der ChangeListener damit überflüssig, da die Poker-Routine auch die ResourceId bekommt.
Das ist also die Antwort für diejenigen, die nicht auf die ResourceId warten können. Was die folgende Frage aufwirft:
Warum muss ich Metadaten kitzeln (oder Inhalte neu binden), sehr wahrscheinlich unnötigen Netzwerkverkehr erzeugen, um onChange () -Ereignis zu erhalten, wenn ich klar sehe, dass die Datei propagiert wurde a vor langer Zeit, und GDAA hat die ResourceId verfügbar?
ResourceIds werden verfügbar, wenn die neu erstellte Ressource für den Server festgeschrieben wird. Bei einem Gerät, das offline ist, könnte dies beliebig lange nach der anfänglichen Dateierstellung sein. Es wird so schnell wie möglich nach der Erstellungsanforderung geschehen, Sie müssen also nichts tun, um die Geschwindigkeit zu erhöhen.
Wenn Sie es wirklich sofort benötigen, können Sie die Änderungsbenachrichtigungen möglicherweise verwenden, um nach der Ressource-ID zu suchen ändern.
Tags und Links google-drive-android-api