Yeni bir Android Parçası oluşturmak için en iyi uygulama


707

Bir uygulamada yeni bir Parçayı başlatmak için iki genel uygulama gördüm:

Fragment newFragment = new MyFragment();

ve

Fragment newFragment = MyFragment.newInstance();

İkinci seçenek statik bir yöntem kullanır newInstance()ve genellikle aşağıdaki yöntemi içerir.

public static Fragment newInstance() 
{
    MyFragment myFragment = new MyFragment();
    return myFragment;
}

İlk başta, ana fayda, bir Fragment'ın yeni örneklerini oluştururken esneklik sağlamak için newInstance () yöntemini aşırı yükleyebileceğimi düşündüm - ama bunu Fragment için aşırı yüklenmiş bir kurucu oluşturarak da yapabilirim.

Bir şey mi kaçırdım?

Bir yaklaşımın diğerine göre faydaları nelerdir? Yoksa sadece iyi bir uygulama mı?


Parametreler olduğunda, seçenek yoktur ve bu burada kapsamlı bir şekilde cevaplanır. Yine de, soru, parçanın tartışmasız inşası için kalır.
rds

1
Fabrika desenleri ve bir nesnenin kendisini örneklemeyen bir çağırma sınıfının onları ayırmada nasıl yardımcı olduğunu öğrendikten sonra, bunun newInstance () yöntemi için güçlü bir nokta olacağını düşündüm. Bunda yanlış mıyım? Bu söz konusu argümanı bir fayda olarak görmedim.
Mobil Uygulamalar

Yanıtlar:


1139

Android, Parçanızı daha sonra yeniden oluşturmaya karar verirse, parçanızın bağımsız değişken yapıcısını çağırır. Yani kurucuyu aşırı yüklemek bir çözüm değildir.

Bununla birlikte, bir Parçanın Android tarafından yeniden oluşturulduktan sonra kullanılabilir olmaları için parçanıza bir şeyler iletmenin yolu, setArgumentsyönteme bir paket iletmektir .

Örneğin, parçaya bir tamsayıyı iletmek isteseydik şöyle bir şey kullanırdık:

public static MyFragment newInstance(int someInt) {
    MyFragment myFragment = new MyFragment();

    Bundle args = new Bundle();
    args.putInt("someInt", someInt);
    myFragment.setArguments(args);

    return myFragment;
}

Ve daha sonra Fragment'ta onCreate()bu tamsayıya aşağıdakileri kullanarak erişebilirsiniz:

getArguments().getInt("someInt", 0);

Parça bir şekilde Android tarafından yeniden oluşturulmuş olsa bile bu Paket kullanılabilir olacak.

Ayrıca not: setArgumentsyalnızca Fragman Aktiviteye eklenmeden önce çağrılabilir.

Bu yaklaşım aynı zamanda android geliştirici referansında da belgelenmiştir: https://developer.android.com/reference/android/app/Fragment.html


7
@Vlasto maalesef statik yöntemler geçersiz kılınamaz.
AJD

8
@yydl Burada bir şey eksik olduğumu düşünüyorum, yine de burada bir yapıcı kullanamaz mıydınız, Bundle'ı oluşturan ve setArguments () 'i çağıran hala kodunuz tarafından çağrıldığından (Android'inizi yeniden oluşturduğunda değil) fragmanı)?
Mike Tunnicliffe

9
@mgibson Sen gerekir Eğer fragmanları sonradan yeniden edildiğinde veriler olmasını istiyorsanız bir paket kullanın.
yydl

114
Parçalar için tartışmasız bir kurucu oluşturmak için ZORUNLU olmak, potansiyel olarak tüm programlamada, her yerde en büyük gotcha'dır. Nesne oluşturma ve başlatmada tam bir paradigma değişikliğini zorlar. Android'de yeniyseniz ve bu konuyu tökezlediyseniz, lütfen yukarıdaki cevabı tekrar tekrar okuyun.
rmirabelle

9
Bu iddiaya karşı çıkarım. Birincisi, tür güvenliği bir çerçeve endişe değil, bir dil endişesidir. İkincisi, IMO, çerçeve "API'nizin asla yapmaması gereken şeyler" alanına giriyor. Eğer kongre kütüphanesini parça kurucuma aktarmak istersem, o zaman izin vermeliyim. "Değişken olmayan" yapıcı sözleşmesi temel olarak parçalarda bağımlılık enjeksiyonu kullanımını öldürür - büyük yuck.
rmirabelle

95

newInstance()Gördüğüm kullanmanın tek yararı şunlardır:

  1. Parçanın kullandığı tüm argümanların bir araya getirilebileceği tek bir yeriniz olacak ve bir parçayı her başlattığınızda aşağıdaki kodu yazmak zorunda kalmayacaksınız.

    Bundle args = new Bundle();
    args.putInt("someInt", someInt);
    args.putString("someString", someString);
    // Put any other arguments
    myFragment.setArguments(args);
  2. Diğer sınıflara sadakatle çalışmayı beklediğini söylemenin iyi bir yoludur (ancak parça örneğinde hiçbir argüman paketlenmemişse vakaları işleyebilmelisiniz).

Yani, benim bir newInstance()parçamın örneğini oluşturmak için statik kullanmak iyi bir uygulamadır.


4
1) Bu, mantığı bir kurucuya koymaktan nasıl farklıdır? Her ikisi de bu mantığı eklediğiniz tek yerlerdir. 2) Statik bir fabrikadaki parametreler, bir yapıcıdaki parametrelerden nasıl farklıdır? Her ikisi de hangi argümanların beklendiğini söyler. Demek istediğim, bu farklı bir paradigma, elbette, ancak bunun yapıcıları kullanmanın açık bir yararı yok.
RJ Cuthbertson

