Android में वैश्विक चर घोषित कैसे करें?




singleton global-variables (14)

मैं एक एप्लीकेशन बना रहा हूं जिसके लिए लॉगिन की आवश्यकता है। मैंने मुख्य और लॉगिन गतिविधि बनाई है।

onCreate विधि पर मुख्य गतिविधि में मैंने निम्नलिखित शर्त को जोड़ा:

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

    ...

    loadSettings();
    if(strSessionString == null)
    {
        login();
    }
    ...
}

onActivityResult विधि जिसे लॉग इन फॉर्म समाप्त होने पर निष्पादित किया जाता है, इस तरह दिखता है:

@Override
public void onActivityResult(int requestCode,
                             int resultCode,
                             Intent data)
{
    super.onActivityResult(requestCode, resultCode, data);
    switch(requestCode)
    {
        case(SHOW_SUBACTICITY_LOGIN):
        {
            if(resultCode == Activity.RESULT_OK)
            {

                strSessionString = data.getStringExtra(Login.SESSIONSTRING);
                connectionAvailable = true;
                strUsername = data.getStringExtra(Login.USERNAME);
            }
        }
    }

समस्या यह है कि लॉगिन फॉर्म कभी-कभी दो बार दिखाई देता है ( login() विधि को दो बार बुलाया जाता है) और जब फोन कीबोर्ड कुंजीपटल लॉग इन करता है तो फिर भी दिखाई देता है और मुझे लगता है कि समस्या परिवर्तनीय strSessionString

क्या किसी को पता है कि उपयोगकर्ता पहले ही सफलतापूर्वक प्रमाणीकृत होने के बाद दिखाई देने वाले लॉगिन फॉर्म से बचने के लिए परिवर्तनीय वैश्विक कैसे सेट करें?


मुझे एप्लिकेशन टैग को निर्दिष्ट करने का तरीका नहीं मिला, लेकिन बहुत सारे गूगलिंग के बाद, यह मैनिफेस्ट फ़ाइल डॉक्स से स्पष्ट हो गया: एप्लिकेशन आइकन में डिफ़ॉल्ट आइकन और लेबल के अलावा एंड्रॉइड: नाम का उपयोग करें।

एंड्रॉइड: नाम आवेदन के लिए लागू एक आवेदन उपclass का पूरी तरह से योग्य नाम। जब आवेदन प्रक्रिया शुरू हो जाती है, तो इस वर्ग को किसी भी एप्लिकेशन के घटकों से पहले तुरंत चालू किया जाता है।

उपclass वैकल्पिक है; अधिकांश अनुप्रयोगों की आवश्यकता नहीं होगी। उप-वर्ग की अनुपस्थिति में, एंड्रॉइड बेस एप्लिकेशन क्लास का एक उदाहरण उपयोग करता है।


आप दो दृष्टिकोणों का उपयोग करके ऐसा कर सकते हैं:

  1. आवेदन वर्ग का उपयोग करना
  2. साझा प्राथमिकताओं का उपयोग करना

  3. आवेदन वर्ग का उपयोग करना

उदाहरण:

class SessionManager extends Application{

  String sessionKey;

  setSessionKey(String key){
    this.sessionKey=key;
  }

  String getSessisonKey(){
    return this.sessionKey;
  }
}

आप उपरोक्त वर्ग का उपयोग अपनी मुख्य गतिविधि में लॉगिन को लागू करने के लिए कर सकते हैं। कोड इस तरह कुछ दिखाई देगा:

@override 
public void onCreate (Bundle savedInstanceState){
  // you will this key when first time login is successful.
  SessionManager session= (SessionManager)getApplicationContext();
  String key=getSessisonKey.getKey();
  //Use this key to identify whether session is alive or not.
}

यह विधि अस्थायी भंडारण के लिए काम करेगी। कम स्मृति की वजह से ऑपरेटिंग सिस्टम आवेदन को मारने वाला है, तो आपको वास्तव में कोई विचार नहीं है। जब आपका एप्लिकेशन पृष्ठभूमि में होता है और उपयोगकर्ता अन्य एप्लिकेशन के माध्यम से नेविगेट कर रहा है जो चलाने के लिए और अधिक मेमोरी की मांग करता है, तो आपके आवेदन को मार दिया जाएगा क्योंकि ऑपरेटिंग सिस्टम पृष्ठभूमि से अग्रभूमि प्रक्रियाओं को अधिक प्राथमिकता देता है। इसलिए उपयोगकर्ता लॉग आउट होने से पहले आपका एप्लिकेशन ऑब्जेक्ट शून्य हो जाएगा। इसलिए इसके लिए मैं ऊपर निर्दिष्ट दूसरी विधि का उपयोग करने की सलाह देते हैं।

  1. साझा प्राथमिकताओं का उपयोग करना।

    String MYPREF="com.your.application.session"
    
    SharedPreferences pref= context.getSharedPreferences(MyPREF,MODE_PRIVATE);
    
    //Insert key as below:
    
    Editot editor= pref.edit();
    
    editor.putString("key","value");
    
    editor.commit();
    
    //Get key as below.
    
    SharedPreferences sharedPref = getActivity().getPreferences(Context.MODE_PRIVATE);
    
    String key= getResources().getString("key");
    

मैंने इस जवाब को '0 9 में वापस लिखा था जब एंड्रॉइड अपेक्षाकृत नया था, और एंड्रॉइड विकास में कई अच्छी तरह से स्थापित क्षेत्र नहीं थे। मैंने इस पोस्ट के निचले भाग में एक लंबी परिशिष्ट जोड़ा है, कुछ आलोचनाओं को संबोधित किया है, और आवेदन के उप-वर्ग के बजाए सिंगलेट्स के उपयोग के साथ मेरे दार्शनिक असहमति का विवरण दिया है। इसे अपने जोखिम पर पढ़ें।

मूल उत्तर:

आप जितनी अधिक सामान्य समस्या का सामना कर रहे हैं वह है कि कई गतिविधियों और आपके आवेदन के सभी हिस्सों में राज्य को कैसे बचाया जाए। एक स्थैतिक चर (उदाहरण के लिए, एक सिंगलटन) इसे प्राप्त करने का एक सामान्य जावा तरीका है। हालांकि, मैंने पाया है कि एंड्रॉइड में एक और शानदार तरीका है कि आप अपने राज्य को एप्लिकेशन संदर्भ से जोड़ दें।

जैसा कि आप जानते हैं, प्रत्येक गतिविधि भी एक संदर्भ है, जो व्यापक रूप से इसके निष्पादन पर्यावरण के बारे में जानकारी है। आपके एप्लिकेशन में एक संदर्भ भी है, और एंड्रॉइड गारंटी देता है कि यह आपके एप्लिकेशन में एक ही उदाहरण के रूप में मौजूद होगा।

ऐसा करने का तरीका android.app.Application का अपना उप-वर्ग बनाना है, और फिर उस मेनिफेस्ट में एप्लिकेशन टैग में उस वर्ग को निर्दिष्ट करें। अब एंड्रॉइड स्वचालित रूप से उस वर्ग का एक उदाहरण बना देगा और इसे आपके पूरे एप्लिकेशन के लिए उपलब्ध कराएगा। आप Context.getApplicationContext() विधि का उपयोग कर किसी भी context से इसे एक्सेस कर सकते हैं ( Activity एक विधि getApplication() भी प्रदान करती है जिसका सटीक प्रभाव होता है)। चेतावनी के साथ निम्नलिखित अत्यंत सरल उदाहरण हैं:

class MyApp extends Application {

  private String myState;

  public String getState(){
    return myState;
  }
  public void setState(String s){
    myState = s;
  }
}

class Blah extends Activity {

  @Override
  public void onCreate(Bundle b){
    ...
    MyApp appState = ((MyApp)getApplicationContext());
    String state = appState.getState();
    ...
  }
}

यह अनिवार्य रूप से एक स्थिर चर या सिंगलटन का उपयोग करने के समान प्रभाव है, लेकिन मौजूदा एंड्रॉइड ढांचे में काफी अच्छी तरह से एकीकृत करता है। ध्यान दें कि यह प्रक्रियाओं में काम नहीं करेगा (क्या आपका ऐप दुर्लभ लोगों में से एक होना चाहिए जिसमें एकाधिक प्रक्रियाएं हों)।

ऊपर दिए गए उदाहरण से कुछ ध्यान देना; मान लीजिए कि हमने इसके बजाय कुछ किया था:

class MyApp extends Application {

  private String myState = /* complicated and slow initialization */;

  public String getState(){
    return myState;
  }
}

अब यह धीमा प्रारंभिकरण (जैसे डिस्क मारना, नेटवर्क मारना, कुछ अवरुद्ध करना आदि) हर बार आवेदन तत्काल किया जाएगा! आप सोच सकते हैं, ठीक है, यह प्रक्रिया के लिए केवल एक बार है और मुझे वैसे भी लागत का भुगतान करना होगा, है ना? मिसाल के तौर पर, जैसा कि डियान हैकबर्न नीचे उल्लेखित है, पृष्ठभूमि प्रक्रिया को संभालने के लिए आपकी प्रक्रिया को तत्काल-समायोजित करने के लिए पूरी तरह से संभव है। यदि आपके प्रसारण प्रसंस्करण की इस स्थिति की कोई आवश्यकता नहीं है तो आपने संभावित रूप से जटिल और धीमी परिचालन की पूरी श्रृंखला को कुछ भी नहीं किया है। आलसी तात्कालिकता यहां खेल का नाम है। निम्नलिखित एप्लिकेशन का उपयोग करने का एक और अधिक जटिल तरीका है जो उपयोग के सबसे सरल लेकिन कुछ भी के लिए अधिक समझ में आता है:

class MyApp extends Application {

  private MyStateManager myStateManager = new MyStateManager();

  public MyStateManager getStateManager(){
    return myStateManager ;
  }
}

class MyStateManager {

  MyStateManager() {
    /* this should be fast */
  }

  String getState() {
    /* if necessary, perform blocking calls here */
    /* make sure to deal with any multithreading/synchronicity issues */

    ...

    return state;
  }
}

class Blah extends Activity {

  @Override
  public void onCreate(Bundle b){
    ...
    MyStateManager stateManager = ((MyApp)getApplicationContext()).getStateManager();
    String state = stateManager.getState();
    ...
  }
}

जबकि मैं यहां और अधिक सुरुचिपूर्ण समाधान के रूप में सिंगलेट्स का उपयोग करने के लिए एप्लिकेशन सबक्लासिंग पसंद करता हूं, लेकिन मैं डेवलपर्स को सिंगलटन का उपयोग करना चाहूंगा, अगर प्रदर्शन के सब कुछ के साथ प्रदर्शन करने वाले राज्य के प्रदर्शन और बहुसंख्यक प्रभावों के माध्यम से वास्तव में सोचने पर वास्तव में आवश्यक नहीं है।

नोट 1: जैसा कि एंटीकाफ ने टिप्पणी की है, अपने एप्लिकेशन को सही ढंग से अपने एप्लिकेशन को ओवरराइड करने के लिए मैनिफेस्ट फ़ाइल में एक टैग आवश्यक है। फिर, अधिक जानकारी के लिए एंड्रॉइड दस्तावेज़ देखें। एक उदाहरण:

<application
     android:name="my.application.MyApp" 
     android:icon="..."
     android:label="...">
</application>

नोट 2: user608578 नीचे बताता है कि यह देशी ऑब्जेक्ट लाइफसाइक्सेस के प्रबंधन के साथ कैसे काम करता है। मैं थोड़ी सी में एंड्रॉइड के साथ मूल कोड का उपयोग करने की गति नहीं कर रहा हूं, और मैं यह जवाब देने के लिए योग्य नहीं हूं कि यह मेरे समाधान के साथ कैसे बातचीत करेगा। अगर किसी के पास इसका जवाब है, तो मैं उन्हें क्रेडिट करने और अधिकतम दृश्यता के लिए इस पोस्ट में जानकारी रखने के लिए तैयार हूं।

परिशिष्ट:

जैसा कि कुछ लोगों ने ध्यान दिया है, यह लगातार राज्य का समाधान नहीं है, मुझे शायद मूल उत्तर में कुछ और ज़ोर देना चाहिए था। हां यह उपयोगकर्ता या अन्य जानकारी को सहेजने का एक समाधान नहीं है जिसका मतलब है कि पूरे जीवनकाल में बने रहें। इस प्रकार, मैं किसी भी समय, आदि पर मारने वाले अनुप्रयोगों से संबंधित सबसे आलोचना पर विचार करता हूं ..., म्यूट, डिस्क पर बने रहने के लिए कभी भी जो कुछ भी आवश्यक है उसे किसी अनुप्रयोग उप-वर्ग के माध्यम से संग्रहीत नहीं किया जाना चाहिए। यह प्रकृति में अस्थायी, आसानी से पुन: रचनात्मक अनुप्रयोग स्थिति (चाहे उपयोगकर्ता को लॉग इन किया गया हो) और घटकों को एक उदाहरण के लिए एक उदाहरण है (उदाहरण के लिए एप्लिकेशन नेटवर्क प्रबंधक) (सिंगलटन नहीं !) को संग्रहीत करने का एक समाधान होना है।

डेरमैन रेटो मेयर और डियान हैकबर्न के साथ एक दिलचस्प बातचीत को इंगित करने के लिए काफी दयालु रहा है जिसमें आवेदन उपखंडों का उपयोग सिंगलटन पैटर्न के पक्ष में निराश होता है। सोमैटिक ने पहले इस प्रकृति की कुछ भी बताया, हालांकि मैंने उस समय इसे नहीं देखा था। एंड्रॉइड प्लेटफॉर्म को बनाए रखने में रेटो और डियान की भूमिकाओं के कारण, मैं अच्छी सलाह नहीं दे सकता कि उनकी सलाह को अनदेखा करने की सलाह दी जाए। वे क्या कहते हैं, चला जाता है। मैं आवेदन उपखंडों पर सिंगलटन को पसंद करने के संबंध में व्यक्त राय के साथ असहमत होना चाहता हूं। मेरी असहमति में मैं सिंगलटन डिजाइन पैटर्न के इस स्टैक एक्सचेंज स्पष्टीकरण में सबसे अच्छी तरह से समझाए गए अवधारणाओं का उपयोग कर रहा हूं, ताकि मुझे इस उत्तर में शर्तों को परिभाषित करने की आवश्यकता न हो। मैं लगातार जारी रखने से पहले लिंक को स्किमिंग करने के लिए प्रोत्साहित करता हूं। बिन्दुवार:

डियान कहते हैं, "आवेदन से उप-वर्ग का कोई कारण नहीं है। यह सिंगलटन बनाने से अलग नहीं है ..." यह पहला दावा गलत है। इसके दो मुख्य कारण हैं। 1) आवेदन वर्ग एक आवेदन डेवलपर के लिए एक बेहतर आजीवन गारंटी प्रदान करता है; यह आवेदन के जीवनकाल की गारंटी है। एक सिंगलटन आवेदन के जीवनकाल से जुड़ा हुआ नहीं है (हालांकि यह प्रभावी ढंग से है)। यह आपके औसत एप्लिकेशन डेवलपर के लिए एक गैर-मुद्दा हो सकता है, लेकिन मैं तर्क दूंगा कि एंड्रॉइड एपीआई की पेशकश की जाने वाली अनुबंध का बिल्कुल सही प्रकार है, और यह एंड्रॉइड सिस्टम के साथ-साथ जुड़े हुए जीवनकाल को कम करके, और अधिक लचीलापन प्रदान करता है डेटा। 2) आवेदन वर्ग राज्य डेवलपर को राज्य के लिए एक उदाहरण धारक के साथ प्रदान करता है, जो राज्य के सिंगलटन धारक से बहुत अलग है। मतभेदों की एक सूची के लिए, ऊपर सिंगलटन स्पष्टीकरण लिंक देखें।

