Wenn Sie eine Unteraktivität mehrmals eröffnen, wird eine InstanceCountViolation trotz der Zerstörung verursacht

Ich arbeite an einem Projekt, das eine niedrigere Ebene Aktivität namens RecordView , um Aufzeichnungsdetails wie ein Bild, das Datum und die Uhrzeit, die es genommen wurde, und die Breiten- / Längengradinformationen anzuzeigen. Anstatt zu versuchen, die Kamera zu geotag zu manipulieren und auf exif Daten zuzugreifen, versuche ich, einen Standortzuhörer zu implementieren, um den Ort zu erhalten, an dem das Bild zuerst aufgenommen wird (auf der Schaltfläche drücken). Dieser Ansatz funktioniert – ich bekomme meinen Standort, um den Datensatz in der Datenbank korrekt anzuzeigen und zu aktualisieren (die Rückkehr in die Ansicht zeigt später den Standort von Anfang an). Allerdings, wenn ich wieder aus dem aktuellen RecordView und dann geben Sie zwei weitere (jede Kombination) das Programm wird mit dem Fehler InstanceCountViolation (voller Fehler nachgedruckt unten) abstürzen. Wenn ich die lebenslangen Methoden von RecordView um anzuzeigen, wenn jeder angerufen wird, finden wir, dass es zerstört wird, bevor er wieder aufgerufen wird. Das heißt, es scheint nicht, dass mehr als ein einziges RecordView zu einem bestimmten Zeitpunkt existiert.

Also klappt meine Frage zu diesem: Woher kommt dieser Fehler und wie kann ich das beheben?

Ist etwas los, das zerstört wird? Ist der LocationListener irgendwo herum und verursacht Probleme? Ist es etwas Unvereinbares, das vielleicht einen falschen Fehler liefern könnte?

Auch sollte ich die schrecklich hart codiert fix und nur bis die Grenze der RecordView Instanzen erlaubt? Oder weiter jagen für einen anderen Ansatz (als Beispiel versuche ich, ein einziges Update mit einem PendingIntent.getBroadcast(...) Anruf anzufordern)?

Als Referenz ist dieser Fehler auf dem Emulator für 3.1 und auf einem tatsächlichen Tablet (ein Xoom, 3.1) erschienen. Der Zuhörer-Update-Code zu kommentieren scheint den Absturz zu vermeiden ( EDIT 2 : Ich scheine das falsch zu haben). Der Code, wie er sich auf den Zuhörer bezieht, ist unten (er findet sich in einer öffentlichen Methode updateLocation innerhalb der RecordView Klasse).

  // Listener for the update request LocationListener locListener = new LocationListener() { // Store the currentRecord so the listener can update it after return Record currentRecord = record; GeoDatabase database = data; @Override public void onLocationChanged(Location location) { if (location != null) { myLocation = location; Log.d(TAG, "Location pulled as " + myLocation); String lat = Location.convert(myLocation.getLatitude(), Location.FORMAT_SECONDS); String lon = Location.convert(myLocation.getLongitude(), Location.FORMAT_SECONDS); // Update the record values currentRecord.setRecordLatitude(lat); currentRecord.setRecordLongitude(lon); database.updateRecord(currentRecord); Log.d(TAG, "Record values now listed as "+ record.getValues()); // Update the text boxes latitude.setText(lat); longitude.setText(lon); Toast.makeText(getBaseContext(),"GPS location updated", Toast.LENGTH_LONG).show(); } else { Log.w(TAG, "Passed location is null!"); Toast.makeText(getBaseContext(), "GPS error - unusable location", Toast.LENGTH_LONG).show(); } } @Override public void onProviderDisabled(String provider) { Toast.makeText(getBaseContext(), "GPS disabled", Toast.LENGTH_SHORT).show(); } @Override public void onProviderEnabled(String provider) { Toast.makeText(getBaseContext(), "GPS enabled", Toast.LENGTH_SHORT).show(); } @Override public void onStatusChanged(String provider, int status, Bundle extras) { } }; lm.requestSingleUpdate(LocationManager.GPS_PROVIDER, locListener, null); 

Der volle Fehler:

 android.os.StrictMode$InstanceCountViolation:class [program path].RecordView; instances=3; limit=2 at android.os.StrictMode.setClassInstanceLimit(StrictMode.java:1) 

BEARBEITEN:

