क्रॉस-डिवाइस वेबऐप्लिकेशन बनाने का ऐसा तरीका जो रिस्पॉन्सिव नहीं है

Boris Smus

मीडिया क्वेरी बहुत अच्छी हैं, लेकिन…

मीडिया क्वेरी बहुत अच्छी हैं. ये वेबसाइट डेवलपर के लिए वरदान हैं. वे अपनी स्टाइलशीट में छोटे बदलाव करके, अलग-अलग साइज़ के डिवाइसों पर उपयोगकर्ताओं को बेहतर अनुभव दे सकते हैं. मीडिया क्वेरी की मदद से, स्क्रीन साइज़ के हिसाब से अपनी साइट की सीएसएस को पसंद के मुताबिक बनाया जा सकता है. इस लेख को पढ़ने से पहले, रिस्पॉन्सिव डिज़ाइन के बारे में ज़्यादा जानें. साथ ही, मीडिया क्वेरी के इस्तेमाल के कुछ बेहतरीन उदाहरण यहां देखें: mediaqueri.es.

जैसा कि ब्रैड फ़्रॉस्ट ने पिछले लेख में बताया है, मोबाइल वेब के लिए वेबसाइट बनाते समय, डिज़ाइन में बदलाव करना सिर्फ़ एक चीज़ है. अगर मोबाइल वेबसाइट बनाते समय, आपने सिर्फ़ मीडिया क्वेरी की मदद से अपने लेआउट को पसंद के मुताबिक बनाया है, तो यहां दी गई स्थिति लागू होगी:

• सभी डिवाइसों पर एक ही JavaScript, CSS, और एसेट (इमेज, वीडियो) मिलती हैं. इससे, पेज लोड होने में ज़रूरत से ज़्यादा समय लगता है.
• सभी डिवाइसों को एक ही शुरुआती डीओएम मिलता है. इस वजह से, डेवलपर को ज़्यादा जटिल सीएसएस लिखनी पड़ सकती है.
• हर डिवाइस के हिसाब से कस्टम इंटरैक्शन तय करने में ज़्यादा सुविधा नहीं मिलती.

वेबऐप्लिकेशन को मीडिया क्वेरी के अलावा और भी चीज़ों की ज़रूरत होती है

मुझे गलत मत समझें. मुझे मीडिया क्वेरी की मदद से रिस्पॉन्सिव डिज़ाइन पसंद है. साथ ही, मुझे लगता है कि इसकी दुनिया में जगह है. इसके अलावा, ऊपर बताई गई कुछ समस्याओं को रिस्पॉन्सिव इमेज, डाइनैमिक स्क्रिप्ट लोडिंग वगैरह जैसे तरीकों से हल किया जा सकता है. हालांकि, किसी समय पर आपको लग सकता है कि आपने बहुत ज़्यादा बदलाव किए हैं. ऐसे में, अलग-अलग वर्शन दिखाना बेहतर हो सकता है.

जैसे-जैसे आपके बनाए गए यूज़र इंटरफ़ेस (यूआई) ज़्यादा जटिल होते जाते हैं और आप एक पेज वाले वेबऐप्लिकेशन की ओर बढ़ते जाते हैं, आपको हर तरह के डिवाइस के लिए यूआई को ज़्यादा कस्टमाइज़ करना होगा. इस लेख में, आपको कम से कम मेहनत के साथ ये बदलाव करने का तरीका बताया जाएगा. आम तौर पर, वेबसाइट पर आने वाले व्यक्ति के डिवाइस को सही डिवाइस क्लास में बांटा जाता है. साथ ही, उस डिवाइस के लिए सही वर्शन दिखाया जाता है. ऐसा करते समय, वर्शन के बीच कोड का रीयूज ज़्यादा से ज़्यादा किया जाता है.

आपको किन डिवाइस क्लास को टारगेट करना है?