डियान जारी है, "... भविष्य में आपको कुछ पछतावा होने की संभावना है क्योंकि आपको लगता है कि आपका एप्लिकेशन ऑब्जेक्ट इस बड़े गलेदार गड़बड़ बन गया है कि स्वतंत्र एप्लिकेशन तर्क क्या होना चाहिए।" यह निश्चित रूप से गलत नहीं है, लेकिन यह एप्लीकेशन सबक्लास पर सिंगलटन चुनने का कोई कारण नहीं है। डियान के तर्कों में से कोई भी एक कारण प्रदान नहीं करता है कि सिंगलटन का उपयोग किसी एप्लिकेशन सबक्लास से बेहतर है, वह यह स्थापित करने का प्रयास करती है कि सिंगलटन का उपयोग किसी एप्लिकेशन उप-वर्ग से भी बदतर नहीं है, जो मुझे विश्वास है कि यह गलत है।

वह आगे बढ़ती है, "और इससे आपको स्वाभाविक रूप से यह पता चलता है कि आपको इन चीजों का प्रबंधन कैसे करना चाहिए - उन्हें मांग पर शुरू करना।" यह इस तथ्य को अनदेखा करता है कि कोई भी कारण नहीं है कि आप एप्लिकेशन उपclass का उपयोग करके मांग पर प्रारंभ नहीं कर सकते हैं। फिर कोई फर्क नहीं पड़ता।

