Une classe DialogFragment interne doit-elle être statique ou non?

Question

Ceci est un extrait de code de mon projet que je me sers pour apprendre Android:

private void enableLocationSettings() { 
    Intent settingsIntent = new Intent(Settings.ACTION_LOCATION_SOURCE_SETTINGS); 
    startActivity(settingsIntent); 
} 

@SuppressLint("ValidFragment") 
public class EnableGpsDialogFragment extends DialogFragment { 

    @Override 
    public Dialog onCreateDialog(Bundle savedInstanceState) { 
     return new AlertDialog.Builder(getActivity()) 
      .setTitle("Tytuł") 
      .setMessage("wiadomosc") 
      .setPositiveButton("odpal", new DialogInterface.OnClickListener() { 

       @Override 
       public void onClick(DialogInterface dialog, int which) { 
        enableLocationSettings(); 
       } 

      }) 
      .create(); 
    } 
} 

Comme vous pouvez le voir, je dois ajouter @SuppressLint pour faire mon travail d'application, mais sur la guide cette annotation était pas nécessaire.

Qu'est-ce que je fais mal?

Voici mes importations:

import android.annotation.SuppressLint; 
import android.app.Activity; 
import android.app.AlertDialog; 
import android.app.Dialog; 
import android.content.Context; 
import android.content.DialogInterface; 
import android.content.Intent; 
import android.location.LocationManager; 
import android.os.Bundle; 
import android.os.Handler; 
import android.os.Message; 
import android.provider.Settings; 
import android.support.v4.app.FragmentActivity; 
import android.support.v4.app.FragmentManager; 
import android.support.v4.app.DialogFragment; 
import android.view.Menu; 
import android.view.View; 
import android.widget.TextView; 
import android.widget.ToggleButton; 

Answer 1

L'exemple n'a pas de ces annotations parce que la classe est dans son propre fichier. Cela signifie que c'est indépendant de l'activité qui utilise le fragment.

Dans votre cas, votre fragment se trouve dans une activité et n'utilise pas le modificateur statique. Cela signifie qu'il est lié à l'instance d'activité. Le fait que le fragment dépende de l'instance d'activité est une mauvaise idée, ces deux classes ont des styles de vie complexes (d'autant plus que les activités sont détruites et recréées assez souvent) et doivent être indépendantes les unes des autres.

Vous devez créer le modificateur EnableGpsDialogFragmentstatic.

public static class EnableGpsDialogFragment extends DialogFragment { 

Une classe static ne dépend pas de la instance de classe englobante, donc l'avertissement disparaîtra.

Pour plus d'informations, lisez le tutoriel Java au nested classes.

Modifier en réponse à votre édition: Maintenant que les classes ne dépendent pas de l'autre instance de, vous devrez sortir une instance de YourActivity afin que vous puissiez appeler enabledLocationSettings() une façon est par coulée et ne fonctionnera que si EnableGpsDialogFragment est utilisé uniquement par YourActivity:

@Override 
public void onClick(DialogInterface dialog, int which) { 
    enableLocationSettings(); 
} 

à

@Override 
public void onClick(DialogInterface dialog, int which) { 
    ((YourActivity)getActivity()).enableLocationSettings(); 
} 

Si ce fragment sera utilisé par plusieurs activités, vous devriez create an interface to be implemented by each Activity instead .

Answer 2

Il ne devrait pas être! De mon point de vue, je ne veux pas que mon DialogFragment (votre NetworkConnectionError) soit statique parce que je veux pouvoir appeler des variables ou des méthodes de ma classe (Activity) qui le contient.
Donc, ce ne sera pas statique. Mais je ne veux pas générer memoryLeaks non plus.
Alors, quelle est la solution?
Simple, quand vous allez dans onStop, assurez-vous de tuer votre DialogFragment, c'est aussi simple que cela. Ainsi, le code ressemble à quelque chose comme ça:

public class CarActivity extends AppCompatActivity{ 

/** 
* The DialogFragment networkConnectionErrorDialog 
*/ 
private NetworkConnectionError networkConnectionErrorDialog ; 
//... your code ...// 
@Override 
protected void onStop() { 
    super.onStop(); 
    //invalidate the DialogFragment to avoid stupid memory leak 
    if (networkConnectionErrorDialog != null) { 
     if (networkConnectionErrorDialog .isVisible()) { 
      networkConnectionErrorDialog .dismiss(); 
     } 
     networkConnectionErrorDialog = null; 
    } 
} 
/** 
* The method called to display your dialogFragment 
*/ 
private void onDeleteCurrentCity(){ 
    FragmentManager fm = getSupportFragmentManager(); 
    networkConnectionErrorDialog =(DeleteAlert)fm.findFragmentByTag("networkError"); 
    if(networkConnectionErrorDialog ==null){ 
     networkConnectionErrorDialog =new DeleteAlert(); 
    } 
    networkConnectionErrorDialog .show(getSupportFragmentManager(), "networkError"); 
} 

Et cette façon, vous éviter les fuites de mémoire (car il est mauvais) et vous vous assurer ne disposez pas d'un fragment statique putain qui ne peut pas accéder aux champs et méthodes de votre activité. C'est la bonne façon de gérer ce problème, de mon point de vue.

Answer 3

Tous les DialogFragments doivent être publics et, si la classe interne est statique. Ils devraient aussi avoir un constructeur sans-argument public, et ne compter que sur setArguments() pour le passage de paramètres. Si vous ne respectez pas ce principe, vous avez produit un avertissement de peluches que vous pouviez supprimer si vous le souhaitiez, mais à partir de la bibliothèque de support Android v25, vous obtiendrez une exception si vous essayez d'afficher un DialogFragment qui ne se conforme pas à ces règles:

java.lang.IllegalStateException: Fragment TestActivity$TestDialogFrament must be a public static class to be properly recreated from instance state.

la raison en est, comme indiqué, que le système d'exploitation doit être capable de recréer tous les fragments dans le cas où quelque chose comme une situation de faible mémoire, il oblige à détruire des fragments quand une application est mise en arrière-plan. Lorsque l'application est à nouveau mise au premier plan, les fragments doivent pouvoir être recréés à partir de l'état de l'application sérialisée, ce qui n'est pas possible pour les classes internes non statiques autres que celles d'une instance de la classe externe La création n'est pas faite à partir de ce contexte. Malheureusement, cela rend les choses plus complexes pour les boîtes de dialogue, car il est généralement très pratique de créer simplement une sous-classe anonyme qui remplace onCreateDialog. Cependant, un tel dialogue ne serait pas capable de recréer du tout.