इंटरनेट से कनेक्ट किए गए बहुत से डिवाइस हैं और उनमें से ज़्यादातर में ब्राउज़र होते हैं. समस्या इनकी अलग-अलग सुविधाओं में है: Mac लैपटॉप, Windows वर्कस्टेशन, iPhones, iPads, टच इनपुट वाले Android फ़ोन, स्क्रोल व्हील, कीबोर्ड, वॉइस इनपुट, दबाव से काम करने वाले डिवाइस, स्मार्ट वॉच, टोस्टर, और रेफ़्रिजरेटर वगैरह. इनमें से कुछ डिवाइस हर जगह मौजूद होते हैं, जबकि कुछ बहुत कम होते हैं.

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

इस स्पेक्ट्रम के दो चरम छोर हैं:

1. एक ऐसा वर्शन बनाएं जो सभी डिवाइसों पर काम करे. इससे यूज़र एक्सपीरियंस पर असर पड़ेगा, क्योंकि अलग-अलग डिवाइसों के लिए डिज़ाइन में अलग-अलग बातों का ध्यान रखना पड़ता है.

2. हर उस डिवाइस के लिए एक वर्शन बनाएं जिस पर आपको ऐप्लिकेशन उपलब्ध कराना है. इसमें काफ़ी समय लगेगा, क्योंकि आपको अपने ऐप्लिकेशन के कई वर्शन बनाने होंगे. साथ ही, जब अगला नया स्मार्टफ़ोन आएगा (जो हर हफ़्ते होता है), तो आपको एक और वर्शन बनाना होगा.

यहां एक बुनियादी समझौता है: आपके पास डिवाइस की जितनी ज़्यादा कैटगरी होंगी, उतना ही बेहतर उपयोगकर्ता अनुभव दिया जा सकता है. हालांकि, डिवाइस की कैटगरी को डिज़ाइन करने, लागू करने, और उसे मैनेज करने में ज़्यादा काम करना पड़ेगा.

परफ़ॉर्मेंस की वजह से, हर डिवाइस कैटगरी के लिए अलग वर्शन बनाना एक अच्छा आइडिया हो सकता है. ऐसा तब भी किया जा सकता है, जब आपको अलग-अलग डिवाइस कैटगरी के लिए अलग-अलग वर्शन दिखाने हों. इसके अलावा, रिस्पॉन्सिव वेब डिज़ाइन का इस्तेमाल करना एक सही तरीका है.

समस्या का संभावित समाधान

यहां एक समझौता किया जा सकता है: डिवाइसों को कैटगरी में बांटें और हर कैटगरी के लिए सबसे अच्छा अनुभव डिज़ाइन करें. आपको कौनसी कैटगरी चुननी हैं, यह आपके प्रॉडक्ट और टारगेट किए गए उपयोगकर्ता पर निर्भर करता है. यहां डिवाइसों के कैटगरी के बंटवारे का एक सैंपल दिया गया है. इसमें, वेब पर काम करने वाले मौजूदा लोकप्रिय डिवाइसों के बारे में बताया गया है.

1. छोटी स्क्रीन + टच (ज़्यादातर फ़ोन)
2. बड़ी स्क्रीन + टच (ज़्यादातर टैबलेट)
3. बड़ी स्क्रीन + कीबोर्ड/माउस (ज़्यादातर डेस्कटॉप/लैपटॉप)

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

फ़ॉर्म फ़ैक्टर के हिसाब से बनाए गए वेब ऐप्लिकेशन के उदाहरण

अलग-अलग फ़ॉर्म फ़ैक्टर के लिए, पूरी तरह से अलग-अलग वर्शन दिखाने वाली वेब प्रॉपर्टी के कई उदाहरण हैं. Google Search और Facebook, दोनों ऐसा करते हैं. इसके लिए, परफ़ॉर्मेंस (ऐसेट फ़ेच करना, पेज रेंडर करना) और सामान्य उपयोगकर्ता अनुभव, दोनों को ध्यान में रखा जाता है.