डियान के साथ समाप्त होता है "ढांचे के पास बनाए गए सभी छोटे साझा डेटा के लिए ढांचे और टन सिंगलटन होते हैं, जैसे कि लोड किए गए संसाधनों के कैश, ऑब्जेक्ट्स के पूल इत्यादि। यह बहुत अच्छा काम करता है।" मैं बहस नहीं कर रहा हूं कि सिंगलेट्स का उपयोग ठीक काम नहीं कर सकता है या वैध विकल्प नहीं है। मैं बहस कर रहा हूं कि सिंगलेट्स एंड्रॉइड सिस्टम के साथ एक एप्लीकेशन सबक्लास का उपयोग करने के रूप में मजबूत अनुबंध प्रदान नहीं करते हैं, और आगे यह है कि सिंगलेट्स का उपयोग आम तौर पर अनावश्यक डिजाइन को इंगित करता है, जिसे आसानी से संशोधित नहीं किया जाता है, और सड़क के नीचे कई समस्याएं होती हैं। आईएमएचओ, डेवलपर अनुप्रयोगों के लिए एंड्रॉइड एपीआई का मजबूत अनुबंध एंड्रॉइड के साथ प्रोग्रामिंग के सबसे आकर्षक और आकर्षक पहलुओं में से एक है, और शुरुआती डेवलपर गोद लेने में मदद करता है जिसने एंड्रॉइड मंच को आज की सफलता के लिए प्रेरित किया है। सिंगलेट्स का उपयोग करने का सुझाव स्पष्ट रूप से एक मजबूत एपीआई अनुबंध से दूर जा रहा है, और मेरी राय में, एंड्रॉइड ढांचे को कमजोर कर देता है।

