Ich bin in einer Sackgasse. Ich benutze Dagger 2 für die Dependency-Injektion, aber ich verliere den Status, wenn die App in den Hintergrund tritt. Hier ist das Szenario: Die App startet und erstellt die Abhängigkeiten. Alles funktioniert perfekt, solange die App im Vordergrund bleibt. Es gibt jedoch ein Szenario, in dem die App in den Hintergrund treten muss. Wenn es zurückkommt, sind die Werte, die in einer meiner injizierten Klassen gespeichert sind, verloren.
Für meine injizierten Klassen, die keine eigenen Abhängigkeiten haben, scheint sich alles korrekt zu erholen. Es gibt jedoch eine injizierte Klasse mit einer injizierten Abhängigkeit, die nicht wiederhergestellt wird. Hier ist, wie ich es aufstelle:
AppComponent.java
%Vor%AppModule.java
%Vor%Und wenn ich dann diese Abhängigkeiten injiziere, mache ich es so:
LoginActivity.java
%Vor%Also, meine grundlegende Frage ist, wie man den Zustand einer Dagger 2-injizierten Klasse erhält. Ich bin glücklich, mehr Code zu teilen, aber das ist die wesentliche Idee.
Danke für jede Hilfe.
BEARBEITEN Angenommen, dass das, was ich oben getan habe, in Ordnung ist, lassen Sie mich weitergehen, wie ich die Werte speichern und abrufen kann, die in diesen injizierten Objekten gespeichert sind. Dies zeigt, dass es irgendwo ein Problem gibt.
Wenn ich in den Hintergrund gehe und dann zurückkomme, kann ich sehen, dass ich eine neue PID bekomme. Ich kann auch sehen, dass ich die injizierten Werte korrekt speichern und abrufen kann in der LoginActivity-Klasse . Andere Klassen, die ebenfalls einen Verweis auf den injizierten Wert haben, haben jetzt andere Werte , was bedeutet, dass sie auf einen anderen Speicherort verweisen, nicht wahr?
Meine beste Vermutung, wo ich falsch liege, ist in LoginActivity onCreate, wo ich den sessionKeyExchangerService Wert aus dem gespeicherten Paket wiederherstelle. Ich denke, ich erstelle neue Werte, die in der App nicht als injizierte Abhängigkeiten erkannt werden, aber ich weiß nicht, warum das falsch ist oder wie ich es beheben kann.
Dieser Code ist auch in LoginActivity.java:
%Vor% Hier ist die Konsolenausgabe, die das Problem veranschaulicht. Hinweis 1) wie sich die PID ändert, nachdem onStop() aufgerufen wurde, und 2) wie die Klasse Authenticator (die einen Verweis auf AESCipherService hat, einen anderen Sitzungsschlüsselwert hat:
1398-1398 / com.mysite.myapp D / MYTAG: beim Speichern des Instanzstatus
1398-1398 / com.mysite.myapp D / MYTAG: Sitzungsschlüssel gespeichert: 93Zuy8B3eos + eCfBQk9ErA ==
1398-1398 / com.mysite.myapp D / MYTAG: ein stop
3562-3562 / com.mysite.myapp D / MYTAG: Sitzungsschlüssel in abgerufen auf erstellen: 93Zuy8B3eos + eCfBQk9ErA ==
3562-3562 / com.mysite.myapp D / MYTAG: am Anfang
3562-3562 / com.mysite.myapp D / MYTAG: Sitzungsschlüssel im Wiederherstellungsstatus abgerufen: 93Zuy8B3eos + eCfBQk9ErA ==
3562-3562 / com.mysite.myapp D / MYTAG: authenticator Klasse sagt, dass die Sitzungsschlüssel ist: 28HwdRCjBqH3uFweEAGCdg ==
SessionKeyExchangerService.java
%Vor%AESCipherService.java
%Vor%Das Eingeben von Werten bedeutet, dass Sie den Wert nicht selbst zuweisen. Das sagte,
%Vor%ist nicht das, was Sie tun möchten.
Wenn Ihr SessionKeyExchangerService von einem gespeicherten Zustand abhängt, müssen Sie es in Ihr Modul eingeben.
AppModule scheint der falsche Ort zu sein, um SessionKeyExchangerService bereitzustellen. Sie sollten wahrscheinlich auf einige SessionModule auslagern, die Sie dann tauschen können, wie ich denke, gut erklärt hier . In diesem Beispiel wird der UserModule-Lebenszyklus von der App und nicht von Dolch verwaltet.
Wenn Sie ein Modul mit einem Konstruktor bereitstellen, können Sie Ihren Parcelable -Zustand von savedInstanceState weitergeben.
Ohne Ihr gesamtes Projekt zu kennen, können Sie die Komplexität erheblich reduzieren und sollten wahrscheinlich keinen Status in der Aktivität speichern, sondern stattdessen SharedPreferences oder einfache Dateien verwenden. Dadurch entfällt auch die Notwendigkeit, den Modullebenszyklus mit Ihrem Aktivitätsstatus aufrechtzuerhalten.
Tags und Links android state dagger-2 activity-lifecycle