2012-03-20 17 views
7

मेरे पास एक गतिविधि है जो दो लोडर का उपयोग करती है। उनमें से प्रत्येक अलग-अलग प्रकार का डेटा देता है। एक लोडर से डेटा प्राप्त करने के लिए केवल एक गतिविधि में LoaderCallbacks<D> लागू करता है। मुझे लगता है कि मैं सिर्फ LoaderCallbacks<Object> को कार्यान्वित कर सकता हूं और ऑब्जेक्ट के प्रकार की जांच कर सकता हूं और फिर यह तय कर सकता हूं कि इनमें से कौन सा लोडर कॉलबैक है, लेकिन यह मेरे लिए हैक की तरह लगता है (ज्यादातर यहां प्रकार की सुरक्षा की कमी के कारण)।एक स्थिर आंतरिक वर्ग के रूप में लोडर कॉलबैक (विभिन्न डेटा प्रकारों के साथ एकाधिक लोडर को संभालने के लिए)

इसलिए मैं बनाने के बारे में सोचा LoaderCallbacks इस तरह एक स्थिर भीतरी वर्ग, कुछ आपत्ति:

private static class geocoderLoaderCallbacks implements LoaderCallbacks<List<Address>>{ 

    @Override 
    public Loader<List<Address>> onCreateLoader(int arg0, Bundle arg1) { 
     GeocoderTask loader = new GeocoderTask(context, ""); 
     return loader; 
    } 

    @Override 
    public void onLoadFinished(Loader<List<Address>> loader, List<Address> data) { 
     // TODO Auto-generated method stub 

    } 

    @Override 
    public void onLoaderReset(Loader<List<Address>> loader) { 
     // TODO Auto-generated method stub 

    } 


} 

और फिर lm.initLoader(0, null, geocoderLoaderCallbacks) का उपयोग कर।

दो सवाल उठते हैं: क्या यह ठीक है, या क्या मुझे लोडर कॉलबैक को गतिविधि में लागू करने के लिए चिपकना चाहिए? और मैं संदर्भ को सुरक्षित रूप से ऑनक्रेट लोडर में कैसे पास करूं? क्या मुझे सिर्फ geocoderLoaderCallbacks में एक कन्स्ट्रक्टर बनाना चाहिए और इस lm.initLoader(0, null, geocoderLoaderCallbacks(this)) जैसे संदर्भ को पास करना चाहिए?

यहां एक समान प्रश्न है LoaderManager with multiple loaders: how to get the right cursorloader लेकिन यह समझाता नहीं है कि विभिन्न डेटा प्रकारों के साथ दो लोडर का प्रबंधन कैसे करें।

उत्तर

9

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

कन्स्ट्रक्टर में Context पास करना ठीक है जब तक आप स्थिर या अन्यथा कैश किए गए संदर्भ नहीं रखते हैं।

+1

मुझे यकीन नहीं है कि मैं "स्थिर या अन्यथा कैश किए गए संदर्भ रखता हूं"। संदर्भ की आवश्यकता है क्योंकि AsyncTaskLoader को एक की आवश्यकता है। तो मुझे इसे geocoderLoaderCallbacks में पास करना होगा। लेकिन क्या मुझे इसे अपनी गतिविधि में तुरंत चालू करना चाहिए और इस विशेष गतिविधि के संदर्भ में जाना चाहिए? क्या यह गतिविधि को रिसाव नहीं करेगा? सभी उदाहरण कार्यान्वयन (जहां गतिविधि लोडर कॉलबैक लागू करती है) में वे गतिविधि के संदर्भ को पास करने के लिए 'lm.initLoader (0, null, this); '(' this') का उपयोग करते हैं। फिर यह स्वचालित रूप से AsyncTaskLoader द्वारा संभालता है। लेकिन क्या यह स्थिर आंतरिक वर्ग के साथ भी काम करता है? –

+1

यह एक अलग वर्ग में और 'संदर्भ' को पारित करने से लीक के संबंध में सुरक्षित है क्योंकि आप लोडर कॉलबैक कक्षा का जीवनकाल गतिविधि के जीवनकाल से बंधे हैं। एक बार जब गतिविधि कचरा इकट्ठा हो जाती है तो वहां से बाहर जाने वाले सभी संदर्भ भी होंगे। केवल एक चीज जो आपको नहीं करना चाहिए वह 'स्थिर' चर का उपयोग करना है जिसमें आपकी गतिविधि के किसी प्रकार का संदर्भ है। यदि आप केवल प्रदान की गई कक्षाओं का इरादा रखते हैं तो आपको आम तौर पर लीक के साथ समस्या नहीं होगी। – zapl

+0

ग्रेट, धन्यवाद! और गतिविधि –

संबंधित मुद्दे