नेटिव ऐप्लिकेशन की दुनिया में, कई डेवलपर अपने ऐप्लिकेशन को किसी डिवाइस क्लास के हिसाब से बनाते हैं. उदाहरण के लिए, iPad के लिए Flipboard का यूज़र इंटरफ़ेस (यूआई), iPhone के लिए Flipboard के यूज़र इंटरफ़ेस से काफ़ी अलग है. टैबलेट के वर्शन को दो हाथों से इस्तेमाल करने और हॉरिज़ॉन्टल फ़्लिप करने के लिए ऑप्टिमाइज़ किया गया है. वहीं, फ़ोन के वर्शन को एक हाथ से इंटरैक्ट करने और वर्टिकल फ़्लिप करने के लिए ऑप्टिमाइज़ किया गया है. iOS के कई अन्य ऐप्लिकेशन भी फ़ोन और टैबलेट के लिए, काफ़ी अलग-अलग वर्शन उपलब्ध कराते हैं. जैसे, Things (टू-डू लिस्ट) और Showyou (सोशल वीडियो). इन ऐप्लिकेशन के वर्शन के बारे में यहां बताया गया है:

पहला तरीका: सर्वर-साइड पर पहचान करना

सर्वर पर, हमारे पास उस डिवाइस के बारे में काफ़ी सीमित जानकारी होती है जिससे हम काम कर रहे हैं. उपयोगकर्ता एजेंट स्ट्रिंग, सबसे ज़्यादा काम की जानकारी है. यह हर अनुरोध पर User-Agent हेडर के ज़रिए दी जाती है. इस वजह से, UA को स्निफ करने का वही तरीका यहां काम करेगा. असल में, DeviceAtlas और WURFL प्रोजेक्ट पहले से ही ऐसा करते हैं. साथ ही, वे डिवाइस के बारे में काफ़ी ज़्यादा जानकारी देते हैं.

माफ़ करें, इनमें से हर एक में अलग-अलग समस्याएं आती हैं. WURFL का साइज़ बहुत बड़ा है. इसमें 20 एमबी का एक्सएमएल होता है. इस वजह से, हर अनुरोध के लिए सर्वर साइड पर ज़्यादा खर्च हो सकता है. कुछ प्रोजेक्ट में, परफ़ॉर्मेंस को बेहतर बनाने के लिए, एक्सएमएल को अलग-अलग हिस्सों में बांटा जाता है. DeviceAtlas, ओपन सोर्स नहीं है. इसका इस्तेमाल करने के लिए, पैसे चुकाकर लाइसेंस लेना ज़रूरी है.

इसके अलावा, Detect Mobile browsers प्रोजेक्ट जैसे आसान और मुफ़्त विकल्प भी हैं. हालांकि, इसकी एक समस्या यह है कि डिवाइस का पता लगाने की सुविधा कम काम की होगी. साथ ही, यह सिर्फ़ मोबाइल और दूसरे डिवाइसों के बीच अंतर करता है. यह टैबलेट पर सीमित तौर पर काम करता है. इसके लिए, कुछ बदलाव करने पड़ते हैं.

दूसरा तरीका: क्लाइंट-साइड पर पहचान करना

सुविधा का पता लगाने की सुविधा का इस्तेमाल करके, हम उपयोगकर्ता के ब्राउज़र और डिवाइस के बारे में काफ़ी कुछ जान सकते हैं. हमें यह तय करना होगा कि डिवाइस में टच की सुविधा है या नहीं. साथ ही, यह भी तय करना होगा कि डिवाइस की स्क्रीन बड़ी है या छोटी.

हमें छोटे और बड़े टच डिवाइसों में अंतर करने के लिए, कहीं न कहीं एक सीमा तय करनी होगी. 5" Galaxy Note जैसे ऐज केस के बारे में क्या? नीचे दिए गए ग्राफ़िक में, लोकप्रिय Android और iOS डिवाइसों को ओवरले किया गया है. साथ ही, उनके स्क्रीन रिज़ॉल्यूशन भी दिखाए गए हैं. तारे के निशान से पता चलता है कि डिवाइस, दोगुनी डेंसिटी में आता है या आ सकता है. पिक्सल डेंसिटी को दोगुना किया जा सकता है, लेकिन सीएसएस अब भी वही साइज़ दिखाती है.

सीएसएस में पिक्सल के बारे में थोड़ी जानकारी: मोबाइल वेब पर सीएसएस पिक्सल, स्क्रीन पिक्सल से अलग होते हैं. iOS रेटिना डिवाइसों ने पिक्सल डेंसिटी को दोगुना करने की सुविधा शुरू की थी. उदाहरण के लिए, iPhone 3GS बनाम 4, iPad 2 बनाम 3. वेब को क्रैश होने से बचाने के लिए, रेटिना मोबाइल Safari UA अब भी डिवाइस की एक ही चौड़ाई की जानकारी देते हैं. अन्य डिवाइसों के तौर पर (उदाहरण के लिए, Android) पर ज़्यादा रिज़ॉल्यूशन वाली स्क्रीन मिलती हैं, तो वे डिवाइस की चौड़ाई के लिए वही तरीका अपनाते हैं.

