วิธีการที่ไม่ตอบสนองต่อการสร้างเว็บแอปข้ามอุปกรณ์

Boris Smus

Twitter หน้าแรก

การค้นหาสื่อนั้นดีเยี่ยม แต่...

คิวรี่สื่อเป็นสิ่งที่ยอดเยี่ยม เป็นประโยชน์ต่อนักพัฒนาเว็บไซต์ที่อยากปรับแต่งสไตล์ชีตเล็กๆ น้อยๆ เพื่อมอบประสบการณ์การใช้งานที่ดีขึ้นสำหรับผู้ใช้อุปกรณ์ขนาดต่างๆ คำค้นหาสื่อช่วยให้คุณปรับแต่ง CSS ของเว็บไซต์ตามขนาดหน้าจอได้เป็นหลัก ก่อนที่จะเจาะลึกลงในบทความนี้ โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์และดูตัวอย่างอย่างละเอียดของการใช้คำค้นหาสื่อที่ mediaqueri.es

ตามที่ Brad Frost ได้อธิบายไว้ในบทความก่อนหน้านี้ การเปลี่ยนรูปลักษณ์เป็นเพียงหนึ่งในหลายสิ่งที่ต้องพิจารณาเมื่อสร้างเว็บบนอุปกรณ์เคลื่อนที่ หากสิ่งเดียวที่คุณทำเมื่อสร้างเว็บไซต์บนอุปกรณ์เคลื่อนที่คือการปรับแต่งเลย์เอาต์ด้วยคำค้นหาสื่อ แสดงว่าเรามีสถานการณ์ต่อไปนี้

• อุปกรณ์ทั้งหมดจะได้รับ JavaScript, CSS และเนื้อหา (รูปภาพ วิดีโอ) เดียวกัน ทำให้ใช้เวลาโหลดนานกว่าที่จำเป็น
• อุปกรณ์ทั้งหมดจะได้รับ DOM เริ่มต้นชุดเดียวกัน ซึ่งอาจบังคับให้นักพัฒนาซอฟต์แวร์เขียน CSS ที่ซับซ้อนเกินไป
• มีความยืดหยุ่นเล็กน้อยในการระบุการโต้ตอบแบบกำหนดเองที่ปรับให้เหมาะกับแต่ละอุปกรณ์

เว็บแอปต้องการมากกว่าแค่คิวรี่สื่อ

ตอบผิดนะ ผมไม่ชอบการออกแบบที่ตอบสนองตามอุปกรณ์ผ่านคำค้นหาตามสื่อ และผมคิดว่าวิธีนี้มีที่หนึ่งในโลก นอกจากนี้ ปัญหาบางอย่างที่กล่าวถึงข้างต้นยังแก้ไขได้ด้วยวิธีต่างๆ เช่น รูปภาพที่ปรับเปลี่ยนตามอุปกรณ์ การโหลดสคริปต์แบบไดนามิก ฯลฯ อย่างไรก็ตาม ณ จุดใดจุดหนึ่ง คุณอาจพบว่าตนเองกำลังปรับแต่งเพิ่มขึ้นมากเกินไป และอาจดีกว่าการแสดงผลเวอร์ชันอื่นๆ

เนื่องจาก UI ที่สร้างมีความซับซ้อนมากขึ้น และคุณโน้มเอียงไปที่เว็บแอปในหน้าเดียว คุณอาจต้องปรับแต่ง UI สำหรับอุปกรณ์แต่ละประเภทมากขึ้น บทความนี้จะสอนวิธีปรับแต่งเหล่านี้โดยใช้ความพยายามเพียงเล็กน้อย วิธีการทั่วไปนี้จะจำแนกประเภทอุปกรณ์ของผู้เข้าชมให้อยู่ในกลุ่มอุปกรณ์ที่เหมาะสม และแสดงเวอร์ชันที่เหมาะสมแก่อุปกรณ์นั้น ขณะเดียวกันก็ทำให้การนำโค้ดกลับมาใช้ซ้ำได้สูงสุดระหว่างเวอร์ชันต่างๆ

คุณกำหนดเป้าหมายอุปกรณ์ประเภทใด

