स्मार्ट संगीत रेडियो जिसमें एक स्थायी इंटरनेट कनेक्शन की आवश्यकता नहीं होती है

काम करने और चलने के दौरान, मैं अक्सर पृष्ठभूमि संगीत सुनता हूं। मैंने जांगो नामक एक इंटरनेट रेडियो का उपयोग किया है, जो निम्नलिखित बातों को छोड़कर लगभग सभी को अनुकूल करता है:

• जंगल में लगभग दैनिक चलने के दौरान (यानी इंटरनेट कनेक्शन के बिना)।
• संगीत की शैली को बदलने के लिए विभिन्न चैनलों के बीच स्विच करने की आवश्यकता है। दूसरे शब्दों में, जांगो के श्रोता के पास नई संगीत शैलियों की खोज करने की बहुत कम संभावना है।

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

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

पटरियों के बारे में मेटाडेटा, साथ ही उपयोगकर्ता वरीयताओं को संग्रहीत करने के लिए, मैंने SQLite को चुना। एल्बम और संगीत कवर फाइलें तीन-स्तरीय हैश-आधारित डायरेक्टरी ट्री (Git में कैसे काम करती हैं) के समान संग्रहित हैं।

512 MiB ने कैश आकार को चुना (ये और कोई भी अंक, निश्चित रूप से कॉन्फ़िगर किया जा सकता है)। पटरियों के रोटेशन का तर्क निम्नानुसार है: 20 ट्रैक प्रति अपडेट पुनरावृत्ति डाउनलोड किए जाते हैं। उपयोगकर्ता द्वारा प्रत्येक ट्रैक को कम से कम दो बार सुनने के बाद, एक नया अपडेट शुरू किया जाता है। ट्रैक हटा दिए जाते हैं जिसके लिए औसत सुनने का समय निर्दिष्ट सीमा से कम है, और नए ट्रैक्स का मेटाडेटा सर्वर से डाउनलोड किया जाता है, जिसके बाद डाउनलोडिंग शुरू होती है।

पार्श्व तर्क इस प्रकार है। एक ट्रैक के लिए औसत सुनने का समय जितना अधिक होता है, उतनी बार खेला जाता है।

एक अनुभवी C ++ डेवलपर होने के नाते, मैंने ऊपर वर्णित तर्क को लागू करने में कोई विशेष कठिनाइयों का अनुभव नहीं किया (हालांकि वास्तव में यह कुछ अधिक जटिल है)। हालाँकि, एंड्रॉइड के लिए एप्लिकेशन लिखने का कोई अनुभव नहीं होने के कारण, मुझे उपयुक्त सॉफ़्टवेयर लेयर (विशेषकर UI) को लागू करने के लिए बहुत समय और प्रयास करना पड़ा। मुझे यकीन है कि कई चीजें अब सबसे अच्छे तरीके से लागू नहीं होती हैं।

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

मैंने JSON मेटाडेटा डाउनलोड करने के लिए ईंधन का उपयोग किया, और फ़ाइलों को डाउनलोड करने के लिए Fetch (मुझे आश्चर्य था कि ईंधन कुशलतापूर्वक फ़ाइलों को डाउनलोड करने में सक्षम नहीं है)। वैसे, दूसरे पुस्तकालय में मुझे काम की स्थिरता के बारे में शिकायतें हैं।

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

सर्वर प्रत्येक उपयोगकर्ता के लिए पटरियों को सुनने के आंकड़े एकत्र करता है। इस प्रकार, प्रत्येक संगीत शैली को एक वरीयता स्कोर दिया जाता है जो रोटेशन के दौरान उपयुक्त रचनाओं को चुनने की संभावना को प्रभावित करता है।

यदि आप मेरे आवेदन का प्रयास करेंगे तो मुझे खुशी होगी। अचानक आप इसे पसंद करेंगे। निश्चित रूप से उपयोग के दौरान, आप बगों का सामना करेंगे (कार्यक्रम अभी भी कच्चा है)। उनके सुधार की गति सीधे मेरे काम की मांग पर निर्भर करेगी।