2
Parça için özel kurucuları kullanamazsınız. Framework, parçaları geri yüklemek için argüman yapıcı kullanmaz.
500865

5
Evet, orada sana katılıyorum. Kavramsal olarak, aşırı yük yapıcıları kullanmak yerine statik fabrika modelini kullanmanın hiçbir faydası olmadığını söylüyorum. Her iki noktanız da her iki kalıpta da geçerlidir; birini diğerinin üzerinde kullanmanın bir yararı yoktur. Android sizi statik fabrika modelini kullanmaya zorlar - ancak birini veya diğerini kullanmanın bir yararı yoktur.
RJ Cuthbertson

pastebin.com/EYJzES0j
RJ Cuthbertson

@RJCuthbertson Olası bir fayda , statik fabrika yöntemi sınıfının alt sınıflarını oluşturma ve döndürme , yani duruma uygun bir alt sınıfı geri verme yeteneği olacaktır .
urgentx

62

Başka bir yol daha var:

Fragment.instantiate(context, MyFragment.class.getName(), myBundle)

Yanılmıyorsam, bu yalnızca Android Destek kitaplığını kullandığınızda mümkündür.
Timo

2
Bunu destek kitaplığıyla denedim, ancak onCreateView'de (parçamda), geçen paket boştu, bu yüzden setArguments / getArguments seçeneğiyle gittim ve işe yaradı (bunu okuyan herkes için).
Jrop

1
İlginçtir, daha önce bu yaklaşımı görmedim. Bir Parçayı örneklemenin diğer yaklaşımlarına göre herhangi bir avantajı var mı?
IgorGanapolsky

23
Gönderen geliştirici dokümanlar ,instantiate() Creates a new instance of a Fragment with the given class name. This is the same as calling its empty constructor.
Brian Bowman

2
Her ne kadar boş kurucu çağırmaktan bahsettiler. "args.setClassLoader (f.getClass () getClassLoader ().);" demeti argümanları altında çağrıldı
Gökhan Barış Aker

49

@Yydl, newInstanceyöntemin neden daha iyi olduğuna dair zorlayıcı bir neden verirken :

Android, Parçanızı daha sonra yeniden oluşturmaya karar verirse, parçanızın bağımsız değişken yapıcısını çağırır. Yani kurucuyu aşırı yüklemek bir çözüm değildir.

bir kurucu kullanmak hala mümkün . Bunun nedenini görmek için, öncelikle yukarıdaki geçici çözümün Android tarafından neden kullanıldığını görmemiz gerekir.

Bir parçanın kullanılabilmesi için önce bir örneğe ihtiyaç vardır. Parçanın bir örneğini oluşturmak için Android çağrıları YourFragment()( argüman oluşturucu yok ). Android, hangisini kullanacağını bilemediğinden, yazdığınız aşırı yüklenmiş kurucu yok sayılır.

Bir Faaliyetin ömrü boyunca, parça yukarıdaki gibi oluşturulur ve Android tarafından birçok kez imha edilir. Bu, parça nesnesinin kendisine veri koyarsanız, parça yok edildiğinde verilerin kaybolacağı anlamına gelir.