ปัจจุบันมีอุปกรณ์ที่เชื่อมต่ออินเทอร์เน็ตอยู่มากมาย และแทบทุกอุปกรณ์มีเบราว์เซอร์ ข้อมูลแทรกซ้อนอยู่ในความหลากหลาย ได้แก่ แล็ปท็อป Mac, เวิร์กสเตชัน Windows, iPhone, iPad, โทรศัพท์ Android ที่มีการป้อนข้อมูลด้วยการสัมผัส, ล้อเลื่อน, แป้นพิมพ์, การป้อนข้อมูลด้วยเสียง, อุปกรณ์ที่มีความไวต่อแรงกด, สมาร์ทวอทช์, เครื่องปิ้งขนมปัง และตู้เย็น และอีกมากมาย อุปกรณ์บางชนิดมีอยู่ทั่วไป และบางอุปกรณ์ก็หายากมาก

อุปกรณ์หลากหลายชนิด (แหล่งที่มา)

ในการสร้างประสบการณ์ของผู้ใช้ที่ดี คุณต้องทราบว่าผู้ใช้ของคุณเป็นใครและใช้อุปกรณ์ใด หากคุณสร้างอินเทอร์เฟซผู้ใช้สำหรับ ผู้ใช้เดสก์ท็อปด้วยเมาส์และแป้นพิมพ์ แล้วสร้างให้กับผู้ใช้สมาร์ทโฟน อินเทอร์เฟซของคุณจะน่าหงุดหงิดเพราะอินเทอร์เฟซนี้ออกแบบมาสำหรับหน้าจอขนาดอื่นและมีรูปแบบการป้อนข้อมูลอีกรูปแบบหนึ่ง

วิธีการมีขอบเขตสุดโต่งอยู่ 2 แบบด้วยกัน ดังนี้

1. สร้างเวอร์ชันเดียวที่ใช้งานได้ในอุปกรณ์ทุกเครื่อง ผลที่ตามมาคืออุปกรณ์แต่ละอย่างมีการพิจารณาการออกแบบต่างกัน

2. สร้างเวอร์ชันสำหรับอุปกรณ์แต่ละเครื่องที่ต้องการรองรับ การดำเนินการนี้อาจใช้เวลานานเกินไป เนื่องจากคุณจะสร้างแอปพลิเคชันหลายเวอร์ชันเกินไป นอกจากนี้ เมื่อสมาร์ทโฟนเครื่องใหม่รุ่นใหม่มาถึง (ซึ่งจะเกิดขึ้นประมาณทุกสัปดาห์) คุณก็จะถูกบังคับให้สร้างอีกเวอร์ชันหนึ่ง

แต่เงื่อนไขพื้นฐานก็คือ ยิ่งมีหมวดหมู่อุปกรณ์มากเท่าใด ประสบการณ์ของผู้ใช้ก็ยิ่งดีขึ้นเท่านั้น แต่การออกแบบ ติดตั้งใช้งาน และดูแลรักษาก็ยิ่งต้องทำงานหนักมากขึ้นเท่านั้น

การสร้างเวอร์ชันแยกต่างหากสำหรับแต่ละคลาสของอุปกรณ์ที่คุณเลือกอาจเป็นความคิดที่ดีด้วยเหตุผลด้านประสิทธิภาพ หรือในกรณีที่เวอร์ชันที่คุณต้องการแสดงในแต่ละคลาสของอุปกรณ์แตกต่างกันอย่างมาก แต่หากไม่เป็นเช่นนั้น การออกแบบเว็บที่ตอบสนองตามอุปกรณ์จะเป็นวิธีที่สมเหตุสมผลที่สุด

โซลูชันที่เป็นไปได้

ข้อดีอีกอย่างหนึ่งคือ แยกอุปกรณ์ออกเป็นหมวดหมู่ต่างๆ และออกแบบประสบการณ์การใช้งานที่ดีที่สุดสำหรับแต่ละหมวดหมู่ หมวดหมู่ที่คุณเลือก ขึ้นอยู่กับผลิตภัณฑ์และผู้ใช้เป้าหมายของคุณ ต่อไปนี้เป็นตัวอย่างการจำแนกประเภทที่ครอบคลุมอุปกรณ์ ที่สามารถใช้งานเว็บได้ซึ่งเป็นที่นิยมอย่างที่มีอยู่ในปัจจุบัน

