समग्र "डेटासोर्स" ऑब्जेक्ट और एक कार्यात्मक दृष्टिकोण के तत्व

एक बार, मैंने (अच्छी तरह से, मुझे भी नहीं) एक निश्चित प्रकार की कोशिकाओं के साथ UICollectionView लिए एक पूरी तरह से अलग प्रकार की एक सेल को जोड़ने के कार्य का सामना करना पड़ा, और केवल एक विशेष मामले में ऐसा करने के लिए, जो "ऊपर" संसाधित होता है और सीधे UICollectionView पर निर्भर नहीं करता है। इस कार्य ने वृद्धि दी, अगर मेरी स्मृति मुझे बदसूरत के एक जोड़े को सेवा देती है, if - UICollectionViewDataSource और UICollectionViewDelegate अंदर ब्लॉक करता है, जो "उत्पादन" कोड में सुरक्षित रूप से बसे हैं और, शायद, वहां से कहीं भी नहीं जाएंगे।

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

मैं यह दिखाऊंगा कि मैंने UITableView उदाहरण के साथ क्या किया। यदि आप चाहें, तो UICollectionView के लिए समान कोड लिखना मुश्किल नहीं होना चाहिए।

"एक विचार हमेशा अपने अवतार से अधिक महत्वपूर्ण होता है"

यह कामोत्तेजना महान कॉमिक बुक के लेखक एलन मूर ( "कीपर्स" , "V का अर्थ वेंडेट्टा के लिए है , " "लीग ऑफ़ आउटस्टैंडिंग जेंटलमेन" ) से है, लेकिन यह वास्तव में प्रोग्रामिंग के बारे में नहीं है, है ना?

मेरे दृष्टिकोण का मुख्य विचार UITableViewDataSource ऑब्जेक्ट्स की एक सरणी को संग्रहीत करना है, उनके कुल अनुभागों को वापस करना और यह निर्धारित करने में सक्षम होना चाहिए कि मूल "डेटा स्रोत" ऑब्जेक्ट्स में से कौन सा एक्सेस इस कॉल को रीडायरेक्ट करेगा।

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

 protocol ComposableTableViewDataSource: UITableViewDataSource { var numberOfSections: Int { get } func numberOfRows(for section: Int) -> Int } 

और समग्र "डेटासोर्स" एक साधारण वर्ग निकला, जो UITableViewDataSource की आवश्यकताओं को कार्यान्वित करता है और इसे केवल एक तर्क के साथ आरंभ किया जाता है - ComposableTableViewDataSource के विशिष्ट उदाहरणों का एक सेट:

 final class ComposedTableViewDataSource: NSObject, UITableViewDataSource { private let dataSources: [ComposableTableViewDataSource] init(dataSources: ComposableTableViewDataSource...) { self.dataSources = dataSources super.init() } private override init() { fatalError("\(#file) \(#line): Initializer with parameters must be used.") } } 

अब यह केवल UITableViewDataSource प्रोटोकॉल के सभी तरीकों को इस तरह से लिखने के लिए बना हुआ है कि वे संबंधित घटकों के तरीकों का उल्लेख करते हैं।

“यह सही निर्णय था। मेरा फैसला

ये शब्द रूसी संघ के पहले अध्यक्ष बोरिस निकोलायेविच येल्तसिन के थे, और वास्तव में नीचे दिए गए पाठ का संदर्भ नहीं देते हैं, मुझे बस उन्हें पसंद आया।

सही निर्णय मुझे स्विफ्ट भाषा की कार्यक्षमता का उपयोग करने के लिए लग रहा था, और यह वास्तव में सुविधाजनक निकला।