हालांकि, इस फ़ैसले को लेने में पोर्ट्रेट और लैंडस्केप, दोनों मोड का ध्यान रखना ज़रूरी है. हम हर बार डिवाइस के ओरिएंटेशन में बदलाव होने पर, पेज को फिर से लोड नहीं करना चाहते. हालांकि, हम पेज को अलग तरीके से रेंडर करना चाहते हैं.

यहां दिए गए डायग्राम में, स्क्वेयर हर डिवाइस के ज़्यादा से ज़्यादा डाइमेंशन दिखाते हैं. ऐसा, पोर्ट्रेट और लैंडस्केप आउटलाइन को ओवरले करने (और स्क्वेयर को पूरा करने) की वजह से होता है:

थ्रेशोल्ड को 650px पर सेट करके, हम iPhone और Galaxy Nexus को स्मॉलटच और iPad और Galaxy Tab को "टैबलेट" के तौर पर बांटते हैं. इस मामले में, Galaxy Note को "फ़ोन" के तौर पर वर्गीकृत किया गया है और इसे फ़ोन लेआउट मिलेगा.

इसलिए, एक सही रणनीति कुछ इस तरह दिख सकती है:

if (hasTouch) {
  if (isSmall) {
    device = PHONE;
  } else {
    device = TABLET;
  }
} else {
  device = DESKTOP;
}

सुविधा का पता लगाने के तरीके के काम करने का एक छोटा सैंपल देखें.

इसके अलावा, डिवाइस टाइप का पता लगाने के लिए UA स्निफिंग का इस्तेमाल किया जा सकता है. आम तौर पर, आप हेयुरिस्टिक्स का एक सेट बनाते हैं और उन्हें अपने उपयोगकर्ता के navigator.userAgent से मैच करते हैं. स्यूडो कोड कुछ ऐसा दिखता है:

var ua = navigator.userAgent;
for (var re in RULES) {
  if (ua.match(re)) {
    device = RULES[re];
    return;
  }
}

UA का पता लगाने के तरीके का सैंपल देखें.

क्लाइंट-साइड लोडिंग के बारे में जानकारी

अगर आपने अपने सर्वर पर UA का पता लगाने की सुविधा चालू की है, तो आपको नया अनुरोध मिलने पर यह तय करने का विकल्प मिलता है कि कौनसी CSS, JavaScript, और DOM दिखाना है. हालांकि, अगर क्लाइंट-साइड डिटेक्शन किया जा रहा है, तो स्थिति ज़्यादा मुश्किल हो जाती है. आपके पास ये विकल्प हैं:

1. डिवाइस टाइप के हिसाब से बनाए गए ऐसे यूआरएल पर रीडायरेक्ट करें जिसमें इस डिवाइस टाइप के लिए वर्शन शामिल हो.
2. डिवाइस टाइप के हिसाब से ऐसेट को डाइनैमिक तौर पर लोड करें.

पहला तरीका आसान है. इसके लिए, window.location.href = '/tablet' जैसे रीडायरेक्ट की ज़रूरत होती है. हालांकि, अब जगह की जानकारी में डिवाइस टाइप की यह जानकारी जोड़ दी जाएगी. इसलिए, अपने यूआरएल को साफ़ करने के लिए, History API का इस्तेमाल किया जा सकता है. माफ़ करें, इस तरीके में रीडायरेक्ट शामिल होता है. यह प्रोसेस धीमी हो सकती है, खास तौर पर मोबाइल डिवाइसों पर.