1. หน้าจอขนาดเล็ก + หน้าจอสัมผัส (ส่วนใหญ่เป็นโทรศัพท์)
2. หน้าจอขนาดใหญ่ + หน้าจอสัมผัส (ส่วนใหญ่เป็นแท็บเล็ต)
3. หน้าจอขนาดใหญ่ + แป้นพิมพ์/เมาส์ (ส่วนใหญ่เป็นเดสก์ท็อป/แล็ปท็อป)

นี่เป็นเพียงรายละเอียดหนึ่งที่เป็นไปได้มากมาย แต่เป็นรายละเอียดที่มีเหตุผลมากในขณะที่เขียน สิ่งที่หายไปจากรายการข้างต้นคืออุปกรณ์เคลื่อนที่ที่ไม่มีหน้าจอสัมผัส (เช่น ฟีเจอร์โฟน โปรแกรมอ่าน eBook โดยเฉพาะ) อย่างไรก็ตาม แอปเหล่านี้ส่วนใหญ่จะมีซอฟต์แวร์การนําทางด้วยแป้นพิมพ์หรือโปรแกรมอ่านหน้าจอติดตั้งอยู่ ซึ่งก็ทํางานได้ด้วยเช่นกัน หากคุณสร้างเว็บไซต์โดยคํานึงถึงการช่วยเหลือพิเศษ

ตัวอย่างเว็บแอปเฉพาะรูปแบบของอุปกรณ์

มีตัวอย่างจำนวนมากของผลิตภัณฑ์และบริการบนอินเทอร์เน็ตที่แสดงเวอร์ชัน ที่แตกต่างกันโดยสิ้นเชิงสำหรับอุปกรณ์รูปแบบต่างๆ Google Search ทำเช่นนี้เช่นเดียวกับ Facebook ข้อควรพิจารณาสำหรับกรณีนี้รวมถึงประสิทธิภาพ (การดึงเนื้อหา การแสดงผลหน้าเว็บ) และประสบการณ์ของผู้ใช้โดยทั่วไป

ในโลกของแอปที่มาพร้อมเครื่อง นักพัฒนาซอฟต์แวร์จำนวนมากเลือกที่จะปรับแต่งประสบการณ์การใช้งานให้เหมาะกับคลาสอุปกรณ์ เช่น Flipboard สำหรับ iPad มี UI ที่แตกต่างจาก Flipboard ใน iPhone มาก เวอร์ชันแท็บเล็ตนี้เหมาะสำหรับใช้มือ 2 ข้างและการพลิกในแนวนอน ส่วนเวอร์ชันโทรศัพท์มีไว้สำหรับการโต้ตอบด้วยมือเดียวและการพลิกในแนวตั้ง แอปพลิเคชันอื่นๆ บน iOS ก็มีเวอร์ชันโทรศัพท์และแท็บเล็ตที่แตกต่างกันมากเช่นกัน เช่น Things (รายการสิ่งที่ต้องทำ) และ Showyou (วิดีโอโซเชียล) ซึ่งมีดังนี้

การปรับแต่ง UI ที่สำคัญสำหรับโทรศัพท์และแท็บเล็ต

วิธีที่ 1: การตรวจหาฝั่งเซิร์ฟเวอร์

ส่วนเซิร์ฟเวอร์ เราจะเข้าใจอุปกรณ์ที่กำลังจัดการอยู่อย่างจำกัดมาก เงื่อนงำที่มีประโยชน์ที่สุดที่มีอยู่คือสตริง User Agent ซึ่งมาจากส่วนหัว User Agent ในคำขอทุกรายการ ด้วยเหตุนี้ แนวทางการดมข้อมูล UA แบบเดียวกันจึงจะใช้งานได้ในส่วนนี้ อันที่จริง โครงการ DeviceAtlas และ WURFL ได้ดำเนินการดังกล่าวไปแล้ว (และให้ข้อมูลเพิ่มเติมมากมายเกี่ยวกับอุปกรณ์)