डियान ने भी नीचे टिप्पणी की है, आवेदन उपखंडों का उपयोग करने के लिए अतिरिक्त नकारात्मक पक्ष का उल्लेख करते हुए, वे कम प्रदर्शन कोड लिखना आसान बना सकते हैं या इसे आसान बना सकते हैं। यह बहुत सच है, और मैंने इस उत्तर को यहां परफ पर विचार करने के महत्व पर जोर देने के लिए संपादित किया है, और यदि आप एप्लिकेशन सबक्लासिंग का उपयोग कर रहे हैं तो सही दृष्टिकोण लेना। जैसा कि डियान कहते हैं, यह याद रखना महत्वपूर्ण है कि आपकी प्रक्रिया कक्षा हर बार तत्काल हो जाएगी जब आपकी प्रक्रिया लोड हो जाती है (यदि आपका एप्लिकेशन एकाधिक प्रक्रियाओं में चलता है तो कई बार हो सकता है!) भले ही प्रक्रिया केवल पृष्ठभूमि प्रसारण के लिए लोड की जा रही हो घटना। इसलिए किसी भी प्रसंस्करण करने के लिए किसी स्थान के बजाय आपके आवेदन के साझा घटकों के लिए पॉइंटर्स के लिए एक भंडार के रूप में एप्लिकेशन क्लास का उपयोग करना महत्वपूर्ण है!

