การพัฒนาแอปออฟไลน์เป็นหลัก: ข้อกำหนด สถาปัตยกรรม และปัจจัยด้านต้นทุน

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

เมื่อแอปจำเป็นต้องทำงานแบบออฟไลน์

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

โดยทั่วไป การทำงานแบบออฟไลน์มีความจำเป็นเมื่อผู้ใช้:

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

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

แบ่งข้อกำหนดออกเป็นสามประเภท:

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

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

คำถามสำหรับเวิร์กช็อปเก็บข้อกำหนด

ขอให้ทีมพัฒนาบันทึกข้อมูลต่อไปนี้ก่อนประเมินงาน:

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

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

สถาปัตยกรรมแบบออฟไลน์เป็นหลักเทียบกับแบบรองรับออฟไลน์

คำว่า “ออฟไลน์เป็นหลัก” และ “รองรับออฟไลน์” สื่อถึงลำดับความสำคัญที่แตกต่างกัน

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

โครงสร้างแอปออฟไลน์เป็นหลักโดยทั่วไปประกอบด้วยสี่ส่วน:

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

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

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

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

การจัดเก็บข้อมูล การซิงโครไนซ์ และการจัดการข้อขัดแย้ง

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

การตัดสินใจเรื่องพื้นที่จัดเก็บในเครื่อง

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

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

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

ลำดับการซิงโครไนซ์

กระบวนการซิงโครไนซ์ที่ใช้งานได้จริงมักดำเนินตามลำดับนี้:

1. ตรวจสอบว่ามีการเชื่อมต่อที่ใช้งานได้ แทนที่จะสันนิษฐานว่าไอคอนเครือข่ายหมายถึงเข้าถึงเซิร์ฟเวอร์ได้
2. อัปโหลดการเปลี่ยนแปลงในเครื่องพร้อมคีย์ idempotency เพื่อให้การลองใหม่ไม่สร้างรายการซ้ำ
3. ตรวจสอบความถูกต้องของการเปลี่ยนแปลงแต่ละรายการบนเซิร์ฟเวอร์และส่งผลลัพธ์ที่ชัดเจนกลับมา
4. แก้ไขหรือทำเครื่องหมายข้อขัดแย้งตามกฎทางธุรกิจของระเบียน
5. ดาวน์โหลดการเปลี่ยนแปลงจากเซิร์ฟเวอร์นับจากโทเค็นการซิงโครไนซ์ล่าสุดของอุปกรณ์
6. นำข้อมูลอัปเดตไปใช้กับฐานข้อมูลในเครื่องภายใน transaction
7. ทำเครื่องหมายรายการที่สำเร็จว่าซิงโครไนซ์แล้ว และเก็บข้อผิดพลาดที่ผู้ใช้หรือผู้ดูแลระบบนำไปดำเนินการต่อได้

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

กลยุทธ์จัดการข้อขัดแย้ง

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

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

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

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

สถานะการเชื่อมต่อ ประสบการณ์ผู้ใช้ และความปลอดภัย

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

เวิร์กโฟลว์ที่เชื่อถือได้อาจแสดงสิ่งต่อไปนี้:

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

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

ข้อกำหนดด้านความปลอดภัยสำคัญยิ่งขึ้นเมื่อข้อมูลทางธุรกิจยังคงอยู่ในอุปกรณ์ ให้กำหนดว่า:

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

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

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

ฟีเจอร์ออฟไลน์ส่งผลต่อขอบเขตงาน ต้นทุน และระยะเวลาอย่างไร

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

ปัจจัยที่มีผลต่อต้นทุนโดยทั่วไป ได้แก่:

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

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

ผู้ซื้อปรับปรุงการประเมินได้โดยขอตารางคุณลักษณะ เช่น ตารางนี้:

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

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

ขอให้ทีมสาธิตสิ่งต่อไปนี้:

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

หากการประเมินระบุว่า “รวมโหมดออฟไลน์” โดยไม่บอกพฤติกรรมเหล่านี้ แสดงว่าข้อกำหนดยังไม่ชัดเจนเพียงพอ

ทดสอบพฤติกรรมออฟไลน์ก่อนเผยแพร่

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

สร้างเมทริกซ์การทดสอบที่ครอบคลุมอย่างน้อยกรณีต่อไปนี้:

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

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

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

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

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

คำถามที่พบบ่อย

จำเป็นต้องพัฒนาแอปมือถือแบบออฟไลน์เป็นหลักทุกแอปหรือไม่?

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

แอปออฟไลน์ซิงโครไนซ์ทุกอย่างโดยอัตโนมัติได้หรือไม่?

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

การพัฒนาแอปออฟไลน์มีค่าใช้จ่ายเท่าใด?

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

ฟังก์ชันออฟไลน์ทำงานร่วมกับ API ของบุคคลที่สามและเครื่องมือ AI ได้หรือไม่?

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

ผู้ซื้อจะตรวจสอบได้อย่างไรว่าการรองรับออฟไลน์ใช้งานได้จริง?

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