Geçici çözüm olarak, android daha sonra erişilebilen bir Bundle(çağrı setArguments()) kullanarak veri depolamanızı ister YourFragment. Bağımsız değişkenler bundleAndroid tarafından korunur ve bu nedenle kalıcı olması garanti edilir .

Bu paketi ayarlamanın bir yolu statik bir newInstanceyöntem kullanmaktır:

public static YourFragment newInstance (int data) {
    YourFragment yf = new YourFragment()
    /* See this code gets executed immediately on your object construction */
    Bundle args = new Bundle();
    args.putInt("data", data);
    yf.setArguments(args);
    return yf;
}

Ancak bir kurucu:

public YourFragment(int data) {
    Bundle args = new Bundle();
    args.putInt("data", data);
    setArguments(args);
}

newInstanceyöntemle tam olarak aynı şeyi yapabilir .

Doğal olarak, bu başarısız olur ve Android'in newInstanceyöntemi kullanmanızı istemesinin nedenlerinden biridir :

public YourFragment(int data) {
    this.data = data; // Don't do this
}

Daha fazla açıklama olarak, Android'in Fragment Sınıfı:

/**
 * Supply the construction arguments for this fragment.  This can only
 * be called before the fragment has been attached to its activity; that
 * is, you should call it immediately after constructing the fragment.  The
 * arguments supplied here will be retained across fragment destroy and
 * creation.
 */
public void setArguments(Bundle args) {
    if (mIndex >= 0) {
        throw new IllegalStateException("Fragment already active");
    }
    mArguments = args;
}

Android'in, argümanların yalnızca yapım aşamasında ayarlanmasını istediğini ve bunların saklanacağını garanti ettiğini unutmayın.

DÜZENLEME : @JHH tarafından yapılan açıklamalarda belirtildiği gibi, bazı bağımsız değişkenler gerektiren özel bir yapıcı sağlıyorsanız, Java parçanıza arg varsayılan yapıcısı sağlamaz . Bu nedenle, bir arg yapıcısı tanımlamanız gerekir , bu da newInstancefabrika yöntemiyle kaçınabileceğiniz koddur .

EDIT : Android artık fragmanlar için aşırı yüklenmiş bir kurucu kullanılmasına izin vermiyor. newInstanceYöntemi kullanmalısınız .


Ne zaman android kullanarak haklı: configChanges = "yönlendirme | keyboardHidden | screenSize"?
Luke Allison

1
Android Studio artık parçalardaki varsayılan olmayan tüm kurucular için bir hata veriyor, bu yüzden artık çalışmıyor.
Sheharyar

6
Kutsal adam, droid dışında kaç tane droid geliştiricisinin kod yazdığını merak ediyorum. Tanımladığınız yaklaşımı kullanamayacağımız delilik. Statik fabrika yöntemini neden kullanmamız gerektiğine dair herhangi bir yorumdan HİÇBİR argüman yoktur. Derleme sırasında hata yapmaları daha da rahatsız edicidir. Bu kesinlikle verilen en iyi cevaptır ve sfm'ye fayda olmadığını gösterir.
MPavlak

3
İnce bir sebep var. Bağımsız değişkenlerle kendi kurucunuzu oluşturmakta özgürsünüz, ancak yine de arg olmayan bir kurucuya ihtiyaç vardır . Sınıflar hep örtük bir no-arg yapıcı olduğundan args ile bir yapıcı açıkça tanımlanmış sürece , bu araçlar size arg-yapıcı hem tanımlamak zorunda olacağı ve açıkça no-arg yapıcı veya sistem herhangi çağırmak için mümkün olmaz no-arg yapıcısı. Bu yüzden tavsiyenin bunun yerine statik bir fabrika yöntemi kullanmak olduğuna inanıyorum - sadece arg olmayan bir kurucu tanımlamayı unutma riskini azaltır.
JHH

@JHH derleme zamanında başarısız olacak, bu yüzden büyük bir risk değil. Bununla birlikte, buradaki sorun, temel bir programlama paradigması olan yapıcı aşırı yüklemesinin Android tarafından reddedilmesidir.
ps95

20

Ben yydi cevap söyleyerek katılmıyorum :

Android, Parçanızı daha sonra yeniden oluşturmaya karar verirse, parçanızın bağımsız değişken yapıcısını çağırır. Yani kurucuyu aşırı yüklemek bir çözüm değildir.

