การทำเว็บด้วย AI ให้แสดงข้อมูลแบบ real-time และเชื่อมหลายหน้าจอให้เห็นข้อมูลชุดเดียวกันโดยไม่ต้องกด refresh สามารถทำได้จริงด้วยเครื่องมืออย่าง Claude Code, Codex หรือ Cursor หัวใจสำคัญไม่ได้อยู่ที่การเขียน code ที่ซับซ้อนด้วยตัวเอง แต่อยู่ที่การเลือกกลไกส่งข้อมูลระหว่าง browser กับ backend ให้ตรงกับลักษณะงานตั้งแต่วางโครงสร้างครั้งแรก หากผู้สร้างเข้าใจความแตกต่างของการดึงข้อมูลตามรอบเวลา การเปิดช่องทางรับข้อมูลสด และการจัดการ state บนหน้าจอ ก็จะสั่ง AI ให้สร้างระบบที่ทำงานประสานกันหลายอุปกรณ์ได้อย่างราบรื่น
ทำไมเว็บที่สั่ง AI สร้างในรอบแรกมักไม่เปลี่ยนข้อมูลเองเมื่อเปิดหลายหน้าจอ
ผู้ที่เริ่มต้นสร้างเว็บด้วย AI จำนวนมากมักพบปัญหาเดียวกันคือ เมื่อทดสอบเว็บด้วยตัวเองบนหน้าจอเดียว ทุกอย่างดูทำงานได้ปกติ แต่พอเปิดเว็บเดียวกันบนโทรศัพท์มือถืออีกเครื่อง หรือเปิดซ้อนกัน 2 tab บนคอมพิวเตอร์ ข้อมูลที่เพิ่มหรือแก้ไขในหน้าจอที่ 1 กลับไม่ปรากฏบนหน้าจอที่ 2 จนกว่าจะกดปุ่ม refresh บน browser ด้วยตัวเอง
สาเหตุที่เป็นเช่นนี้เพราะเมื่อเราเขียน prompt สั่ง AI ด้วยคำสั่งทั่วไป เช่น ขอให้สร้างหน้าเว็บรับรายการอาหาร หรือสร้างตารางบันทึกค่าใช้จ่าย AI จะเลือกสร้างโครงสร้างพื้นฐานที่เรียบง่ายที่สุดก่อนเสมอ โดยมักเขียน code ให้ทำงานใน 2 ลักษณะนี้
- เก็บข้อมูลไว้ใน localStorage ของ browser เครื่องที่กำลังใช้งานอยู่ ซึ่งทำให้ข้อมูลถูกขังอยู่ในอุปกรณ์นั้นเครื่องเดียว อุปกรณ์อื่นที่เปิดหน้าเว็บเดียวกันจึงไม่มีทางมองเห็นข้อมูลชุดนี้ได้เลย
- เชื่อมต่อกับ database จริง แต่เขียนคำสั่งให้ดึงข้อมูลเฉพาะตอนเปิดหน้าเว็บครั้งแรกเท่านั้น เมื่อหน้าจอที่ 1 ส่งข้อมูลใหม่ขึ้นไปเก็บใน database สำเร็จ หน้าจอที่ 2 ที่เปิดค้างไว้ก่อนแล้วจึงไม่รับรู้ว่าข้อมูลใน table มีการเปลี่ยนแปลง
การทำให้หลายหน้าจอเห็นข้อมูลตรงกันโดยอัตโนมัติ จึงต้องสั่ง AI ให้วางองค์ประกอบครบ 3 ส่วน ได้แก่ ตัวเก็บข้อมูลกลางบน backend ที่ทุกเครื่องเข้าถึงร่วมกัน ช่องทางส่งสัญญาณแจ้งเตือนเมื่อข้อมูลเปลี่ยน และตัวจัดการ state บน frontend ที่คอยรับข้อมูลใหม่มาวาดทับเฉพาะจุดโดยไม่ทำให้หน้าจอกระพริบ
ตัวอย่างเว็บและแอปฝีมือคนไทยที่ใช้การเชื่อมข้อมูลหลายหน้าจอและระบบ real-time
ในคลังผลงานบน applnw.com ที่มีเว็บและแอปฝีมือคนไทยสร้างด้วย AI รวม 2478 รายการ มีผลงานหลายชิ้นที่นำแนวคิดการเชื่อมข้อมูลข้ามหน้าจอและการทำงานแบบ real-time ไปแก้ปัญหาในชีวิตประจำวันและงานบริการได้อย่างน่าสนใจ
- เหลือไร (LuerRai) เว็บในหมวดร้านอาหารและเครื่องดื่มที่ deploy บน Vercel และใช้ Supabase เป็น backend สร้างขึ้นเพื่อติดตามสถานะร้านค้าและรายการอาหารในโรงอาหารว่าเหลือหรือหมดโดยไม่ต้องโหลดหน้าใหม่ ช่วยให้นักเรียนค้นหาร้าน ติดตามร้านโปรด และสุ่มอาหารได้ ลดปัญหาการเดินไปถึงร้านแล้วพบว่าอาหารหมด
- PaynEat POS ระบบในหมวดร้านอาหารและเครื่องดื่มที่วางระบบบน GitHub Pages ทำหน้าที่เชื่อมงานรับรายการอาหารของพนักงานเข้ากับหน้าจอครัว การปิดยอดชำระ และการดูยอดขายของผู้จัดการร้าน รองรับทั้ง PromptPay QR การใช้งานเมื่อไม่มีเครือข่าย รวมถึงรองรับภาษาไทยและอังกฤษ
- ทริปโซล เว็บในหมวดท่องเที่ยวและการเดินทางบน Cloudflare Pages ที่แสดงแผนเที่ยวเกาหลีใต้สำหรับ OATT และ POPP พร้อมช่องบันทึกค่าใช้จ่ายที่เชื่อมข้อมูลข้ามเครื่อง โดยผู้เดินทางทั้ง 2 คนสามารถเพิ่มทางเข้าบนหน้าจอมือถือและเปิดดูแผนได้แม้ไม่มีเครือข่าย
- RUAMTHANG (ร่วมทาง) ผลงานในหมวดยานยนต์และขนส่งที่ใช้ Tailwind และวางระบบบน Vercel สำหรับเปิดห้องสนทนาด้วยเสียงแบบ real-time ให้ผู้ที่จอดติดไฟแดงในบริเวณเดียวกันพูดคุยกัน ผู้ร่วมทางสามารถแลกเปลี่ยนข้อมูลจราจรหรือคลายเหงาระหว่างรอไฟเขียว และติดตั้งเป็น PWA ได้
- Moom เว็บในหมวดครีเอทีฟและออกแบบที่พัฒนาด้วย Next.js บน Vercel เพื่อเปิดหน้ารับเงินสนับสนุนผ่านพร้อมเพย์และร้านขาย file ดิจิทัลให้ streamer และ VTuber ไทย โดยเงินโอนเข้าผู้รับโดยตรง มีการตรวจยอดด้วยตนเองหรือ SlipOK พร้อมการแจ้งเตือนบน OBS และอ่านข้อความด้วยเสียง ทั้งนี้การเชื่อมต่อ SlipOK และ VTube Studio ยังไม่ได้ทดสอบกับบริการจริง
จากตัวอย่างข้างต้นจะเห็นว่าคำว่าเชื่อมข้อมูลข้ามหน้าจอไม่ได้มีรูปแบบเดียว งานบางประเภทต้องการเพียงให้ข้อมูลรายการอาหารหรือค่าใช้จ่ายตรงกันระหว่างผู้ใช้งาน ส่วนงานบางประเภทต้องการส่งสัญญาณแจ้งเตือนขึ้นหน้าจอแสดงผลหรือส่งเสียงสนทนาแบบทันทีทันใด
เทียบ 4 กลไกทำให้หน้าเว็บเปลี่ยนข้อมูลอัตโนมัติ เลือกแบบไหนให้เหมาะกับงาน
ก่อนจะสั่ง AI ให้แก้ไข code เราควรเลือกกลไกการรับส่งข้อมูลให้เหมาะกับความถี่และลักษณะของงาน เพราะถ้าเลือกวิธีที่ซับซ้อนเกินความจำเป็น ระบบจะดูแลรักษายากและอาจชนเพดานการใช้งานของ free tier ได้เร็วเกินไป ตารางด้านล่างนี้เปรียบเทียบ 4 แนวทางหลักที่สามารถสั่งให้ AI เขียนได้ทันที
| กลไกการรับส่งข้อมูล | ลักษณะการทำงาน | งานที่เหมาะสม | ข้อควรระวังเมื่อสั่ง AI สร้าง |
|---|---|---|---|
| Polling | ให้ browser ตั้งเวลาส่งคำขอไปถามข้อมูลใหม่จาก server ตามรอบเวลาที่กำหนด | หน้าจอแสดงยอดขายรายชั่วโมง ตารางสรุปข้อมูล หรือสถานะที่ไม่ต้องเปลี่ยนระดับวินาที | यदिตั้งเวลาน้อยเกินไปจะเปลืองจำนวนครั้งการเรียก API และทำให้ server ทำงานหนักโดยไม่จำเป็น |
| Database Realtime Subscription | ผูกหน้าเว็บเข้ากับ event ของ table ใน backend เช่น Supabase เพื่อรับเฉพาะ row ที่เพิ่ม แก้ไข หรือลบ | ระบบห้องครัวรับรายการอาหาร ระบบแจ้งสถานะร้านค้า บันทึกค่าใช้จ่ายร่วมกันหลายเครื่อง | ต้องสั่ง AI ให้คืนทรัพยากรการเชื่อมต่อทุกครั้งเมื่อผู้ใช้เปลี่ยนหน้า เพื่อไม่ให้เกิดการรับข้อมูลซ้ำซ้อน |
| Server-Sent Events (SSE) | เปิดช่องทางให้ server ส่งข้อมูลไหลลงมาที่ browser ทางเดียวอย่างต่อเนื่อง | หน้าจอแจ้งเตือนขึ้นจอ OBS การแสดงผลข้อความจาก AI ทีละคำ หรือป้ายประกาศสถานะสด | เหมาะกับการส่งข้อมูลจากระบบไปหาผู้ชมทางเดียว หากผู้ใช้ต้องส่งข้อมูลโต้ตอบกลับถี่ๆ จะไม่คล่องตัว |
| WebSocket และ WebRTC | เปิดท่อสื่อสารสองทางความหน่วงต่ำระหว่างอุปกรณ์หรือผ่านตัวกลาง | ห้องสนทนาด้วยเสียงแบบสด เกมที่เล่นพร้อมกันหลายหน้าจอ หรือกระดานวาดภาพร่วมกัน | ใช้ทรัพยากรการเชื่อมต่อสูงและต้องจัดการกรณีสัญญาณ internet สะดุดอย่างรัดกุม |
1. Polling ทางเลือกที่ง่ายและเสถียรสำหรับงานทั่วไป
หลายคนเข้าใจว่าทุกเว็บต้องใช้ระบบเชื่อมต่อสดตลอดเวลา แต่ในความจริงแล้ว ถ้าคุณกำลังทำหน้าจอสรุปยอดขายให้ผู้จัดการร้านดู หรือทำหน้าตารางคะแนนที่เปลี่ยนทุก 1 ถึง 2 นาที การสั่ง AI ให้ใช้วิธี Polling โดยดึงข้อมูลใหม่ทุก 15 หรือ 30 วินาที และดึงข้อมูลอีกครั้งเมื่อผู้ใช้สลับกลับมาเปิดหน้าจอ เป็นวิธีที่เขียนง่ายที่สุด เกิด bug น้อยที่สุด และทำงานร่วมกับ hosting ได้แทบทุกประเภท
2. Database Realtime Subscription ทางเลือกยอดนิยมสำหรับคนทำเว็บด้วย AI
สำหรับเว็บที่ต้องรับส่งข้อมูลระหว่างผู้ใช้งานหลายคน เช่น พนักงานหน้าร้านกดรับรายการแล้วหน้าจอในครัวต้องเด้งขึ้นทันที หรือร้านค้ากดเปลี่ยนสถานะว่าอาหารหมดแล้วหน้าจอของผู้เรียนต้องเปลี่ยนตามโดยไม่ต้องกด refresh การใช้ความสามารถด้าน real-time ที่ติดมากับบริการอย่าง Supabase หรือ Firebase คือทางเลือกที่สะดวกที่สุด เพราะไม่ต้องตั้ง server สำหรับจัดการ WebSocket เอง เพียงสั่ง AI ให้ผูกคำสั่ง subscribe เข้ากับ table ที่ต้องการ เมื่อข้อมูลใน table มีการเปลี่ยนแปลง ระบบจะส่งเฉพาะข้อมูลส่วนที่เปลี่ยนมาให้ browser ทันที
3. Server-Sent Events และ WebSocket สำหรับงานแจ้งเตือนสดและสื่อสารสองทาง
หากงานของคุณเป็นหน้าจอแสดงผลที่รอรับสัญญาณจากระบบหลังบ้านอย่างเดียว เช่น หน้าต่างแจ้งเตือนเวลาคนโอนเงินสนับสนุนเพื่อนำไปซ้อนทับบนโปรแกรมถ่ายทอดสด การใช้ Server-Sent Events หรือการรับสัญญาณผ่าน channel เฉพาะกิจจะช่วยให้หน้าจอฝั่งรับมีขนาดเบาและเปิดทิ้งไว้ได้นาน ส่วนงานที่ต้องการส่งเสียงสนทนาสดหรือแลกเปลี่ยนพิกัดกันตลอดเวลา จำเป็นต้องระบุใน prompt ให้ AI ใช้ WebSocket หรือ WebRTC เพื่อลดความหน่วงของสัญญาณให้ต่ำที่สุด
ขั้นตอนสั่ง AI สร้างระบบเชื่อมข้อมูลหลายหน้าจอตั้งแต่ต้นจนใช้งานได้จริง
เมื่อเลือกกลไกที่เหมาะกับงานได้แล้ว การสั่ง AI ให้เขียนระบบเชื่อมข้อมูลหลายหน้าจอควรแบ่งออกเป็น 4 ขั้นตอนย่อย เพื่อให้เราตรวจสอบความถูกต้องได้ทีละส่วนและป้องกันไม่ให้ AI รื้อโครงสร้างเดิมจนพัง
1. กำหนดบทบาทของแต่ละหน้าจอและข้อมูลที่ต้องเปลี่ยนพร้อมกัน
อย่าเพิ่งสั่งคำกว้างๆ อย่างคำว่าขอระบบ real-time ทั้งเว็บ ให้แยกแยะก่อนว่าในระบบของเรามีหน้าจอของใครบ้าง และข้อมูลก้อนไหนที่ต้องเปลี่ยนทันที ตัวอย่างเช่น ในระบบร้านอาหาร หน้าจอของพนักงานรับรายการเป็นฝั่งส่งข้อมูลเข้า table ส่วนหน้าจอห้องครัวเป็นฝั่งรอรับรายการใหม่และกดเปลี่ยน status ของอาหาร ในขณะที่รายการเมนูทั้งหมดหรือราคาสินค้าอาจไม่จำเป็นต้องเปิดรับข้อมูลสดตลอดเวลา การระบุขอบเขตที่ชัดเจนช่วยให้ AI เขียน code เฉพาะจุดที่จำเป็น
2. สั่ง AI ออกแบบโครงสร้าง table และกรองข้อมูลเฉพาะกลุ่ม
ความผิดพลาดสำคัญเวลาให้ AI เขียนคำสั่ง subscribe คือ AI มักสั่งให้หน้าเว็บดึงการเปลี่ยนแปลงทุกอย่างใน table มาทั้งหมด หากเว็บของคุณมีผู้ใช้หลายกลุ่ม เช่น มีผู้เดินทางหลายคณะ หรือมีร้านค้าหลายร้านในระบบเดียวกัน ต้องสั่งให้ AI กำหนดตัวกรองข้อมูล หรือ filter ตามรหัสกลุ่ม เช่น รหัสห้อง รหัสร้าน หรือรหัสแผนการเดินทาง เพื่อให้หน้าจอของผู้ใช้รับเฉพาะข้อมูลที่เกี่ยวข้องกับกลุ่มของตนเองเท่านั้น
นอกจากนี้ ควรสั่งให้ AI แยกขั้นตอนการโหลดข้อมูลครั้งแรกออกจากขั้นตอนการรับข้อมูลใหม่ กล่าวคือ เมื่อเปิดหน้าเว็บครั้งแรกให้ดึงข้อมูลปัจจุบันทั้งหมดมาแสดงผลก่อน 1 รอบ จากนั้นเมื่อมี event แจ้งว่ามีการเพิ่มรายการใหม่ การแก้ไข หรือการลบ ให้ AI นำเฉพาะข้อมูลแถวนั้นไปปรับปรุงใน state เดิม แทนการสั่งดึงข้อมูลทั้งตารางใหม่ทุกครั้งที่มีการกดปุ่ม
3. จัดการการแสดงผลบนหน้าจอเมื่อมีข้อมูลใหม่เข้ามาโดยไม่รบกวนผู้ใช้
ปัญหาที่พบบ่อยมากเมื่อเปิดใช้งานจริงคือ เวลาหน้าจอที่ 1 ส่งข้อมูลเข้ามา หน้าจอที่ 2 กลับกระตุก เลื่อนกลับไปบนสุดของหน้าเว็บเอง หรือข้อความที่ผู้ใช้ฝั่งหน้าจอที่ 2 กำลังพิมพ์ค้างอยู่ในช่อง input ถูกล้างหายไปทั้งหมด
สาเหตุเกิดจาก AI เขียนคำสั่งให้วาดหน้าเว็บใหม่ทั้งหน้าเมื่อได้รับข้อมูลสด วิธีแก้คือต้องกำชับใน prompt ให้ AI แยก state ของตารางแสดงผลออกจาก state ของ form ที่ใช้กรอกข้อมูล และเมื่อมีข้อมูลใหม่เข้ามา ให้ปรับปรุงเฉพาะรายการที่เปลี่ยนพร้อมรักษาตำแหน่ง scroll เดิมของผู้ใช้ไว้ หากมีรายการใหม่เพิ่มเข้ามาในขณะที่ผู้ใช้เลื่อนหน้าจอลงไปดูข้อมูลด้านล่าง อาจให้แสดงเป็นแถบแจ้งเตือนเล็กๆ ว่ามีข้อมูลใหม่แทนการบังคับเลื่อนหน้าจอทันที
4. สั่ง AI เขียนระบบต่อสัญญาณใหม่เมื่อหน้าจอมือถือพักเครื่อง
พฤติกรรมการใช้งานบนโทรศัพท์มือถือต่างจากคอมพิวเตอร์อย่างมาก เพราะผู้ใช้มักกดสลับไปเปิดแอปอื่น หรือปล่อยให้หน้าจอดับไปชั่วคราว เมื่อหน้าจอมือถือพักการทำงาน browser มักตัดการเชื่อมต่อเครือข่ายเบื้องหลังเพื่อประหยัดพลังงาน พอผู้ใช้กลับมาเปิดหน้าจออีกครั้ง หน้าเว็บยังแสดงอยู่เหมือนเดิมแต่ท่อส่งข้อมูลแบบ real-time ขาดไปแล้ว ทำให้หน้าจอนั้นไม่เปลี่ยนข้อมูลอีกต่อไป
ดังนั้น ทุกครั้งที่ทำเว็บให้คนใช้บนมือถือ ต้องสั่ง AI ให้ตรวจจับเหตุการณ์เมื่อผู้ใช้สลับกลับมาที่หน้าเว็บและเมื่อสัญญาณ internet กลับมาเชื่อมต่อได้อีกครั้ง โดยให้ระบบตรวจสอบสถานะของ channel หากพบว่าการเชื่อมต่อหลุดไป ให้ทำการเชื่อมต่อใหม่พร้อมดึงข้อมูลล่าสุดมาเทียบ 1 รอบเพื่อให้มั่นใจว่าไม่มีข้อมูลตกหล่นระหว่างที่หน้าจอดับไป
โครงสร้าง prompt สำหรับสั่ง AI ทำระบบ real-time ให้ไม่พังง่าย
เพื่อให้คุณนำไปปรับใช้กับ Claude Code, Cursor หรือเครื่องมือตัวอื่นได้ทันที สามารถใช้โครงสร้างคำสั่ง 3 ส่วนนี้เป็นต้นแบบในการสั่งงาน
- คำสั่งเชื่อมต่อข้อมูลเฉพาะจุด: ให้เชื่อมต่อการรับข้อมูลแบบ real-time ที่หน้าแสดงรายการโดยรับเฉพาะ event การเพิ่มและแก้ไขข้อมูลที่ตรงกับรหัสห้องปัจจุบัน เมื่อได้รับข้อมูลใหม่ให้นำไปรวมกับ state เดิมโดยไม่ต้องโหลดข้อมูลทั้งหน้าใหม่ และอย่าให้กระทบกับค่าในช่อง input ที่ผู้ใช้กำลังพิมพ์อยู่
- คำสั่งป้องกันการเชื่อมต่อซ้ำซ้อน: ให้ตรวจสอบการเขียนคำสั่งเชื่อมต่อทั้งหมดว่ามีฟังก์ชันยกเลิกการเชื่อมต่อ หรือ unsubscribe เมื่อผู้ใช้ปิดหน้านี้หรือเปลี่ยนไปหน้าอื่น เพื่อป้องกันไม่ให้เปิดการเชื่อมต่อซ้ำซ้อนหลายเส้นและป้องกัน memory รั่วไหล
- คำสั่งจัดการเมื่อสัญญาณหลุดหรือพักหน้าจอมือถือ: ให้เพิ่มการตรวจจับเมื่อหน้าเว็บกลับมาแสดงผลบนหน้าจออีกครั้งหรือเมื่อเครือข่ายกลับมาใช้งานได้ หากการเชื่อมต่อหลุดไปให้ต่อสัญญาณใหม่และดึงข้อมูลล่าสุดมาปรับให้ตรงกับฐานข้อมูล
ปัญหาที่พบบ่อยเมื่อทำเว็บ real-time ด้วย AI และวิธีตรวจสอบก่อนเปิดใช้งาน
ก่อนนำเว็บไปให้ลูกค้า เพื่อนร่วมงาน หรือผู้ใช้งานจริงเปิดพร้อมกัน ควรตรวจสอบจุดเสี่ยง 3 ข้อที่ AI มักมองข้ามในการสร้าง code รอบแรก
- การเปิดช่องทางรับข้อมูลซ้ำซ้อนโดยไม่รู้ตัว หาก AI เขียนคำสั่งเปิดรับข้อมูลไว้ในจุดที่ทำงานซ้ำทุกครั้งเมื่อหน้าจอเปลี่ยนค่า จะทำให้เกิดการเชื่อมต่อซ้อนกันหลายชั้น ส่งผลให้เวลามีข้อมูลใหม่เข้ามา 1 รายการ หน้าจอจะแสดงรายการซ้ำกัน 2 ถึง 3 อัน และทำให้โควตาการเชื่อมต่อของ backend เต็มอย่างรวดเร็ว วิธีตรวจสอบคือให้เปิดหน้าต่างตรวจสอบการทำงานของ browser ดูว่ามีการส่งสัญญาณเชื่อมต่อซ้ำหลายรอบหรือไม่
- ข้อมูลทับกันเมื่อมีคนกดปุ่มพร้อมกัน ในกรณีที่ผู้ใช้ 2 คนกดตัดจำนวนสินค้าชิ้นเดียวกันในเสี้ยววินาทีเดียวกัน หาก AI เขียนคำสั่งให้เอาตัวเลขบนหน้าจอของแต่ละคนไปบันทึกทับลงใน database โดยตรง ตัวเลขสุดท้ายจะผิดพลาด วิธีแก้คือต้องสั่งให้ AI ส่งเฉพาะจำนวนที่ต้องการเพิ่มหรือลดไปคำนวณที่ฝั่ง database แทนการส่งค่าสุทธิจากหน้าจอไปเขียนทับ
- การลืมจำกัดสิทธิ์การรับฟังข้อมูล แม้หน้าเว็บจะแสดงเฉพาะข้อมูลของห้องตัวเอง แต่ถ้าไม่ได้ตั้งค่าสิทธิ์ในระดับ database ให้รัดกุม ผู้ที่มีความรู้ทางเทคนิคอาจดักฟังข้อมูลของห้องอื่นได้หากเป็นข้อมูลส่วนตัว เช่น บันทึกค่าใช้จ่ายหรือข้อความสนทนา จึงต้องสั่ง AI ให้ตรวจสอบการตั้งค่าสิทธิ์การเข้าถึงข้อมูลควบคู่กันเสมอ
วิธีทดสอบที่ง่ายและได้ผลดีที่สุดสำหรับคนทำเว็บคนเดียว คือการเปิดหน้าเว็บเดียวกันบนคอมพิวเตอร์ 1 หน้าจอ คู่กับหน้าต่างไม่ระบุตัวตนอีก 1 หน้าจอ หรือเปิดบนโทรศัพท์มือถือที่ใช้สัญญาณเครือข่ายมือถือควบคู่กัน จากนั้นลองทดสอบเพิ่มข้อมูล แก้ไขข้อมูล ปิดสัญญาณเครือข่ายชั่วคราวแล้วเปิดใหม่ รวมถึงลองพิมพ์ข้อความค้างไว้ในจอที่ 1 แล้วกดส่งข้อมูลจากจอที่ 2 หากหน้าจอทั้ง 2 ฝั่งแสดงผลตรงกันโดยไม่มีข้อมูลหายและไม่ต้องกดปุ่ม refresh ก็พร้อมเปิดให้ผู้ใช้จริงเข้ามาใช้งานร่วมกันได้อย่างมั่นใจ