missspelled
App-Anbieter (In-App)
- 127
Hallo, in einem anderen Thread ging es um o.g. Fragestelltung, besser gesagt "wann das Keyword static Probleme hinsichtlich Memoryleaks macht/machen kann". Daher habe ich hier mal einen neuen Thread dazu aufgemacht, um diese Fragestellung konkreter zu thematisieren.
Das habe ich auch schon öfter gehört. Allerdings auch selbst noch keine negativen Erfahrungen gemacht - wohlgemerkt in Helferklassen.
An was liegt das - spielt es eine Rolle das die Helferklasse "final" ist? Vermutlich nicht...
Ich denke eher, dass die Erreichbarkeit, gar nicht mal so das Problem darstellt.. Sondern, schlicht und ergreifend, die Tatsache, dass ein "fester" Context in einer solchen Helferklasse nichts zu suchen hat und erst durch diesen Leaks entstehen. Wird der (aktuelle) Context der Methode beim Aufruf übergeben, sollten Leaks kein Problem darstellen. So meine Vermutung..
Eine Helferklasse benutze ich, um die Wartbarkeit und Lesbarkeit des Codes zu verbessern, bzw. die Codemenge zu reduzieren. Hier ein Beispiel für eine solchen Helfer:
PS: in dem anderen Thread habe ich es schon gesagt, wiederhole es hier aber nochmal: Ich selbst kann dazu keine konkreten Erfahrungswerte abgeben, da ich auf den "static"-Bezeichner, mit obiger Ausnahme, verzichte.
markus.tullius schrieb:
Das habe ich auch schon öfter gehört. Allerdings auch selbst noch keine negativen Erfahrungen gemacht - wohlgemerkt in Helferklassen.
An was liegt das - spielt es eine Rolle das die Helferklasse "final" ist? Vermutlich nicht...
Ich denke eher, dass die Erreichbarkeit, gar nicht mal so das Problem darstellt.. Sondern, schlicht und ergreifend, die Tatsache, dass ein "fester" Context in einer solchen Helferklasse nichts zu suchen hat und erst durch diesen Leaks entstehen. Wird der (aktuelle) Context der Methode beim Aufruf übergeben, sollten Leaks kein Problem darstellen. So meine Vermutung..
Eine Helferklasse benutze ich, um die Wartbarkeit und Lesbarkeit des Codes zu verbessern, bzw. die Codemenge zu reduzieren. Hier ein Beispiel für eine solchen Helfer:
Code:
public final class Logic {
public static void toastShort(Context context, String message) {
Toast.makeText(context, message, Toast.LENGTH_SHORT).show();
}
public static void toastLong(Context context, String message) {
Toast.makeText(context, message, Toast.LENGTH_LONG).show();
}
public static void toastLong(Context context, String message) {
Toast.makeText(context, message, Toast.LENGTH_LONG).show();
}
public static boolean isDarkTheme(Context c) {
final SharedPreferences sp = c.getSharedPreferences(MP.CONFIG_FILE_NAME, Context.MODE_PRIVATE);
return !sp.getString(MP.PK_LIST_THEME, MP.DEFAULT_THEME).equals(MP.LIGHT);
}PS: in dem anderen Thread habe ich es schon gesagt, wiederhole es hier aber nochmal: Ich selbst kann dazu keine konkreten Erfahrungswerte abgeben, da ich auf den "static"-Bezeichner, mit obiger Ausnahme, verzichte.
In einer Activity ist das vielleicht nicht so sinnig, aber in einem Application-Objekt kann das durchaus sinnvoll sein.