Bence bu bir çözüm ve iyi bir çözüm, Java çekirdek dili tarafından geliştirilmesinin nedeni de tam olarak bu.

Android sistemi yok edebilir ve yeniden oluşturabilirsiniz doğrudur Fragment. Böylece bunu yapabilirsiniz:

public MyFragment() {
//  An empty constructor for Android System to use, otherwise exception may occur.
}

public MyFragment(int someInt) {
    Bundle args = new Bundle();
    args.putInt("someInt", someInt);
    setArguments(args);
}

Sistem tarafından yeniden oluşturulmuş olsa bile someInt, getArguments()ikincisini çekmenize izin verecektir Fragment. Bu, kurucudan daha zarif bir çözümdür static.

Bence staticinşaatçılar işe yaramaz ve kullanılmamalıdır. Ayrıca gelecekte bunu genişletmek Fragmentve yapıcıya daha fazla işlevsellik eklemek isterseniz sizi sınırlarlar . İle staticyapıcı bunu yapamaz.

Güncelleme:

Android, varsayılan olmayan tüm kurucuları hata ile işaretleyen inceleme ekledi.
Yukarıda belirtilen nedenlerden dolayı devre dışı bırakmanızı öneririm.


4
Yukarıda bahsetmediğim statik bir yönteme sahip olmanın bir başka yararı, yanlışlıkla özellikleri ayarlayamamanızdır.
yydl

4
Ek olarak, "bu parçayı genişlet" konusundaki görüşünüzle ilgili olarak, sınıfı genişletirseniz bu yöntem gerçekten kötü olur. Süper çağrıldığında, setArguments () çağrısının yalnızca alt öğe veya üst öğe için etkili olmasına neden olur, ancak her ikisinde birden etkili olmaz!
yydl

2
@ yydle, alt Paketi başlatmak için get argümanlarını çağırarak bu durumdan kaçınabilirsiniz. Java yolu her zaman daha iyidir.
Ilya Gazman

9
Doğru, ancak bu, insanları Google'ın önerdiği kalıbı kullanmaya teşvik etmek için başka bir neden. Tabii ki, hepimiz çözümünüzün teknik olarak% 100 uygun olduğunu kabul ediyoruz. Aynı şekilde birçok şey yapmanın birçok yolu vardır. Ancak soru, bunun en iyi olup olmadığıdır. Ve yapıcıyı kullanmanın bunun nasıl çalışması gerektiğinin gerçek doğasını temsil etmediğini kuvvetle hissediyorum.
yydl

3
@Yydl ile statik oluşturmanın daha iyi olduğuna katılıyorum. Diğer bir fayda, gelecekteki yeni bağımlılıkların bağımlılık enjeksiyonudur - kurucu bunun için uygun değildir ve muhtemelen daha fazla kod değişikliğine neden olacaktır (veya daha fazla kurucu eklenecektir).
Boon

19

Bazı kotlin kodu:

companion object {
    fun newInstance(first: String, second: String) : SampleFragment {
        return SampleFragment().apply {
            arguments = Bundle().apply {
                putString("firstString", first)
                putString("secondString", second)
            }
        }
    }
}

Ve bununla tartışabilirsiniz:

val first: String by lazy { arguments?.getString("firstString") ?: "default"}
val second: String by lazy { arguments?.getString("secondString") ?: "default"}

3

Android'de argümanları olan parçaları örneklemek için en iyi uygulama, parçanızda statik fabrika yöntemine sahip olmaktır.

public static MyFragment newInstance(String name, int age) {
    Bundle bundle = new Bundle();
    bundle.putString("name", name);
    bundle.putInt("age", age);

    MyFragment fragment = new MyFragment();
    fragment.setArguments(bundle);

    return fragment;
}

Alanlarınızı bir parça örneği ile ayarlamaktan kaçınmalısınız. Çünkü android sistem parçanızı yeniden oluşturduğunda, sistemin daha fazla belleğe ihtiyacı olduğunu hissediyorsa, argümansız yapıcı kullanarak parçanızı yeniden oluşturacaktır.

Burada argümanlarla fragmanları başlatmak için en iyi uygulama hakkında daha fazla bilgi bulabilirsiniz .


2

En iyi uygulama ile ilgili sorulardan beri, bazı REST web hizmetleriyle çalışırken parça oluşturmak için hibrit yaklaşımı kullanmak için çok iyi bir fikir olduğunu ekliyorum.

