Warum möchte ich nicht-Standard-Konstruktoren in Fragmenten vermeiden?

Ich schaffe eine App mit Fragments und in einem von ihnen habe ich einen Nicht-Standard-Konstruktor erstellt und bekam diese Warnung:

 Avoid non-default constructors in fragments: use a default constructor plus Fragment#setArguments(Bundle) instead 

Kann mir jemand sagen, warum das nicht eine gute Idee ist?

  • Erhöhe die Aufnahmeaufzeichnung Android AudioRecord
  • Warum haben die meisten Android-Geräte keinen Swap-Bereich als typisches Betriebssystem?
  • Wie kann ich mit dem APK auf das Android STK Menü zugreifen?
  • Verwenden von android.app.Fragment mit ViewPager in Android 3.0+
  • Testen von Android-Projekt mit Jar Dependecies
  • Wie importiere ich eine .aar Datei in Android Studio 1.1.0 und benutze sie in meinem Code
  • Können Sie auch vorschlagen, wie ich das erreichen würde:

     public static class MenuFragment extends ListFragment { public ListView listView1; Categories category; //this is my "non-default" constructor public MenuFragment(Categories category){ this.category = category; }.... 

    Ohne den Nicht-Standard-Konstruktor zu verwenden?

  • Wie integriere ich Google Analytics in Android App
  • Fügen Sie eine neue Benachrichtigung hinzu, wenn die Push-Benachrichtigung (nicht ersetzt wird)
  • Sound-Erkennung in Android
  • Warum seltsame Namenskonvention von "AlertDialog.Builder" anstelle von "AlertDialogBuilder" in Android
  • So löschen Sie Daten aus einem JSON Array
  • Android png optimierung
  • 6 Solutions collect form web for “Warum möchte ich nicht-Standard-Konstruktoren in Fragmenten vermeiden?”

    Machen Sie ein Bündelobjekt und fügen Sie Ihre Daten ein (in diesem Beispiel Ihr Category Objekt). Sei vorsichtig, du kannst dieses Objekt nicht direkt in das Bündel übergeben, es sei denn, es ist serialisierbar. Ich denke, es ist besser, deinen Gegenstand im Fragment zu bauen und nur eine ID oder etwas anderes ins Bündel zu legen. Dies ist der Code zum Erstellen und Anfügen eines Bündels:

     Bundle args = new Bundle(); args.putLong("key", value); yourFragment.setArguments(args); 

    Danach in deinem Fragmentzugriffsdaten:

     Type value = getArguments().getType("key"); 

    Das ist alles.

    Es scheint, als ob keiner der Antworten tatsächlich antwortet "Warum Bündel zum Übergeben von Parametern anstelle von Nicht-Standard-Konstruktoren verwenden"

    Der Grund, warum Sie Parameter über Bündel übergeben sollten, ist, dass, wenn das System ein fragment wiederherstellt (zB bei Konfigurationsänderung), wird es automatisch Ihr bundle wiederherstellen.

    Die Rückrufe wie onCreate oder onCreateView sollten die Parameter aus dem bundle lesen – auf diese Weise werden Sie garantiert, dass der Zustand des fragment korrekt in denselben Zustand wiederhergestellt wird, in dem das fragment initialisiert wurde (beachten Sie, dass dieser Zustand sich von dem onSaveInstanceState bundle unterscheiden kann Zum onCreate/onCreateView )

    Die Empfehlung zur Verwendung der statischen newInstance() -Methode ist nur eine Empfehlung. Sie können einen Nicht-Standard-Konstruktor verwenden, aber stellen Sie sicher, dass Sie die Initialisierungsparameter im bundle innerhalb des Körpers dieses Konstruktors füllen. Und lese diese Parameter in den onCreate() oder onCreateView() .

    Ihr Fragment sollte nicht über Konstrukteure verfügen, weil der FragmentManager instanziiert. Sie sollten eine newInstance() statische Methode mit den newInstance() Parametern definiert haben, dann bündeln und sie als Argumente des Fragments festlegen, die Sie später mit dem Bundle Parameter Bundle .

    Beispielsweise:

     public static MyFragment newInstance(int title, String message) { MyFragment fragment = new MyFragment(); Bundle bundle = new Bundle(2); bundle.putInt(EXTRA_TITLE, title); bundle.putString(EXTRA_MESSAGE, message); fragment.setArguments(bundle); return fragment ; } 

    Und lese diese Argumente bei onCreate :

     @Override public void onCreate(Bundle savedInstanceState) { title = getArguments().getInt(EXTRA_TITLE); message = getArguments().getString(EXTRA_MESSAGE); //... } 

    Auf diese Weise, wenn abgelöst und wieder befestigt, kann der Objektzustand durch die Argumente gespeichert werden, ähnlich wie bundles an Intent s.

    Wenn Sie den Parameter für eine Klasse verwenden. Versuche dies

     SomeClass mSomeInstance; public static final MyFragment newInstance(SomeClass someInstance){ MyFragment f = new MyFragment(); f.mSomeInstance = someInstance; return f; } 

    Ich habe die Methode benutzt und es funktioniert!

     public FragmentHome() { // Required empty public constructor } public void FragmentHomeConstructor(Context context, String stringBundle) { mContext = context; mStringBundle = stringBundle; } 

    Füge dies in Fragment's oncreate () Methode, um Kontext ohne Fehler zu bekommen!

     mContext = this.getActivity(); 

    In oncreate() Methode Ihrer Tätigkeit:

     FragmentHome fragmentHome = new FragmentHome(); fragmentHome.FragmentHomeConstructor(mContext, mStringBundle); 

    Ich denke, es gibt keinen Unterschied zwischen dem statischen Konstruktor und zwei Konstruktoren (leer und parametrisiert, die Argumente in ein Fragment-Argument-Bündel speichert), wahrscheinlich wird diese Faustregel erstellt, um die Wahrscheinlichkeit des Vergessens zu reduzieren, um keinen Arg-Konstruktor in Java zu implementieren , Was bei der Überlastung nicht implizit erzeugt wird.

    In meinen Projekten verwende ich Kotlin und implementiere Fragmente mit einem primären no-arg-Konstruktor und einem sekundären Konstruktor für Argumente, die sie nur in ein Bündel speichern und als Fragment-Argumente setzen, alles funktioniert gut.

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