दूसरा तरीका लागू करना ज़्यादा मुश्किल है. आपको डाइनैमिक तरीके से CSS और JS लोड करने के लिए, किसी तरीके की ज़रूरत होती है. साथ ही, हो सकता है कि ब्राउज़र के हिसाब से, आपके पास <meta viewport> को पसंद के मुताबिक बनाने जैसी सुविधाएं न हों. साथ ही, रीडायरेक्ट न होने की वजह से, आपको वही ओरिजनल एचटीएमएल दिखता है जो दिखाया गया था. बेशक, JavaScript की मदद से इसमें बदलाव किया जा सकता है. हालांकि, आपके ऐप्लिकेशन के हिसाब से, यह धीमा और/या खराब हो सकता है.

क्लाइंट या सर्वर तय करना

इन तरीकों के बीच के अंतर को यहां बताया गया है:

Pro क्लाइंट:

• UA के बजाय स्क्रीन साइज़/क्षमताओं के आधार पर होने की वजह से, आने वाले समय में ज़्यादा काम का है.
• UA की सूची को बार-बार अपडेट करने की ज़रूरत नहीं है.

Pro सर्वर:

• यह कंट्रोल करने का पूरा अधिकार कि किन डिवाइसों पर किस वर्शन को दिखाना है.
• बेहतर परफ़ॉर्मेंस: क्लाइंट रीडायरेक्ट या डाइनैमिक लोडिंग की ज़रूरत नहीं है.

मेरी निजी पसंद है कि device.js और क्लाइंट-साइड डिटेक्शन से शुरू किया जाए. जैसे-जैसे आपका ऐप्लिकेशन बेहतर होता जाता है, अगर आपको क्लाइंट-साइड रीडायरेक्ट की वजह से परफ़ॉर्मेंस में कोई समस्या आती है, तो device.js स्क्रिप्ट को आसानी से हटाया जा सकता है. साथ ही, सर्वर पर UA का पता लगाने की सुविधा लागू की जा सकती है.

पेश है device.js

Device.js, सेमैंटिक और मीडिया क्वेरी के आधार पर डिवाइस का पता लगाने के लिए शुरुआती पॉइंट है. इसके लिए, सर्वर-साइड कॉन्फ़िगरेशन की ज़रूरत नहीं होती. इससे, उपयोगकर्ता एजेंट स्ट्रिंग को पार्स करने में लगने वाला समय और मेहनत बचती है.

इसका मकसद यह है कि आप अपने <head> के सबसे ऊपर, सर्च इंजन के हिसाब से मार्कअप (link rel=alternate) दें. इससे यह पता चलता है कि आपको अपनी साइट के कौनसे वर्शन उपलब्ध कराने हैं.

<link rel="alternate" href="http://foo.com" id="desktop"
    media="only screen and (touch-enabled: 0)">

इसके बाद, सर्वर साइड पर UA की पहचान करके, वर्शन रीडायरेक्ट को खुद मैनेज किया जा सकता है. इसके अलावा, सुविधा के आधार पर क्लाइंट-साइड रीडायरेक्ट करने के लिए, device.js स्क्रिप्ट का इस्तेमाल किया जा सकता है.

ज़्यादा जानकारी के लिए, device.js प्रोजेक्ट पेज देखें. साथ ही, क्लाइंट-साइड रीडायरेक्ट के लिए, device.js का इस्तेमाल करने वाले नकली ऐप्लिकेशन को भी देखें.

सुझाव: डिवाइस के नाप या आकार के हिसाब से व्यू के साथ एमवीसी

अब तक आपको शायद यह लग रहा होगा कि हम आपको तीन अलग-अलग ऐप्लिकेशन बनाने के लिए कह रहे हैं. नहीं! कोड शेयर करना सबसे अहम है.

उम्मीद है कि आपने Backbone, Ember वगैरह जैसे एमवीसी फ़्रेमवर्क का इस्तेमाल किया होगा. अगर ऐसा है, तो आपको अलग-अलग कामों को अलग-अलग करने के सिद्धांत के बारे में पता होगा. खास तौर पर, यह कि आपके यूज़र इंटरफ़ेस (व्यू लेयर) को आपके लॉजिक (मॉडल लेयर) से अलग किया जाना चाहिए. अगर यह आपके लिए नया है, तो एमवीसी के बारे में और JavaScript में एमवीसी से जुड़े इन रिसॉर्स में से कुछ के साथ शुरुआत करें.