Kullanıcı parçasını görüntüleme durumunda karmaşık nesneleri, örneğin bazı Kullanıcı modelini geçiremeyiz

Ama yapabileceğimiz, check-in yapmak onCreate o kullanıcıyı ! = Null ve eğer değilse - veri katmanından getirin, aksi takdirde - mevcut kullanın.

Bu şekilde, hem Android tarafından parça rekreasyonu ve kullanıcı eylemleri için snappiness durumunda userId tarafından yeniden oluşturma yeteneği, hem de kendisini nesneye tutarak veya yalnızca kimliğini tutarak parça oluşturma yeteneği kazanırız

Bir şey bunu seviyor:

public class UserFragment extends Fragment {
    public final static String USER_ID="user_id";
    private User user;
    private long userId;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        userId = getArguments().getLong(USER_ID);
        if(user==null){
            //
            // Recreating here user from user id(i.e requesting from your data model,
            // which could be services, direct request to rest, or data layer sitting
            // on application model
            //
             user = bringUser();
        }
    }

    public static UserFragment newInstance(User user, long user_id){
        UserFragment userFragment = new UserFragment();
        Bundle args = new Bundle();
        args.putLong(USER_ID,user_id);
        if(user!=null){
            userFragment.user=user;
        }
        userFragment.setArguments(args);
        return userFragment;

    }

    public static UserFragment newInstance(long user_id){
        return newInstance(null,user_id);
    }

    public static UserFragment newInstance(User user){
        return newInstance(user,user.id);
    }
}

3
"Karmaşık nesneleri, örneğin bazı Kullanıcı modellerini geçiremeyiz" dediniz. - Bu doğru değil, yapabiliriz. Bunun gibi: User user = /*...*/ kullanıcıyı pakete koyun: Bundle bundle = new Bundle(); bundle.putParcelable("some_user", user); ve kullanıcıyı bağımsız değişkenlerden alın: User user = getArguments().getParcelable("some_user"); Nesnenin Parcelable arabirimini uygulaması gerekir. bağlantı
Adam Varhegyi

3
Evet, ama sınıf karmaşık olduğunda ve başka nesnelere yönlendirmeler içerdiğinde ... Ben şahsen basit tutmayı tercih ederim, ya nesnem var, ya da almıyorum ve sonra almam gerekiyor
Tigra

1

bu kodu kullanın% 100 sorununuzu düzeltin

Bu kodu girmek firstFragment

public static yourNameParentFragment newInstance() {

    Bundle args = new Bundle();
    args.putBoolean("yourKey",yourValue);
    YourFragment fragment = new YourFragment();
    fragment.setArguments(args);
    return fragment;
}

bu örnek boole verileri gönderir

ve SecendFragment içinde

yourNameParentFragment name =yourNameParentFragment.newInstance();
   Bundle bundle;
   bundle=sellDiamondFragments2.getArguments();
  boolean a= bundle.getBoolean("yourKey");

ilk parçadaki değer statik olmalıdır

mutlu kod


0

Parçayı örneklemenin en iyi yolu, varsayılan Fragment.instantiate yöntemini kullanmaktır veya parçayı örneklemek için fabrika yöntemi oluşturmaktır
Dikkat: parça belleğini geri yüklerken her zaman parçada bir boş yapıcı oluşturun, çalışma zamanı istisnası atar.


0

Son zamanlarda buradayım. Ama bildiğim bazı şeyler sana biraz yardımcı olabilir.

Java kullanıyorsanız, değiştirecek çok şey yoktur. Ancak kotlin geliştiricileri için, aşağıdaki bazı snippet'i düşünüyorum, bu da sizi çalıştırmak için bir bodrum yapabilir:

  • Üst parça:
inline fun <reified T : SampleFragment> newInstance(text: String): T {
    return T::class.java.newInstance().apply {
        arguments = Bundle().also { it.putString("key_text_arg", text) }
    }
}
  • Normal çağrı
val f: SampleFragment = SampleFragment.newInstance("ABC")
// or val f = SampleFragment.newInstance<SampleFragment>("ABC")
  • Alt parça sınıfındaki üst başlatma işlemini şu yollarla genişletebilirsiniz:
fun newInstance(): ChildSampleFragment {
    val child = UserProfileFragment.newInstance<ChildSampleFragment>("XYZ")
    // Do anything with the current initialized args bundle here
    // with child.arguments = ....
    return child
}