แต่ทั้ง 2 อย่างนี้ต่างก็มีความท้าทายต่างกัน WURFL มีขนาดใหญ่มาก โดยประกอบด้วย XML ขนาด 20 MB ซึ่งอาจทำให้เกิดโอเวอร์เฮดฝั่งเซิร์ฟเวอร์ที่สำคัญสำหรับคำขอแต่ละรายการ มีโครงการที่แยก XML ด้วยเหตุผลด้านประสิทธิภาพ DeviceAtlas ไม่ใช่โอเพนซอร์ส และคุณต้องใช้สัญญาอนุญาตแบบมีค่าใช้จ่ายในการใช้

อีกทั้งยังมีตัวเลือกฟรีที่ง่ายกว่าและง่ายกว่าด้วย เช่น โปรเจ็กต์ตรวจหาเบราว์เซอร์ในอุปกรณ์เคลื่อนที่ แน่นอนว่าข้อด้อยก็คือการตรวจหาอุปกรณ์ ที่ครอบคลุมน้อยกว่าอย่างหลีกเลี่ยงไม่ได้ นอกจากนี้ยังแยกความแตกต่างระหว่างอุปกรณ์เคลื่อนที่กับอุปกรณ์อื่นๆ เท่านั้น โดยให้การสนับสนุนแท็บเล็ตแบบจำกัดผ่านการปรับแต่งเฉพาะกิจ

วิธีที่ 2: การตรวจหาฝั่งไคลเอ็นต์

เราสามารถเรียนรู้มากมายเกี่ยวกับเบราว์เซอร์และอุปกรณ์ของผู้ใช้โดยใช้การตรวจหาฟีเจอร์ สิ่งสำคัญที่เราต้องพิจารณาคืออุปกรณ์มีความสามารถในการสัมผัสหรือไม่ และเป็นหน้าจอขนาดใหญ่หรือเล็ก

เราต้องลากเส้นแบ่งเพื่อแยกแยะอุปกรณ์ระบบสัมผัสขนาดเล็กและใหญ่ แล้วเคส Edge อย่าง Galaxy Note ขนาด 5" ล่ะ กราฟิกต่อไปนี้แสดงอุปกรณ์ Android และ iOS ยอดนิยมจำนวนหนึ่งที่วางซ้อนกัน (ที่มีความละเอียดหน้าจอสอดคล้องกัน) เครื่องหมายดอกจันแสดงว่าอุปกรณ์มาถึงหรืออาจมีความหนาแน่นเพิ่มขึ้นเป็น 2 เท่า แม้ว่าความหนาแน่นของพิกเซลอาจเป็น 2 เท่า CSS ก็ยังคงรายงานขนาดเดียวกัน

ข้อมูลสั้นๆ เกี่ยวกับพิกเซลใน CSS: พิกเซล CSS ในเว็บบนอุปกรณ์เคลื่อนที่ไม่เหมือนกับพิกเซลหน้าจอ อุปกรณ์ iOS Retina นำ ความหนาแน่นของพิกเซลเป็น 2 เท่า (เช่น iPhone 3GS เทียบกับ 4, iPad 2 เทียบกับ 3) UA สำหรับ Safari ในอุปกรณ์เคลื่อนที่แบบเรตินายังคงรายงานความกว้างของอุปกรณ์เท่าเดิมเพื่อหลีกเลี่ยงการทำลายเว็บ เช่นเดียวกับอุปกรณ์อื่นๆ (เช่น Android) จะได้รับจอแสดงผลที่มีความละเอียดสูงขึ้น แต่จะใช้วิธีการเดียวกันกับความกว้างของอุปกรณ์

ความละเอียดของอุปกรณ์ (เป็นพิกเซล)

อย่างไรก็ตาม สิ่งที่ทำให้เกิดความสับสนคือความสำคัญของการพิจารณาทั้งโหมดแนวตั้งและแนวนอน เราไม่ต้องการโหลดหน้านี้ซ้ำหรือโหลดสคริปต์เพิ่มเติมทุกครั้งที่ปรับการวางแนวอุปกรณ์ แต่อาจต้องการแสดงผลหน้าเว็บให้แตกต่างออกไป

