क्या आप कोर डेटा स्टैक को सही ढंग से आरंभीकृत करते हैं?

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

यह मेरे लिए अजीब लगता है कि यह त्रुटि अक्सर होती है (और "गंभीर" परियोजनाओं में होनी चाहिए), लेकिन किसी कारण से वे इसके बारे में चुप हैं।
यह आलेख iOS अनुप्रयोगों में CoreData स्टैक को प्रारंभ करते समय एक मानक त्रुटि पर चर्चा करेगा।

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

मुझे तुरंत यह कहना होगा कि किसी त्रुटि का सामना करने के लिए, आपको तीन कारणों को इकट्ठा करने की आवश्यकता है: डेटाबेस की एक बड़ी मात्रा, मुख्य धागे में कोरडेटा स्टैक का इनिशियलाइज़ेशन, आपके प्रोग्राम के नए संस्करण में डेटाबेस स्कीमा में परिवर्तन। आइए देखें कि एक डेवलपर के रूप में उन सभी को कितनी आसानी से इकट्ठा किया जा सकता है।

कारण # 1। बड़े डेटाबेस फ़ाइल का आकार

जब "पूर्ण" का उपयोग किया जाता है, तो अक्सर ऐसा होता है कि आधार का आकार कृत्रिम रूप से कुछ भी असीमित है और आसानी से गीगाबाइट पर कब्जा कर सकता है।

उत्तरार्द्ध के उदाहरणों के लिए, आपको लंबे समय तक जाने की आवश्यकता नहीं है। इंटरनेट पर, लोग अभी भी सोच रहे हैं कि क्या चित्रों को डेटाबेस में संग्रहीत किया जा सकता है (वैसे, इस लेख में, कोरडाटा और डेटाबेस लगभग समानार्थी होंगे)। Stackoverflow दर्शकों की मंजूरी है कि काफी लोकप्रिय जवाब है कि आप सुरक्षित रूप से एक मेगाबाइट तक एक तस्वीर के लिए एक डेटाबेस में इसे स्टोर कर सकते हैं सुझाव है। उदाहरण के लिए, यहां stackoverflow.com/questions/2573072/coredata-store-images-to-db-or-not

जवाब इस तरह दिखता है:

<100kb संबंधित डेटा के रूप में एक ही तालिका में संग्रहीत करता है
अनावश्यक रूप से लोडिंग से बचने के लिए एक संबंध के माध्यम से जुड़ी एक अलग तालिका में <1mb स्टोर
> डिस्क पर 1mb स्टोर करें और इसे कोर डेटा के अंदर देखें

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

कारण संख्या 2। मुख्य सूत्र में प्रारंभिक

खैर, क्या वास्तव में संदेह हो सकता है? मुझे लगता है कि लगभग 100% नवागंतुक और बिल्कुल 70% डेवलपर्स मुख्य कार्यक्रम प्रवाह में पूरे कोरडेटा स्टैक को शुरू करने की अधिक संभावना रखते हैं।

कारण संख्या 3। एक नए डेटा स्कीमा में माइग्रेट करने की आवश्यकता है

आमतौर पर डेटाबेस स्कीमा (मॉडल) को बदलते समय, यदि आप उचित नियम निर्धारित करते हैं, तो कोरडेटा पुराने डेटाबेस से डेटा को नए में स्थानांतरित करता है। सबसे सरल तथाकथित लाइटवेट माइग्रेशन आसान है, आपको स्टोरेज को NSPersistentStoreCoordinator से कनेक्ट करते समय विकल्प शब्दकोश को पास करना होगा:

NSDictionary *optionsDictionary = [NSDictionary dictionaryWithObjectsAndKeys:[NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption, [NSNumber numberWithBool:YES], NSInferMappingModelAutomaticallyOption, nil]; [_persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType configuration:nil URL:storeUrl options:optionsDictionary error:&error]; 

यदि स्थानांतरण हल्के प्रवास के ढांचे में फिट नहीं होता है, तो डेवलपर्स को उनके कस्टम का एहसास होगा, लेकिन कारण संख्या 3 का सार नहीं बदलता है।

कारण एकत्र किए गए

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

, !

203 203


क्या चल रहा है?

मुझे लगता है कि ये सभी कारण आपको एक सरल निष्कर्ष पर ले जाते हैं। और वह वफादार है! यहां तक ​​कि डेटाबेस के एक नए संस्करण में बस माइग्रेशन डेटा की प्रतिलिपि बनाने में समय लगता है, और डेटाबेस फ़ाइल को जितना लंबा समय लगता है, उतना ही अधिक समय लगता है। और हम सरल नकल के बारे में बात कर रहे हैं, और यदि आपको उदाहरण के लिए, खेतों को फिर से जोड़ने की आवश्यकता है?

अड़चन का पहले ही उल्लेख किया जा चुका है - यह NSPersistentStoreCoordinator ऑब्जेक्ट में लगातार स्टोरेज का कनेक्शन है। यह वह जगह है जहाँ कारण एक साथ एक समस्या पैदा करते हैं। और यदि आपका एप्लिकेशन 30 सेकंड के लिए प्रतिक्रिया नहीं देता है, तो सिस्टम इसे बंद कर देता है।

निर्णय

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

यहां बताया गया है कि यह कोड में कैसे दिखेगा (मैं तुरंत कहता हूं कि समाधान सही होने का दावा नहीं करता है, अगर कोई बेहतर समझता है, तो टिप्पणियों में लिखें)।

 //     GUI    - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { self.launchOptions = launchOptions; [self performSelectorInBackground:@selector(initCoreData) withObject:nil]; [NSThread sleepForTimeInterval:0.2]; // ,       ,    .        [self initialDisplayGUI]; return YES; } - (void)initialDisplayGUI { if (self.dataIsReady) { [self diplayAllGUIStuff]; } else { self.dataPrepareController = [[MigrationProgressViewController alloc] init]; [dataPrepareController setDoneTarget:self withAction:@selector(diplayAllGUIStuff)]; dataPrepareController.view.frame = window.frame; [window addSubview:dataPrepareController.view]; [window makeKeyAndVisible]; } } - (void)initCoreData { NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; if (self.persistentStoreCoordinator) { NSLog(@"Storage was added"); } self.dataIsReady = YES; [pool release]; } - (void)setDataIsReady:(BOOL)dataIsReady { if (_dataIsReady != dataIsReady) { _dataIsReady = dataIsReady; [self performSelectorOnMainThread:@selector(diplayAllGUIStuff) withObject:nil waitUntilDone:NO]; } } 

-diplayAllGUIStuff में एक विधि है जिसमें आपके पास कोड है - (BOOL) अनुप्रयोग: didFinishLaunchingWithOptions:

MigrationProgressViewController को प्रदर्शित करने की आवश्यकता है, उदाहरण के लिए, शेष समय के संकेतक, या कम से कम यह दिखाते हैं कि प्रक्रिया लटका नहीं है। इसका एकमात्र कार्य उपयोगकर्ता को आश्वस्त करना है। उपयोगकर्ताओं के लिए "स्क्रीन पर सेवर करने की तुलना में" नंगे "UIActivityIndicatorView पर भी देखना अधिक सुखद है, और इससे भी अधिक उनके हाथों पर एक दुर्घटनाग्रस्त एप्लिकेशन है।

शायद यही सब है। ऐसे संयोग से बचें और अक्सर कोड की समीक्षा करें, विशेष रूप से वह जो आपके लिए एक्सकोड डाला गया है।