मैं आपको सिंगलेट्स को डाउनसाइड्स की निम्न सूची के साथ छोड़ देता हूं, जैसा कि पहले स्टैक एक्सचेंज लिंक से चुराया गया था:

  • सार या इंटरफ़ेस कक्षाओं का उपयोग करने में असमर्थता;
  • Subclass करने में असमर्थता;
  • आवेदन में उच्च युग्मन (संशोधित करना मुश्किल);
  • परीक्षण करने में मुश्किल (यूनिट परीक्षणों में नकली / नकली नहीं हो सकता है);
  • उत्परिवर्तनीय स्थिति के मामले में समानांतर करने में कठिनाई (व्यापक लॉकिंग की आवश्यकता है);

और अपना खुद का जोड़ें:

  • एंड्रॉइड (या अधिकतर) विकास के लिए अस्पष्ट और अप्रबंधनीय आजीवन अनुबंध अनुपयुक्त;

बस आपको नीचे दिए गए एप्लिकेशन नाम को परिभाषित करने की आवश्यकता है जो काम करेगा:

<application
  android:name="ApplicationName" android:icon="@drawable/icon">
</application>

इस तरह के राज्य को स्टोर करने के लिए आपके पास स्थिर क्षेत्र हो सकता है। या इसे संसाधन बंडल में डाल दें और वहां से क्रिएट (बंडल सेव किया गया इंस्टेंसस्टेट) पर पुनर्स्थापित करें। बस सुनिश्चित करें कि आप एंड्रॉइड ऐप प्रबंधित जीवन चक्र को पूरी तरह से समझते हैं (उदाहरण के लिए कीबोर्ड अभिविन्यास परिवर्तन पर क्यों लॉगिन () को कॉल किया जाता है)।


