แนวทางที่ไม่ปรับเปลี่ยนตามอุปกรณ์ในการสร้างเว็บแอปที่ใช้งานได้บนอุปกรณ์หลายประเภท

Boris Smus

คิวรี่สื่อนั้นยอดเยี่ยม แต่…

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

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

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

เว็บแอปต้องมีมากกว่า Media Query

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

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

คุณกำหนดเป้าหมายเป็นอุปกรณ์คลาสใด

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

อุปกรณ์หลากหลายประเภท (แหล่งที่มา)

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

แนวทางในการจัดการการเปลี่ยนแปลงมี 2 สุดขั้ว ดังนี้

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

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

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

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

วิธีแก้ปัญหาที่อาจเป็นไปได้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การตั้งค่าเกณฑ์เป็น 650px ทำให้เราจัดประเภท iPhone และ Galaxy Nexus เป็น smalltouch และ 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. เปลี่ยนเส้นทางไปยัง URL เฉพาะประเภทอุปกรณ์ที่มีเวอร์ชันสำหรับ อุปกรณ์ประเภทนี้
2. โหลดชิ้นงานเฉพาะประเภทอุปกรณ์แบบไดนามิก

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

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

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

ข้อดีและข้อเสียของแต่ละวิธีมีดังนี้

ไคลเอ็นต์ Pro:

• พร้อมรับมือกับอนาคตได้มากกว่าเนื่องจากอิงตามขนาด/ความสามารถของหน้าจอแทนที่จะเป็น UA
• ไม่ต้องอัปเดตรายการ UA อยู่ตลอดเวลา

เซิร์ฟเวอร์ Pro:

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

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

ขอแนะนำ device.js

Device.js เป็นจุดเริ่มต้นในการตรวจหาอุปกรณ์ตามความหมายที่อิงตาม Media Query โดยไม่ต้องมีการกำหนดค่าพิเศษฝั่งเซิร์ฟเวอร์ ซึ่งช่วยประหยัดเวลาและความพยายามที่ต้องใช้ในการแยกวิเคราะห์สตริง 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 แอปที่แยกจากกันโดยสิ้นเชิง โดยแต่ละแอปจะใช้สำหรับอุปกรณ์แต่ละประเภท ไม่เอาด้วยหรอก การแชร์โค้ดเป็น กุญแจสำคัญ

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

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

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

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

models/ (โมเดลที่แชร์) item.js item-collection.js

controllers/ (shared controllers) item-controller.js

versions/ (สิ่งต่างๆ ที่เฉพาะเจาะจงสำหรับอุปกรณ์) tablet/ desktop/ phone/ (โค้ดที่เฉพาะเจาะจงสำหรับโทรศัพท์) style.css index.html views/ 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) Media Query ไม่ได้เป็นไปตามมาตรฐาน (ใช้ได้เฉพาะใน Firefox ที่อยู่หลังmozคำนำหน้าของผู้ให้บริการ) แต่ device.js จะจัดการได้อย่างถูกต้อง (ขอขอบคุณ Modernizr.touch)

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

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

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

สรุป

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

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