ASP.NET MVC 4 मोबाइल फीचर्स दिखाई दे रहे तेजी से घटते हैं

ASP.NET MVC 4 में मोबाइल फीचर्स क्या है

ASP.NET MVC 4 एक बहुत ही प्रत्याशित और लंबे समय से प्रतीक्षित नई सुविधा के साथ सामने आया - अंग्रेजी कॉल मोबाइल फीचर्स - मोबाइल उपकरणों के लिए समर्थन। द्वारा और बड़े नाम ने तुरंत आश्चर्यचकित कर दिया, क्योंकि यह नवाचार के तकनीकी विवरण से थोड़ा भिन्न है। लेकिन पदोन्नति - पदोन्नति है। HTML 5 के समर्थन के साथ पेज टेम्प्लेट (लेआउट) के सभी संदर्भ, व्यूपोर्ट, सीएसएस मीडिया निर्दिष्ट करते हुए - इन सभी का MVC फ्रेमवर्क से कोई लेना-देना नहीं है।

केवल दो बिंदुओं को ही ढांचे की नई विशेषता के लिए जिम्मेदार ठहराया जा सकता है:

• मोबाइल ब्राउज़रों के लिए विशिष्ट दृश्य और टेम्पलेट्स का निर्माण
• फ्लाई पर बदलने की क्षमता जो दृश्य को उपयोगकर्ता को प्रदान की जाएगी - अर्थात्, अलग-अलग दृश्य के बीच रनटाइम में स्विच करें

और यहां यह तुरंत ध्यान देने योग्य है कि "मोबाइल" शब्द पूरी तरह से विज्ञापन के उद्देश्यों के लिए उल्लिखित है। MVC 4 आपको आवश्यक पृष्ठों में से प्रत्येक के लिए कई दृश्य बनाने और यह निर्धारित करने की अनुमति देता है कि उनमें से प्रत्येक को किस ब्राउज़र में प्रदर्शित किया जाना चाहिए। यही है, संभावनाएं मोबाइल ब्राउज़र तक सीमित नहीं हैं।

सरल सब कुछ सरल है - ViewEngine में एक "हुक"

इस सुविधा का कार्यान्वयन बहुत सरल है। यह ViewEngine में सिर्फ एक "हुक" है।

आप विभिन्न उपकरणों या ब्राउज़रों के लिए अलग-अलग पृष्ठ (दृश्य) बनाते हैं। कीवर्ड जोड़कर फ़ाइलों को नाम दें:

• Catalog.cshtml
• Catalog.iPhone.cshtml

उन मापदंडों को निर्दिष्ट करें जिनके द्वारा वांछित दृश्य का चयन किया जाएगा - DisplayModeProvider का उपयोग करके, वांछित नाम के साथ वांछित DefaultDisplayMode निर्दिष्ट करें।

DisplayModeProvider.Instance.Modes.Insert(0, new DefaultDisplayMode("iPhone") { ContextCondition = (context => context.GetOverriddenUserAgent().IndexOf ("iPhone", StringComparison.OrdinalIgnoreCase) >= 0) }); 

रनटाइम में, जब नियंत्रक विधि काम करती है, तो तैयार किया गया ViewResult View Engine में पारित हो जाता है, DisplayModeProvider की स्थितियों की जाँच की जाती है, यह दृश्य फ़ाइल का नाम बदलता है जिसे लोड करने की आवश्यकता होती है।

क्या हम वास्तव में इसका उपयोग कर सकते हैं?

बेशक हम कर सकते हैं। लेकिन केवल बहुत ही सरल मामलों में। मुख्य नुकसान यह है कि पृष्ठ के लिए आपके द्वारा किए गए सभी दृश्य एक ही नियंत्रक विधि द्वारा संसाधित होते हैं। जल्दी या बाद में, यह एक समस्या बन जाती है।

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

पहली नज़र में स्मार्टफोन और टैबलेट दोनों के लिए समर्थन इतना जटिल नहीं दिखता है - स्क्रीन आकार में अंतर। लेकिन एक बड़े क्षेत्र में, आप अधिक जानकारी या अधिक कस्टम फ़ंक्शन रख सकते हैं, न कि केवल चित्रों का आकार बढ़ा सकते हैं।

टीवी सपोर्ट एक बहुत ही सरल काम है। फुल एचडी का मतलब पिक्सल में एक ही स्क्रीन साइज से है। लेकिन प्लसस वहीं खत्म हो जाते हैं।

यह पता चला है कि यदि आपकी साइट को टीवी से खोला गया था, तो इसे ब्राउज़र में खोला जा सकता है:

• फिलिप्स स्मार्ट टीवी - नेटटीवी एसडीके - सीई-एचटीएमएल वेबसाइट
• सैमसंग स्मार्ट टीवी - सैमसंग का अपना एसडीके है, संभावनाएं नेटटीवी से बहुत अलग हैं
• एलजी स्मार्ट टीवी
• XBOX 360 के साथ - इंटरनेट एक्सप्लोरर
• प्लेस्टेशन 3 से
• Wii से
• Google टीवी, सोनी टीवी के साथ एकीकृत Google टीवी
• Apple टीवी के साथ
• Boxee बॉक्स, Kylo ब्राउज़र, Roku और अन्य

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

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

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

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

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

बदले में क्या पेश किया जा सकता है?

यह स्पष्ट है कि सबसे सरल बात तुरंत विभिन्न उपकरणों के लिए अलग-अलग साइटें बनाना है और सही पर पुनर्निर्देशित करना है। हम ऐसे समाधान को बहुत सरल मानते हैं। आप किसी भी समय इस विकल्प पर वापस आ सकते हैं।

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

ASP.NET MVC 4 की वास्तुकला को देखते हुए, केवल एक उपयुक्त विकल्प है। MVC एप्लिकेशन (प्रोजेक्ट) के अंदर, साइट के प्रत्येक विकल्प को अपने क्षेत्र में निष्पादित किया जाना चाहिए। उपयोगकर्ता एजेंट स्ट्रिंग द्वारा हम यह निर्धारित कर सकते हैं कि किस डिवाइस / ब्राउज़र से अनुरोध प्राप्त हुआ है और इसे वांछित क्षेत्र में भेजें।

वांछित क्षेत्र में स्थानांतरित करने के लिए, आपको रूटिंग तालिका में प्रत्येक मार्ग (रूट) के लिए एक बाधा (बाधा) जोड़ने की आवश्यकता है।

इस दृष्टिकोण का नुकसान यह है कि आपको सभी मार्गों पर इस तरह के प्रतिबंध को जोड़ना नहीं भूलना चाहिए।

उदाहरण के लिए, यदि हमने Chrome ब्राउज़र के साथ सभी को पुनर्निर्देशित करने के लिए एक क्षेत्र बनाया है, तो क्षेत्र पंजीकरण इस तरह दिखेगा:

  public class ChromeAreaRegistration : AreaRegistration { public override string AreaName { get { return "Chrome"; } } public override void RegisterArea(AreaRegistrationContext context) { context.MapRoute( "Chrome_default", "{controller}/{action}/{id}", new { controller = "Home", action = "Index", id = UrlParameter.Optional }, new { isChromeBrowser = new IsChromeConstraint() } ); } } 

इस मामले में, प्रतिबंध इस तरह दिखेगा:

  public class IsChromeConstraint : IRouteConstraint { public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection) { string userAgent = httpContext.Request.UserAgent; if (string.IsNullOrWhiteSpace(userAgent)) { return false; } return userAgent.Contains("Chrome"); } } 

उसी समय, हमारे पास मुख्य क्षेत्र है, जहां क्रोम को छोड़कर अन्य सभी ब्राउज़रों को जाना चाहिए।

  public class DesktopAreaRegistration : AreaRegistration { public override string AreaName { get { return "Desktop"; } } public override void RegisterArea(AreaRegistrationContext context) { context.MapRoute( "Desktop_default", "{controller}/{action}/{id}", new { controller = "Home", action = "Index", id = UrlParameter.Optional }, new { isNotChromeBrowser = new IsNotChromeConstraint() } ); } } 

इसमें हमें एक प्रतिबंध का भी उपयोग करना चाहिए जो Chrome को काटने वाले ब्राउज़र को फ़िल्टर करता है:

  public class IsNotChromeConstraint : IRouteConstraint { public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection) { string userAgent = httpContext.Request.UserAgent; if (string.IsNullOrWhiteSpace(userAgent)) { return false; } return !userAgent.Contains("Chrome"); } } 

सभी क्षेत्रों में सभी मार्गों के लिए प्रतिबंध लगाना आवश्यक है, इस तथ्य के बावजूद कि रनटाइम में मार्गों को ऊपर से नीचे तक देखा जाता है। तथ्य यह है कि स्टार्टअप पर एरियाराइजेशन को पंजीकृत करने की प्रक्रिया यादृच्छिक है। यह स्पष्ट रूप से उनके आदेश का संकेत देकर - सभी क्षेत्रों के मार्गों को एक जगह - Global.asax में पंजीकृत करने से बचा जा सकता है। फिर आप गारंटी दे सकते हैं कि क्रोम ब्राउज़र की जांच हमेशा पहले होगी।

उपसंहार

यदि आप इससे थक जाते हैं, तो आप हमेशा प्रत्येक क्षेत्र को एक अलग एप्लिकेशन में स्थानांतरित कर सकते हैं और विभिन्न डोमेन पर होस्ट कर सकते हैं।