ในแผนภาพต่อไปนี้ สี่เหลี่ยมจัตุรัสจะแสดงขนาดสูงสุดของอุปกรณ์แต่ละเครื่อง ซึ่งเป็นผลมาจากการซ้อนทับเส้นแนวตั้งและแนวนอน (และเติมสี่เหลี่ยมจัตุรัส)

ความละเอียดแนวตั้ง + แนวนอน (เป็นพิกเซล)

เมื่อตั้งค่าเกณฑ์เป็น 650px เราจะจัดประเภท iPhone, Galaxy Nexus เป็น smalltouch และ iPad, Galaxy Tab เป็น "แท็บเล็ต" Galaxy Note ของ Google+ ในตัวอย่างนี้ได้รับการจัดประเภทเป็น "phone" และจะมีเลย์เอาต์ของโทรศัพท์

กลยุทธ์ที่สมเหตุสมผลอาจมีลักษณะดังนี้

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

ดูตัวอย่างเล็กๆ น้อยๆ ของวิธีการตรวจหาฟีเจอร์ในการใช้งานจริง

อีกวิธีหนึ่งคือการใช้การดักจับของ UA เพื่อตรวจหาประเภทอุปกรณ์ โดยพื้นฐานแล้ว คุณสร้างชุดการเรียนรู้และจับคู่กับ navigator.userAgent ของผู้ใช้ได้ โค้ด Pseudo มีลักษณะดังต่อไปนี้

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

ดูตัวอย่างการทำงานของวิธีการตรวจหา UA

หมายเหตุเกี่ยวกับการโหลดฝั่งไคลเอ็นต์

หากทำการตรวจหา UA บนเซิร์ฟเวอร์ คุณสามารถเลือก CSS, JavaScript และ DOM ที่จะแสดงเมื่อได้รับคำขอใหม่ อย่างไรก็ตาม หากคุณทำการตรวจหาฝั่งไคลเอ็นต์ สถานการณ์จะซับซ้อนมากขึ้น คุณมีหลายตัวเลือกดังนี้

1. เปลี่ยนเส้นทางไปยัง URL เฉพาะประเภทอุปกรณ์ที่มีเวอร์ชันสำหรับอุปกรณ์ประเภทนี้
2. โหลดเนื้อหาเฉพาะประเภทอุปกรณ์แบบไดนามิก

วิธีแรกนั้นตรงไปตรงมา ซึ่งต้องเปลี่ยนเส้นทาง เช่น window.location.href = '/tablet' อย่างไรก็ตาม ตอนนี้ตำแหน่งดังกล่าวจะมีข้อมูลประเภทอุปกรณ์อยู่ต่อท้ายไปแล้ว ดังนั้นคุณอาจต้องใช้ History API เพื่อล้าง URL ของคุณ ขออภัย วิธีนี้ต้องมีการเปลี่ยนเส้นทาง ซึ่งทำได้ช้า โดยเฉพาะในอุปกรณ์เคลื่อนที่

วิธีที่ 2 ใช้งานค่อนข้างซับซ้อน คุณต้องมีกลไกในการโหลด CSS และ JS แบบไดนามิก และ (ขึ้นอยู่กับเบราว์เซอร์) คุณอาจทำสิ่งต่อไปนี้ไม่ได้ เช่น ปรับแต่ง <meta viewport> และเนื่องจากไม่มีการเปลี่ยนเส้นทาง คุณจึงค้างอยู่ที่ HTML เดิมที่แสดง แน่นอนว่าคุณสามารถจัดการแท็กด้วย JavaScript ได้ แต่อาจทำงานช้าและ/หรือไม่สุภาพ ทั้งนี้ขึ้นอยู่กับแอปพลิเคชันของคุณ

การตัดสินใจเกี่ยวกับไคลเอ็นต์หรือเซิร์ฟเวอร์

ข้อดีและข้อเสียระหว่าง 2 วิธีนี้มีดังนี้

ลูกค้า Pro:

• พิสูจน์ให้เห็นว่าอนาคตจะเป็นอย่างไรเมื่อพิจารณาขนาด/ความสามารถของหน้าจอมากกว่า UA
• ไม่จำเป็นต้องอัปเดตรายการ UA อย่างสม่ำเสมอ

Pro Server:

• ควบคุมเวอร์ชันที่จะแสดงในอุปกรณ์ได้โดยสมบูรณ์
• ประสิทธิภาพที่ดีขึ้น: ไม่จำเป็นต้องเปลี่ยนเส้นทางไคลเอ็นต์หรือการโหลดแบบไดนามิก

ความต้องการส่วนตัวของผมคือเริ่มต้นด้วย device.js และการตรวจหาฝั่งไคลเอ็นต์ เมื่อแอปพลิเคชันมีการพัฒนามากขึ้น หากพบว่าการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์มีข้อเสียด้านประสิทธิภาพอย่างมาก คุณอาจนำสคริปต์ device.js ออกและใช้การตรวจจับ UA บนเซิร์ฟเวอร์ได้อย่างง่ายดาย

ขอแนะนำ device.js

Device.js คือจุดเริ่มต้นของการตรวจหาอุปกรณ์เชิงความหมายโดยใช้คำค้นหาสื่อ โดยไม่จำเป็นต้องกำหนดค่าพิเศษฝั่งเซิร์ฟเวอร์ ซึ่งช่วยประหยัดแรงและเวลาที่ต้องใช้ในการแยกวิเคราะห์สตริง User Agent

แนวคิดคือคุณใส่มาร์กอัปที่เหมาะกับเครื่องมือค้นหา (link rel=alternate) ที่ด้านบนของ <head> เพื่อระบุเวอร์ชันของเว็บไซต์ที่ต้องการ

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

ถัดไป คุณจะตรวจหา UA ฝั่งเซิร์ฟเวอร์และจัดการการเปลี่ยนเส้นทางเวอร์ชันด้วยตัวเอง หรือใช้สคริปต์ device.js เพื่อเปลี่ยนเส้นทางฝั่งไคลเอ็นต์ตามฟีเจอร์ก็ได้

ดูข้อมูลเพิ่มเติมได้ที่หน้าโปรเจ็กต์ device.js และแอปพลิเคชันปลอมที่ใช้ device.js สําหรับการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์

คำแนะนำ: MVC ที่มีมุมมองเฉพาะสำหรับรูปแบบของอุปกรณ์

ถึงตอนนี้คุณอาจคิดว่าฉันบอกให้คุณสร้างแอป 3 แอปแยกจากกัน โดยใช้ 1 แอปสำหรับอุปกรณ์แต่ละประเภท ไม่เอาด้วยหรอก การแชร์โค้ดคือ กุญแจสำคัญ

หวังว่าคุณจะเคยใช้เฟรมเวิร์กที่เหมือน MVC อย่างเช่น Backbone, Ember เป็นต้น หากเคยใช้แล้ว คุณคุ้นเคยกับหลักการแยกข้อกังวล โดยเฉพาะอย่างยิ่งต้องแยก UI (Viewเลเยอร์) ออกจากตรรกะของคุณ (โมเดลเลเยอร์) หากคุณยังไม่คุ้นเคยกับการสตรีม ให้เริ่มต้นใช้งานด้วยแหล่งข้อมูลเกี่ยวกับ MVC และ MVC ใน JavaScript เหล่านี้

เรื่องราวจากหลายอุปกรณ์นี้เข้ากับเฟรมเวิร์ก MVC ที่คุณมีอยู่อย่างลงตัว คุณสามารถย้ายมุมมองไปที่ไฟล์แยกต่างหากได้อย่างง่ายดาย ซึ่งเป็นการสร้างมุมมองที่กำหนดเองสำหรับอุปกรณ์แต่ละประเภท จากนั้นคุณสามารถแสดงโค้ดเดียวกันสำหรับทุกอุปกรณ์ ยกเว้นเลเยอร์มุมมอง

MVC หลายอุปกรณ์