Mutlu kodlama.


-2

setArguments()yararsızdır. Sadece bir karmaşa getirir.

public class MyFragment extends Fragment {

    public String mTitle;
    public String mInitialTitle;

    public static MyFragment newInstance(String param1) {
        MyFragment f = new MyFragment();
        f.mInitialTitle = param1;
        f.mTitle = param1;
        return f;
    }

    @Override
    public void onSaveInstanceState(Bundle state) {
        state.putString("mInitialTitle", mInitialTitle);
        state.putString("mTitle", mTitle);
        super.onSaveInstanceState(state);
    }

    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle state) {
        if (state != null) {
            mInitialTitle = state.getString("mInitialTitle");
            mTitle = state.getString("mTitle");
        } 
        ...
    }
}

Sadece bir yöntemi daha geçersiz kılmaya ve onViewCreatedkapsamla izole edilmiş bir alan oluşturmaya zorlanmanız dışında . Sanırım kolaylık, aynı şeyi yapmanın birçok yolu. Ayrıca kullanıcı tarafından yapılan güncellemeleri kontrol etmenin kolay bir yoludur (paketlerini getArgumentsve paketini karşılaştırın onSaveInstanceState)
Overclover

@Asagen, başlangıç ​​ve kullanıcı değerlerini karşılaştırma hakkındaki yorumunuzu beğendim. Ben kodu düzenledi ve hala düzgün ve net witout getArgumentsşeyler olduğunu düşünüyorum. Peki ya onViewCreatedkapsam ... Devlet paketini geri yükleyebiliriz. Ama ben sadece onCreateViewhafif ve hızlı yapmayı tercih ediyorum ve tüm ağır başlatmaları yapıyorum onActivityCreatedçünkü Fragment.getActivity()bazen geri dönmek nullve onAttach()API 23'ün yeni sürümündeki değişiklikler nedeniyle .
Vadim Star

Bütün burada yaptığım hareket set ve get Argumentsiçine saveInstanceState. Aslında "kaputun altında" yapılanla aynı şeyi yapıyorsunuz
OneCricketeer

1
@ cricket_007 veya tam tersi . Kullanımı saveInstanceState"kaputun altında". Ve kullanımı Arguments, iki kez kontrol etmenizi sağlayan işlevselliğin kopyalanmasıdır: ilk Argumentsdeğerler ve sonra saveInstanceStatedeğerler. Çünkü saveInstanceStateherhangi bir şekilde kullanmak zorundasın . Peki ya Arguments... gerekli değiller.
Vadim Star

Bağımsız değişkenler, fragmanlar için Niyet ekstralarının eşdeğeridir . İşe yaramazlar, mevcut durumdan farklı olan başlangıç ​​parametrelerini içerirler.
BladeCoder

-12

Bunun için çok daha basit bir çözümüm olduğuna inanıyorum.

public class MyFragment extends Fragment{

   private String mTitle;
   private List<MyObject> mObjects;

   public static MyFragment newInstance(String title, List<MyObject> objects)
   MyFragment myFrag = new MyFragment();
   myFrag.mTitle = title;
   myFrag.mObjects = objects;
   return myFrag;
   }

12
MyFragment yeniden oluşturulursa mObjects silinir (kullanıcı cihazın ana ekranına gider ve daha sonra MyFragment'ta bırakılan uygulamayı açar). MyFragment'ı bağımsız değişken olarak bir paket göndererek mObjects'i tutabilirsiniz.
ynnadkrap

1
Ayrıca, statik yöntem statik olmayan üye değişkenlere nasıl erişir?
OrhanC1

2
@ynnadkrap Doğru, bir paket kullanmak buraya gitmenin yoludur.
Stefan Bogaard

2
@ OrhanC1 Bu örnek koduna göre, statik yöntem üye değişkenlere erişmiyor. MyFragment örneği üyelerine erişiyor. Burada hata yok. Ancak, bu cevabı kimseye önermiyorum çünkü parçanız hafızadan çıkarıldığında android os tarafından bir miktar alan açmak için aktiviteyi yeniden başlattıktan sonra ve bu parça karınca değişkenleri atamadan varsayılan boş yapıcı ile oluşturulacak.
Gunhan

@Gunhan Haklısın! Değil. Karışıklık için özür dilerim :)
OrhanC1
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.