API พื้นที่เก็บข้อมูล

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

นอกจากนี้ คุณต้องคำนึงถึงวิธีจัดการข้อมูลเมื่อแอปออฟไลน์ (โปรดดูออฟไลน์ก่อน) เอกสารนี้จะแนะนำตัวเลือกพื้นที่เก็บข้อมูลสำหรับการส่ง รับ และบันทึกข้อมูลภายในเครื่อง เวลา ส่วนที่เหลือของเอกสารแสดงวิธีใช้ File System API และ Sync File System API ของ Chrome (ดูเพิ่มเติม) fileSystem API และ syncFileSystem API)

ตัวเลือกพื้นที่เก็บข้อมูล

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

เมื่อบันทึกข้อมูลไว้ในเครื่อง คุณสามารถใช้ Chrome Storage API เพื่อบันทึกสตริงจำนวนเล็กน้อยได้ และ IndexedDB เพื่อบันทึกข้อมูลที่มีโครงสร้าง ด้วย IndexedDB คุณสามารถยืนยันออบเจ็กต์ JavaScript ไปยัง จัดเก็บและใช้ดัชนีของร้านค้าเพื่อค้นหาข้อมูล (หากต้องการเรียนรู้เพิ่มเติม โปรดดูสิ่งที่ต้องทำอย่างง่ายอย่างง่ายของ HTML5 Rock) แสดงรายการบทแนะนำ) สำหรับข้อมูลประเภทอื่นๆ ทั้งหมด เช่น ข้อมูลไบนารี ให้ใช้ระบบไฟล์และการซิงค์ Filesystem API

Filesystem API และ Sync Filesystem API ของ Chrome ขยาย HTML5 FileSystem API พร้อม Filesystem API แอปสามารถสร้าง อ่าน ไปยังส่วนต่างๆ และเขียนในส่วนแซนด์บ็อกซ์ของ ระบบไฟล์ในเครื่อง ตัวอย่างเช่น แอปแชร์รูปภาพสามารถใช้ Filesystem API เพื่ออ่านและเขียน รูปภาพที่ผู้ใช้เลือก

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

การใช้ Chrome Filesystem API

กำลังเพิ่มสิทธิ์ในระบบไฟล์

หากต้องการใช้ File System API ของ Chrome คุณต้องเพิ่ม "fileSystem" ในไฟล์ Manifest ว่าคุณขอรับสิทธิ์จากผู้ใช้เพื่อจัดเก็บข้อมูลถาวรได้

"permissions": [
  "...",
  "fileSystem"
]

ตัวเลือกของผู้ใช้สำหรับการเลือกไฟล์

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

การรับเส้นทางของ fileEntry

หากต้องการดูเส้นทางแบบเต็มของไฟล์ที่ผู้ใช้เลือก fileEntry ให้โทรหา getDisplayPath()

function displayPath(fileEntry) {
  chrome.fileSystem.getDisplayPath(fileEntry, function(path) {
    console.log(path)
  });
}

การใช้การลากและวาง

หากคุณต้องการใช้การเลือกแบบลากและวาง ให้ใช้ตัวควบคุมไฟล์แบบลากและวาง (dnd.js) ใน ตัวอย่าง filesystem-access เป็นจุดเริ่มต้นที่ดี ตัวควบคุมสร้างรายการไฟล์ จาก DataTransferItem ผ่านการลากและวาง ในตัวอย่างนี้ fileEntry ได้รับการตั้งค่าเป็น วางรายการแล้ว

var dnd = new DnDFileController('body', function(data) {
  var fileEntry = data.items[0].webkitGetAsEntry();
  displayPath(fileEntry);
});

กำลังอ่านไฟล์

โค้ดต่อไปนี้จะเปิดไฟล์ (อ่านอย่างเดียว) และอ่านเป็นข้อความโดยใช้ออบเจ็กต์ FileReader ถ้า ไม่มีไฟล์อยู่ มีข้อผิดพลาดเกิดขึ้น

var chosenFileEntry = null;