अलग-अलग डिवाइसों पर दिखने वाली स्टोरी, आपके मौजूदा एमवीसी फ़्रेमवर्क में आसानी से फ़िट हो जाती है. हर डिवाइस टाइप के लिए कस्टम व्यू बनाकर, व्यू को अलग-अलग फ़ाइलों में आसानी से ट्रांसफ़र किया जा सकता है. इसके बाद, व्यू लेयर को छोड़कर, सभी डिवाइसों पर एक ही कोड दिखाया जा सकता है.

आपके प्रोजेक्ट का स्ट्रक्चर कुछ ऐसा हो सकता है (हालांकि, आपके पास अपने ऐप्लिकेशन के हिसाब से सबसे सही स्ट्रक्चर चुनने का विकल्प है):

models/ (शेयर किए गए मॉडल) item.js item-collection.js

controllers/ (शेयर किए गए कंट्रोलर) item-controller.js

versions/ (डिवाइस के हिसाब से कॉन्टेंट) tablet/ desktop/ phone/ (फ़ोन के हिसाब से कोड) style.css index.html views/ item.js item-list.js

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

अपने पसंदीदा बिल्ड टूल को चलाने के बाद, आपको तेज़ी से लोड करने के लिए, सभी JavaScript और CSS को एक फ़ाइल में जोड़ना होगा और छोटा करना होगा. इससे आपका प्रोडक्शन एचटीएमएल कुछ ऐसा दिखेगा (फ़ोन के लिए, device.js का इस्तेमाल करके):

<!doctype html>
<head>
  <title>Mobile Web Rocks! (Phone Edition)</title>

  <!-- Every version of your webapp should include a list of all
        versions. -->
  <link rel="alternate" href="http://foo.com" id="desktop"
      media="only screen and (touch-enabled: 0)">
  <link rel="alternate" href="http://m.foo.com" id="phone"
      media="only screen and (max-device-width: 650px)">
  <link rel="alternate" href="http://tablet.foo.com" id="tablet"
      media="only screen and (min-device-width: 650px)">

  <!-- Viewport is very important, since it affects results of media
        query matching. -->
  <meta name="viewport" content="width=device-width">

  <!-- Include device.js in each version for redirection. -->
  <script src="device.js"></script>

  <link rel="style" href="phone.min.css">
</head>
<body>
  <script src="phone.min.js"></script>
</body>

ध्यान दें कि (touch-enabled: 0) मीडिया क्वेरी स्टैंडर्ड नहीं है. इसे सिर्फ़ moz वेंडर प्रीफ़िक्स के पीछे Firefox में लागू किया गया है. हालांकि, device.js इसे सही तरीके से मैनेज करता है. इसकी वजह Modernizr.touch है.

वर्शन बदलना

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

आम तौर पर, मोबाइल वर्शन से डेस्कटॉप वर्शन का लिंक दिया जाता है. इसे लागू करना आसान है, लेकिन device.js में device GET पैरामीटर की मदद से, यह सुविधा काम करती है.

आखिर में

खास जानकारी के लिए, अलग-अलग डिवाइसों पर काम करने वाले ऐसे सिंगल-पेज यूआई बनाते समय जो रिस्पॉन्सिव डिज़ाइन के दायरे में नहीं आते, यह तरीका अपनाएं:

1. डिवाइस क्लास का एक सेट चुनें और डिवाइसों को क्लास में बांटने के लिए ज़रूरी शर्तें तय करें.
2. अलग-अलग कामों को अलग-अलग रखकर, अपना एमवीसी ऐप्लिकेशन बनाएं. इसके लिए, व्यू को बाकी कोडबेस से अलग करें.
3. क्लाइंट साइड डिवाइस क्लास की पहचान करने के लिए, device.js का इस्तेमाल करें.
4. जब आप तैयार हों, तो अपनी स्क्रिप्ट और स्टाइलशीट को हर डिवाइस क्लास के लिए, एक-एक पैकेज में पैकेज करें.
5. अगर क्लाइंट-साइड रीडायरेक्ट की परफ़ॉर्मेंस में कोई समस्या आ रही है, तो device.js का इस्तेमाल बंद करें और सर्वर साइड UA-डिटेक्शन पर स्विच करें.