मैनिफेस्ट फ़ाइल में एक और <application> टैग का उपयोग करें। बस मौजूदा <application> टैग में एक बदलाव करें, इस लाइन को android:name=".ApplicationName" जोड़ें android:name=".ApplicationName" <application> android:name=".ApplicationName" जहां, ApplicationName नाम आपके उप-वर्ग का नाम होगा (वैश्विक स्टोर करने के लिए उपयोग करें ) कि, आप बनाने के बारे में है।

इसलिए, आखिर में आपका एक और केवल <application> टैग मेनिफेस्ट फ़ाइल में इस तरह दिखना चाहिए: -

<application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:label="@string/app_name"
        android:theme="@style/Theme.AppCompat.NoActionBar"
        android:name=".ApplicationName"
        >

ऐसी वैश्विक संरचनाओं के साथ देशी स्मृति के संग्रह को सुनिश्चित करने के बारे में क्या?

क्रियाकलापों पर एक onPause/onDestroy() विधि है जिसे विनाश पर बुलाया जाता है, लेकिन अनुप्रयोग वर्ग में कोई समकक्ष नहीं होता है। यह सुनिश्चित करने के लिए कि कौन से तंत्र की सिफारिश की जाती है कि ग्लोबल स्ट्रक्चर (विशेष रूप से देशी मेमोरी के संदर्भ वाले) कचरा उचित रूप से एकत्र किए जाते हैं जब एप्लिकेशन या तो मारे जाते हैं या कार्य स्टैक पृष्ठभूमि में रखा जाता है?


गतिविधि परिणाम पर फिर से शुरू करने के लिए कहा जाता है। तो फिर से शुरू करने के लिए आपको लॉग इन चेक पर ले जाएं और सीकॉम गतिविधि ने सकारात्मक परिणाम लौटाए जाने के बाद आपका दूसरा लॉगिन अवरुद्ध किया जा सकता है। फिर से शुरू करने पर हर बार बुलाया जाता है इसलिए इसकी चिंता नहीं होती है जिसे पहली बार नहीं कहा जाता है।


उप-वर्गीकरण के दृष्टिकोण का उपयोग बरैकस ढांचे द्वारा भी किया गया है। मेरे दृष्टिकोण से सबक्लासिंग एप्लिकेशन का उद्देश्य एंड्रॉइड की जीवनशैली के साथ काम करना था; यह वही है जो कोई भी एप्लीकेशन कंटेनर करता है। तब ग्लोबल्स होने के बजाय, मैं इस संदर्भ में सेम पंजीकृत करता हूं, उन्हें संदर्भ द्वारा प्रबंधित किसी भी वर्ग में इंजेक्शन देने दें। प्रत्येक इंजेक्शन बीन उदाहरण वास्तव में एक सिंगलटन है।