chooseFileButton.addEventListener('click', function(e) {
  chrome.fileSystem.chooseEntry({type: 'openFile'}, function(readOnlyEntry) {

    readOnlyEntry.file(function(file) {
      var reader = new FileReader();

      reader.onerror = errorHandler;
      reader.onloadend = function(e) {
        console.log(e.target.result);
      };

      reader.readAsText(file);
    });
    });
});

การเขียนไฟล์

กรณีการใช้งานทั่วไป 2 กรณีสำหรับการเขียนไฟล์คือ "บันทึก" และ "บันทึกเป็น" โค้ดต่อไปนี้จะสร้าง writableEntry จาก chosenFileEntry แบบอ่านอย่างเดียว และเขียนไฟล์ที่เลือกลงในไฟล์

 chrome.fileSystem.getWritableEntry(chosenFileEntry, function(writableFileEntry) {
    writableFileEntry.createWriter(function(writer) {
      writer.onerror = errorHandler;
      writer.onwriteend = callback;

    chosenFileEntry.file(function(file) {
      writer.write(file);
    });
  }, errorHandler);
});

โค้ดต่อไปนี้สร้างไฟล์ใหม่ที่มี "บันทึกเป็น" และเขียน BLOB ใหม่ลงใน โดยใช้เมธอด writer.write()

chrome.fileSystem.chooseEntry({type: 'saveFile'}, function(writableFileEntry) {
    writableFileEntry.createWriter(function(writer) {
      writer.onerror = errorHandler;
      writer.onwriteend = function(e) {
        console.log('write complete');
      };
      writer.write(new Blob(['1234567890'], {type: 'text/plain'}));
    }, errorHandler);
});

การใช้ Chrome Sync Filesystem API

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

กำลังเพิ่มสิทธิ์สำหรับระบบไฟล์การซิงค์

หากต้องการใช้ Sync Filesystem API ของ Chrome คุณต้องเพิ่ม "syncFileSystem" สิทธิ์ ไฟล์ Manifest เพื่อให้คุณได้รับสิทธิ์จากผู้ใช้ในการจัดเก็บและซิงค์ข้อมูลถาวร

"permissions": [
  "...",
  "syncFileSystem"
]

กำลังเริ่มต้นพื้นที่เก็บข้อมูลไฟล์ที่ซิงค์ได้

หากต้องการเริ่มใช้พื้นที่เก็บไฟล์ที่ซิงค์ได้ในแอป เพียงเรียกใช้ syncFileSystem.requestFileSystem วิธีนี้จะแสดงระบบไฟล์ที่ซิงค์ได้ซึ่งได้รับการสนับสนุนโดย Google ไดรฟ์ เช่น

chrome.syncFileSystem.requestFileSystem(function (fs) {
   // FileSystem API should just work on the returned 'fs'.
   fs.root.getFile('test.txt', {create:true}, getEntryCallback, errorCallback);
});

เกี่ยวกับสถานะการซิงค์ไฟล์

ใช้ syncFileSystem.getFileStatus เพื่อดูสถานะการซิงค์สำหรับไฟล์ปัจจุบัน ดังนี้

chrome.syncFileSystem.getFileStatus(entry, function(status) {...});

ค่าสถานะการซิงค์ไฟล์อาจเป็นค่าใดค่าหนึ่งต่อไปนี้ 'synced', 'pending' หรือ 'conflicting' "ซิงค์แล้ว" หมายความว่าไฟล์ซิงค์สมบูรณ์แล้ว ไม่มีการเปลี่ยนแปลงในระบบที่รอดำเนินการซึ่ง ซิงค์กับ Google ไดรฟ์แล้ว แต่อาจมีการเปลี่ยนแปลงที่รอดำเนินการในฝั่ง Google ไดรฟ์ ยังไม่ได้ดึงข้อมูล

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