โปรเจ็กต์ของคุณอาจมีโครงสร้างต่อไปนี้ (แน่นอนว่าคุณเลือกโครงสร้างที่เหมาะสมที่สุดตามแอปพลิเคชันของคุณได้)

โมเดล/ (โมเดลที่ใช้ร่วมกัน) item.js item-collection.js

Controller/ (ตัวควบคุมที่ใช้ร่วมกัน) item-controller.js

เวอร์ชัน/ (ข้อมูลเฉพาะอุปกรณ์) แท็บเล็ต/ เดสก์ท็อป/ โทรศัพท์/ (โค้ดเฉพาะโทรศัพท์) style.css index.html view/ item.js item-list.js

โครงสร้างประเภทนี้ช่วยให้คุณควบคุมเนื้อหาที่จะโหลดแต่ละเวอร์ชันได้อย่างเต็มที่ เนื่องจากคุณมี HTML, CSS และ JavaScript ที่กำหนดเองสำหรับแต่ละอุปกรณ์ ซึ่งเป็นวิธีที่มีประสิทธิภาพสูงและนำไปสู่การพัฒนาที่น้อยที่สุดและมีประสิทธิภาพมากที่สุดสำหรับเว็บแบบข้ามอุปกรณ์ โดยไม่ต้องอาศัยเทคนิคใดๆ เช่น รูปภาพแบบปรับอัตโนมัติ

เมื่อคุณเรียกใช้เครื่องมือสร้างที่ชอบแล้ว คุณจะเชื่อมต่อและลดขนาด JavaScript และ CSS ทั้งหมดให้เป็นไฟล์เดียวเพื่อให้โหลดได้เร็วขึ้น โดย HTML เวอร์ชันที่ใช้งานจริงจะมีลักษณะดังต่อไปนี้ (สำหรับโทรศัพท์ ที่ใช้ 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) นั้นไม่ได้เป็นมาตรฐาน (ใช้ได้ใน Firefox หลังคำนำหน้าผู้ให้บริการ moz เท่านั้น) แต่ได้รับการจัดการอย่างถูกต้อง (ต้องขอบคุณ Modernizr.touch) โดย device.js

การลบล้างเวอร์ชัน

บางครั้งการตรวจหาอุปกรณ์อาจผิดพลาด และในบางกรณี ผู้ใช้อาจต้องการดูการจัดวางของแท็บเล็ตบนโทรศัพท์ (อาจใช้ Galaxy Note) คุณจึงต้องให้ผู้ใช้เลือกได้ว่าจะใช้เว็บไซต์เวอร์ชันใดหากต้องการลบล้างด้วยตนเอง

วิธีทั่วไปคือให้ลิงก์ไปยังเวอร์ชันเดสก์ท็อปจากเวอร์ชันอุปกรณ์เคลื่อนที่ วิธีการนี้ใช้งานง่ายพอ แต่ device.js รองรับฟังก์ชันนี้ด้วยพารามิเตอร์ device GET

สรุป

กล่าวโดยสรุปคือ เมื่อสร้าง UI แบบหน้าเดียวแบบหลายอุปกรณ์ที่ไม่เข้ากับโลกแห่งการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์เลย ให้ทำดังนี้

1. เลือกชุดคลาสอุปกรณ์ที่จะสนับสนุนและเกณฑ์ที่จะใช้ในการจัดประเภทอุปกรณ์เป็นคลาส
2. สร้างแอป MVC ด้วยการแยกข้อกังวลใจอย่างชัดเจน โดยแยกมุมมองออกจากฐานของโค้ดที่เหลือ
3. ใช้ device.js เพื่อตรวจจับคลาสอุปกรณ์ฝั่งไคลเอ็นต์
4. เมื่อคุณพร้อมแล้ว ให้แพ็กเกจสคริปต์และสไตล์ชีตเป็นคลาสใดคลาสหนึ่งสำหรับอุปกรณ์แต่ละคลาส
5. หากประสบปัญหาเกี่ยวกับประสิทธิภาพการเปลี่ยนเส้นทางฝั่งไคลเอ็นต์ ให้เลิกใช้ device.js แล้วเปลี่ยนไปใช้การตรวจหา UA ฝั่งเซิร์ฟเวอร์