विवरण के लिए यह उदाहरण देखें

मैन्युअल काम क्यों करते हैं यदि आप इतना अधिक कर सकते हैं?


सिर्फ एक नोट ..

जोड़ें:

android:name=".Globals"

या जो भी आपने अपने उप-वर्ग को मौजूदा <application> टैग में नामित किया है। मैं मैनिफेस्ट में एक और <application> टैग जोड़ने की कोशिश करता रहा और उसे अपवाद मिलेगा।


class GlobaleVariableDemo extends Application {

    private String myGlobalState;

    public String getGlobalState(){
     return myGlobalState;
    }
    public void setGlobalState(String s){
     myGlobalState = s;
    }
}

class Demo extends Activity {

@Override
public void onCreate(Bundle b){
    ...
    GlobaleVariableDemo appState = ((GlobaleVariableDemo)getApplicationContext());
    String state = appState.getGlobalState();
    ...
    }
}

आवेदन के लिए राज्य रखने के सुनील तरीके से सुझाया गया अच्छा है, हालांकि इसमें एक कमजोर बिंदु है - ऐसे मामले हैं जब ओएस पूरी आवेदन प्रक्रिया को मारता है। इस पर प्रलेखन - प्रक्रियाएं और जीवनसाथी यहां दी गई हैं

एक मामले पर विचार करें - आपका ऐप पृष्ठभूमि में जाता है क्योंकि कोई आपको कॉल कर रहा है (फोन ऐप अब अग्रभूमि में है)। इस मामले में && कुछ अन्य स्थितियों के तहत (उपर्युक्त लिंक देखें कि वे क्या हो सकते हैं) ओएस एप्लिकेशन उपclass उदाहरण सहित आपकी एप्लिकेशन प्रक्रिया को मार सकता है। नतीजतन राज्य खो गया है। जब आप बाद में एप्लिकेशन पर वापस आते हैं, तो ओएस अपनी गतिविधि स्टैक और Application myState उदाहरण को पुनर्स्थापित करेगा, हालांकि myState फ़ील्ड null हो जाएगा।

AFAIK, राज्य सुरक्षा की गारंटी देने का एकमात्र तरीका राज्य को SharedPrefernces रखने के किसी भी प्रकार का उपयोग करना है, उदाहरण के लिए एप्लिकेशन फ़ाइल या SharedPrefernces लिए निजी का उपयोग करना (यह अंततः आंतरिक फाइल सिस्टम में एप्लिकेशन फ़ाइल के लिए एक निजी का उपयोग करता है)।


जैसा कि ऊपर चर्चा की गई थी, ओएस किसी भी अधिसूचना के बिना आवेदन को मार सकता है (डस्ट्रॉय इवेंट पर कोई नहीं है) इसलिए इन वैश्विक चरों को सहेजने का कोई तरीका नहीं है।

साझा किए गए संदर्भ एक समाधान हो सकते हैं जब आपके पास कॉम्प्लेक्स संरचित चर हैं (मेरे मामले में मेरे पास पहले से संभाले गए आईडी को स्टोर करने के लिए पूर्णांक सरणी थी)। साझा किए गए संदर्भों में समस्या यह है कि प्रत्येक बार मूल्यों की आवश्यकता होने पर इन संरचनाओं को संग्रहीत करना और पुनर्प्राप्त करना मुश्किल है।

मेरे मामले में मेरे पास पृष्ठभूमि सेवा थी इसलिए मैं इस चर को वहां ले जा सकता था और क्योंकि सेवा पर डेस्ट्रॉय ईवेंट था, मैं उन मानों को आसानी से सहेज सकता था।


यदि कुछ चर एसक्लाइट में संग्रहीत हैं और आपको अपने ऐप में अधिकांश गतिविधियों में उनका उपयोग करना होगा। तो आवेदन इसे प्राप्त करने का सबसे अच्छा तरीका हो सकता है। जब एप्लिकेशन प्रारंभ होता है और उन्हें फ़ील्ड में संग्रहीत करता है तो डेटाबेस से वेरिएबल क्वेरी करें। फिर आप अपनी गतिविधियों में इन चर का उपयोग कर सकते हैं।

तो सही रास्ता खोजें, और कोई अच्छा तरीका नहीं है।





state