Zwei Dinge habe ich bestimmt

Die erste ist, dass, wenn Logcat zeigt die Zerstörung der RecordView Aktivität der LocationListener korrekt getrennt ist (zerstört? Es ist null sowieso). Allerdings scheint der Zuhörer, wie es war, von jenseits des Grabes zu aktualisieren – das heißt, ich sehe manchmal meine Toast-Nachricht über ein GPS-Update auf dem Bildschirm der höheren Ebene und die GPS-Informationen wurden aktualisiert.

Die zweite ist, dass es nicht genau stürzt pro sagen – es scheint zu sein Force Closing the RecordView anstatt die gesamte app. Das Hauptstück der App scheint einfach nur minimiert zu sein.

EDIT 2:

Wir haben vor kurzem einen Präferenzbildschirm mit einer neuen Aktivität hinzugefügt und das hat denselben InstanceCountViolation Fehler wie die RecordView . Wir haben bestätigt, dass in der Aktivität für den Fehler nichts geändert werden muss: es muss nur ein paar Mal geöffnet werden. Ein Beispiel dafür, wie wir unsere Teilaktivitäten von den Hauptaktivitäten eröffnen, ist unten:

 Intent intent = new Intent(this.getActivity() .getApplicationContext(), RecordView.class); Bundle extras = new Bundle(); extras.putString("tableName", "table1"); extras.putInt("id", mId); extras.putBoolean("newRecord", false); extras.putLong("folder_id", mFolderId); extras.putString("type", recordList.get(mId).getTableName()); intent.putExtras(extras); startActivity(intent); 

Also jetzt frage ich mich, ob es ein Problem in, wie die Absicht Handhabung Aktivität Erstellung und Löschung ist.

  • Finden, was die StrictMode-Richtlinie verletzt hat
  • Definition von DEVELOPER_MODE für StrictMode
  • Lebkuchen Emulator Instanz ist viel schleppender als Froyo und unten. Warum?
  • StrictMode für niedrigere Plattformversionen
  • Android StrictMode berichtet falsche Positives
  • Android StrictMode InstanceCountViolation
  • Eine Ressource wurde auf der angehängten Stack-Trace erworben, aber niemals veröffentlicht. Siehe java.io.Closeable für Informationen über die Vermeidung von Ressourcenlecks
  • StrictMode + Analytics
  • 2 Solutions collect form web for “Wenn Sie eine Unteraktivität mehrmals eröffnen, wird eine InstanceCountViolation trotz der Zerstörung verursacht”

    Es scheint, als wäre es nicht nötig, aber hast du versucht, anzurufen

    lm.removeUpdates(locListener);

    Den Hörer nicht registrieren?

    Ich weiß, dass das alte Pfosten ist. Nur für Jungs, die nach Lösung und Erklärung für dieses Problem suchen.

    Im Fall gibt es InstanceCountViolation Ausnahme bedeutet es, dass es real mit Aktivität Leck oder Problem, die im Zusammenhang mit, wie detectActivityLeaks Überprüfung ist in Android SDK implementiert ist.

    Um zu identifizieren, ob dies ein Problem ist, kann ich den folgenden Beitrag empfehlen: Erkennung von ausgelaufenen Aktivitäten in Android . Wenn Sie sehen, dass es Objekte gibt, die einen Verweis auf diese Aktivität enthalten, die nicht mit Android Framework verwandt ist, dann haben Sie ein Problem, das von Ihnen behoben werden sollte.

    Falls es keine Objekte gibt, die einen Verweis auf diese Aktivität enthalten, die nicht mit Android Framework verwandt ist, bedeutet dies, dass Sie mit dem Problem aufwiesen, wie es festgestellt wird, wie detectActivityLeaks check implementiert ist. In diesem Fall, um das Problem mit fehlgeschlagener Aktivität zu beheben, ohne dass Sie detectActivityLeaks ausschalten, können Sie einfach System.gc () ausführen, bevor Sie die Aktivität in der Debug-Konfiguration wie im folgenden Beispiel starten:

      if (BuildConfig.DEBUG) { System.gc(); } Intent intent = new Intent(context, SomeActivity.class); this.startActivity(intent); 

    Weitere Informationen finden Sie in dieser Antwort .

    Das Android ist ein Google Android Fan-Website, Alles ├╝ber Android Phones, Android Wear, Android Dev und Android Spiele Apps und so weiter.