सबसे पहले, हम एक विधि लागू करते हैं जो वर्गों की संख्या लौटाता है - यह मुश्किल नहीं है। जैसा कि ऊपर उल्लेख किया गया है, हमें घटकों के सभी वर्गों की कुल संख्या की आवश्यकता है:

 func numberOfSections(in tableView: UITableView) -> Int { // Default value if not implemented is "1". return dataSources.reduce(0) { $0 + ($1.numberOfSections?(in: tableView) ?? 1) } } 

(मैं मानक कार्यों के वाक्यविन्यास और अर्थ की व्याख्या नहीं करूँगा। यदि आवश्यक हो, तो इंटरनेट विषय पर अच्छे परिचयात्मक लेखों से भरा है। और मैं एक अच्छी पुस्तक की सिफारिश भी कर सकता हूं।)

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

सबसे पहले, सभी कार्यों को एक "जेनेरिक" फ़ंक्शन के लिए कम किया जा सकता है, जो एक विशिष्ट ComposableTableViewDataSource और अनुभाग संख्या या IndexPath के मूल्य के संदर्भ के रूप में लेता है। सुविधा और संक्षिप्तता के लिए, हम इन कार्यों के प्रकारों को छद्म शब्द प्रदान करते हैं। साथ ही, अतिरिक्त पठनीयता के लिए, मैं सुझाव देता हूं कि खंड संख्या के लिए एक उपनाम घोषित किया जाए:

 private typealias SectionNumber = Int private typealias AdducedSectionTask<T> = (_ composableDataSource: ComposableTableViewDataSource, _ sectionNumber: SectionNumber) -> T private typealias AdducedIndexPathTask<T> = (_ composableDataSource: ComposableTableViewDataSource, _ indexPath: IndexPath) -> T 

(मैं नीचे चयनित नामों की व्याख्या करूंगा।)

दूसरे, हम एक साधारण फ़ंक्शन को लागू करते हैं जो विशिष्ट ComposableTableViewDataSource और ComposableTableViewDataSource अनुभाग संख्या द्वारा संबंधित अनुभाग संख्या निर्धारित करता है:

 private func decompose(section: SectionNumber) -> (dataSource: ComposableTableViewDataSource, decomposedSection: SectionNumber) { var section = section var dataSourceIndex = 0 for (index, dataSource) in dataSources.enumerated() { let diff = section - dataSource.numberOfSections dataSourceIndex = index if diff < 0 { break } else { section = diff } } return (dataSources[dataSourceIndex], section) } 

शायद, यदि आप मेरे मुकाबले थोड़ा लंबा सोचते हैं, तो कार्यान्वयन अधिक सुरुचिपूर्ण और कम सीधा हो जाएगा। उदाहरण के लिए, मेरे सहयोगियों ने तुरंत सुझाव दिया कि मैं इस फ़ंक्शन में एक द्विआधारी खोज को लागू करता हूं (पहले, उदाहरण के लिए, आरंभीकरण के दौरान, वर्गों की संख्या के सूचकांक की रचना करके - पूर्णांक का एक सरल सरणी )। या अनुभाग संख्याओं के पत्राचार तालिका को संकलित करने और संग्रहीत करने में भी थोड़ा समय व्यतीत करें, लेकिन फिर O (n) या O (log n) की समय जटिलता के साथ विधि का उपयोग करने के बजाय, आप O (1) की लागत पर परिणाम प्राप्त कर सकते हैं। लेकिन मैंने स्पष्ट आवश्यकता और उचित माप के बिना समय से पहले अनुकूलन में संलग्न न होने के लिए महान डोनाल्ड नथ की सलाह लेने का फैसला किया। हां, और इस लेख के बारे में नहीं।

और अंत में, कार्य जो AdducedSectionTask और AdducedIndexPathTask स्वीकार करते हैं, ऊपर इंगित करते हैं और उन्हें विशिष्ट AdducedIndexPathTask उदाहरणों के लिए "रीडायरेक्ट" करते हैं:

 private func adduce<T>(_ section: SectionNumber, _ task: AdducedSectionTask<T>) -> T { let (dataSource, decomposedSection) = decompose(section: section) return task(dataSource, decomposedSection) } private func adduce<T>(_ indexPath: IndexPath, _ task: AdducedIndexPathTask<T>) -> T { let (dataSource, decomposedSection) = decompose(section: indexPath.section) return task(dataSource, IndexPath(row: indexPath.row, section: decomposedSection)) } 

और अब आप इन सभी कार्यों के लिए मेरे द्वारा चुने गए नामों की व्याख्या कर सकते हैं। यह सरल है: वे एक कार्यात्मक नामकरण शैली को दर्शाते हैं। यानी वास्तव में बहुत कम है, लेकिन प्रभावशाली ध्वनि।

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

ये सभी तैयारी और सहायक कार्यान्वयन में अविश्वसनीय रूप से लाभ देते हैं, वास्तव में, प्रोटोकॉल विधियों के। तालिका कॉन्फ़िगरेशन विधियाँ:

 func tableView(_ tableView: UITableView, titleForHeaderInSection section: Int) -> String? { return adduce(section) { $0.tableView?(tableView, titleForHeaderInSection: $1) } } func tableView(_ tableView: UITableView, titleForFooterInSection section: Int) -> String? { return adduce(section) { $0.tableView?(tableView, titleForFooterInSection: $1) } } func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int { return adduce(section) { $0.tableView(tableView, numberOfRowsInSection: $1) } } func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell { return adduce(indexPath) { $0.tableView(tableView, cellForRowAt: $1) } } 

पंक्तियाँ डालें और हटाएं:

 func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCell.EditingStyle, forRowAt indexPath: IndexPath) { return adduce(indexPath) { $0.tableView?(tableView, commit: editingStyle, forRowAt: $1) } } func tableView(_ tableView: UITableView, canEditRowAt indexPath: IndexPath) -> Bool { // Default if not implemented is "true". return adduce(indexPath) { $0.tableView?(tableView, canEditRowAt: $1) ?? true } } 

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

"असंभव आज कल संभव होगा"

ये रूसी वैज्ञानिक कोन्स्टेंटिन एडुआर्डोविच त्सिकोलोवस्की के शब्द हैं, जो सैद्धांतिक कॉस्मोनॉटिक्स के संस्थापक हैं।

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

दूसरे, और अधिक महत्वपूर्ण बात, स्क्रीन पर डेटा अपडेट करने के लिए तंत्र पर सोचना आवश्यक है। मुझे लगता है कि यह ComposableTableViewDataSource प्रतिनिधि के प्रोटोकॉल को घोषित करके कार्यान्वित किया जा सकता है, जिनमें से तरीके ComposableTableViewDataSource द्वारा लागू किए जाएंगे और एक संकेत प्राप्त होगा कि मूल "डेटा स्रोत" को एक अद्यतन प्राप्त हुआ है। दो प्रश्न खुले रहते हैं: यह कैसे निर्धारित किया ComposableTableViewDataSource कि कौन सा ComposableTableViewDataSource अंदर बदल गया है और यह कैसे एक अलग और सबसे तुच्छ कार्य है, लेकिन कई समाधान हैं (उदाहरण के लिए, ऐसे )। और, ज़ाहिर है, आपको ComposedTableViewDataSource प्रतिनिधि ComposedTableViewDataSource आवश्यकता होगी, जिनमें से तरीकों को समग्र "डेटा स्रोत" को अपडेट करते समय और क्लाइंट प्रकार (उदाहरण के लिए, एक नियंत्रक या दृश्य मॉडल ) द्वारा कार्यान्वित किया जाएगा।

मैं समय के साथ इन मुद्दों की बेहतर जांच करने और उन्हें लेख के दूसरे भाग में शामिल करने की उम्मीद करता हूं। इस बीच, मैं खुश हूँ, आप इन प्रयोगों के बारे में पढ़ने के लिए उत्सुक थे!

पुनश्च

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

संदर्भ:
- पूर्ण कोड और उदाहरण के साथ Playgroud
- मेरा ट्विटर