syncFileSystem.onFileStatusChanged จะเริ่มทำงานเมื่อสถานะของไฟล์เปลี่ยนเป็น 'conflicting' "ขัดแย้งกัน" หมายความว่ามีการเปลี่ยนแปลงที่ขัดแย้งกันทั้งบนที่เก็บข้อมูลในเครื่องและ Google ไดรฟ์ ไฟล์จะอยู่ในสถานะนี้ได้ก็ต่อเมื่อตั้งค่านโยบายการแก้ไขข้อขัดแย้งเป็น 'manual' นโยบายเริ่มต้นคือ 'last_write_win' และจะแก้ไขความขัดแย้งโดยอัตโนมัติโดย นโยบายง่ายๆ แบบขายตรง นโยบายการแก้ไขข้อขัดแย้งของระบบสามารถเปลี่ยนแปลงได้โดย syncFileSystem.setConflictResolutionPolicy.

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

กำลังฟังการเปลี่ยนแปลงในสถานะที่ซิงค์

เหตุการณ์ syncFileSystem.onFileStatusChanged จะเริ่มทำงานเมื่อสถานะการซิงค์ของไฟล์มีการเปลี่ยนแปลง เช่น สมมติว่าไฟล์มีการเปลี่ยนแปลงที่รอดำเนินการและอยู่ในสถานะ "รอดำเนินการ" อาจมีการนำแอปไปใช้ ในสถานะออฟไลน์เพื่อให้ระบบซิงค์การเปลี่ยนแปลง เมื่อบริการซิงค์ตรวจพบ การเปลี่ยนแปลงในระบบที่รอดำเนินการและอัปโหลดการเปลี่ยนแปลงไปยัง Google ไดรฟ์ บริการจะเริ่มทำงาน onFileStatusChanged เหตุการณ์ที่มีค่าต่อไปนี้ { fileEntry:a fileEntry for the file, status: 'synced', action: 'updated', direction: 'local_to_remote' }

ในทำนองเดียวกัน ไม่ว่ากิจกรรมในเครื่องจะเป็นอย่างไรก็ตาม บริการซิงค์อาจตรวจพบการเปลี่ยนแปลงระยะไกลที่ทำโดย ไคลเอ็นต์อื่น และดาวน์โหลดการเปลี่ยนแปลงจาก Google ไดรฟ์ไปยังพื้นที่เก็บข้อมูลในเครื่อง หากรีโมต การเปลี่ยนแปลงคือการเพิ่มไฟล์ใหม่ เหตุการณ์ที่มีค่าต่อไปนี้จะเริ่มทำงาน { fileEntry: a fileEntry for the file, status: 'synced', action: 'added', direction: 'remote_to_local' }

หากทั้งอุปกรณ์ในเครื่องและระยะไกลมีการเปลี่ยนแปลงในไฟล์เดียวกันที่ขัดแย้งกันและหากมีข้อขัดแย้ง ตั้งค่านโยบายความละเอียดเป็น 'manual' สถานะของไฟล์เปลี่ยนเป็น conflicting คือ ถูกปลดออกจากบริการการซิงค์ และจะไม่ซิงค์ข้อมูลจนกว่าข้อขัดแย้งจะได้รับการแก้ไข ด้วยวิธีนี้ ในกรณีที่เหตุการณ์ที่มีค่าต่อไปนี้เริ่มทำงาน { fileEntry: a fileEntry for the file, status: 'conflicting', action: null, direction: null }

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

chrome.syncFileSystem.onFileStatusChanged.addListener(function(fileInfo) {
  if (fileInfo.status === 'synced') {
    if (fileInfo.direction === 'remote_to_local') {
      if (fileInfo.action === 'added') {
        db.add(fileInfo.fileEntry);
      } else if (fileInfo.action === 'deleted') {
        db.remove(fileInfo.fileEntry);
      }
    }
  }
});

กำลังตรวจสอบการใช้งาน API

หากต้องการตรวจสอบปริมาณข้อมูลที่ API ใช้ ให้ค้นหาในไดเรกทอรีแซนด์บ็อกซ์ในเครื่องของแอป หรือ ไบต์การใช้งานที่แสดงผลโดย syncFileSystem.getUsageAndQuota

chrome.syncFileSystem.getUsageAndQuota(fileSystem, function (storageInfo) {
   updateUsageInfo(storageInfo.usageBytes);
   updateQuotaInfo(storageInfo.quotaBytes);
});

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