Bijna elk aspect van app-ontwikkeling omvat een element van het verzenden of ontvangen van gegevens. Beginnend met de basis, moet u een MVC-framework gebruiken om u te helpen bij het ontwerpen en implementeren van uw app, zodat de gegevens volledig gescheiden zijn van de weergave van de app op die gegevens (zie MVC-architectuur ).
U moet ook nadenken over de manier waarop gegevens worden verwerkt wanneer uw app offline is (zie Eerst offline ). In dit document worden kort de opslagopties geïntroduceerd voor het lokaal verzenden, ontvangen en opslaan van gegevens; In de rest van het document ziet u hoe u de bestandssysteem- en synchronisatiebestandssysteem-API's van Chrome gebruikt (zie ook fileSystem API en syncFileSystem API ).
Opbergmogelijkheden
Verpakte apps gebruiken veel verschillende mechanismen om gegevens te verzenden en te ontvangen. Voor externe gegevens (bronnen, webpagina's) moet u op de hoogte zijn van het Content Security Policy (CSP) . Net als bij Chrome-extensies kunt u cross-origin XMLHttpRequests gebruiken om met externe servers te communiceren. Ook kunt u externe pagina's isoleren, zodat de rest van uw app veilig is (zie Externe webpagina's insluiten ).
Wanneer u gegevens lokaal opslaat, kunt u de Chrome Storage API gebruiken om kleine hoeveelheden tekenreeksgegevens op te slaan en IndexedDB om gestructureerde gegevens op te slaan. Met IndexedDB kunt u JavaScript-objecten in een objectarchief bewaren en de indexen van de winkel gebruiken om gegevens op te vragen (voor meer informatie, zie HTML5 Rock's Simple Todo List Tutorial ). Voor alle andere soorten gegevens, zoals binaire gegevens, gebruikt u de Filesystem- en Sync Filesystem-API's.
De Filesystem- en Sync Filesystem-API's van Chrome breiden de HTML5 FileSystem API uit. Met de Filesystem API van Chrome kunnen apps een sandboxgedeelte van het lokale bestandssysteem van de gebruiker maken, lezen, navigeren en ernaar schrijven. Een app voor het delen van foto's kan bijvoorbeeld de Filesystem API gebruiken om alle foto's die een gebruiker selecteert, te lezen en te schrijven.
Met de Sync Filesystem API van Chrome kunnen apps gegevens opslaan en synchroniseren op de Google Drive van een gebruiker, zodat dezelfde gegevens beschikbaar kunnen zijn voor verschillende clients. Een teksteditor-app in de cloud kan bijvoorbeeld automatisch nieuwe tekstbestanden synchroniseren met het Google Drive-account van een gebruiker. Wanneer de gebruiker de teksteditor in een nieuwe client opent, pusht Google Drive nieuwe tekstbestanden naar die instantie van de teksteditor.
Met behulp van de Chrome-bestandssysteem-API
Toestemming voor bestandssysteem toevoegen
Om de File System API van Chrome te gebruiken, moet u de machtiging 'fileSystem' aan het manifest toevoegen, zodat u toestemming van de gebruiker kunt verkrijgen om persistente gegevens op te slaan.
"permissions": [
"...",
"fileSystem"
]
Gebruikersopties voor het selecteren van bestanden
Gebruikers verwachten dat ze bestanden op dezelfde manier selecteren als altijd. Ze verwachten op zijn minst een 'kies bestand'-knop en een standaard bestandskiezer. Als uw app veel gebruik maakt van bestandsoverdracht, moet u ook slepen en neerzetten implementeren (zie hieronder en bekijk ook Native HTML5 Drag and Drop ).
Het pad van een fileEntry verkrijgen
Om het volledige pad te krijgen van het bestand dat de gebruiker heeft geselecteerd, fileEntry , roept u getDisplayPath() aan:
function displayPath(fileEntry) {
chrome.fileSystem.getDisplayPath(fileEntry, function(path) {
console.log(path)
});
}
Drag-and-drop implementeren
Als u selectie via slepen en neerzetten moet implementeren, is de bestandscontroller voor slepen en neerzetten ( dnd.js ) in het voorbeeld van bestandssysteemtoegang een goed startpunt. De controller maakt via slepen en neerzetten een bestandsinvoer van een DataTransferItem . In dit voorbeeld is de fileEntry ingesteld op het eerste verwijderde item.
var dnd = new DnDFileController('body', function(data) {
var fileEntry = data.items[0].webkitGetAsEntry();
displayPath(fileEntry);
});
Een bestand lezen
De volgende code opent het bestand (alleen-lezen) en leest het als tekst met behulp van een FileReader object. Als het bestand niet bestaat, wordt er een fout gegenereerd.
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);
});
});
});
Een bestand schrijven
De twee gebruikelijke gebruiksscenario's voor het schrijven van een bestand zijn "Opslaan" en "Opslaan als". De volgende code maakt een writableEntry van de alleen-lezen chosenFileEntry en schrijft het geselecteerde bestand ernaartoe.
chrome.fileSystem.getWritableEntry(chosenFileEntry, function(writableFileEntry) {
writableFileEntry.createWriter(function(writer) {
writer.onerror = errorHandler;
writer.onwriteend = callback;
chosenFileEntry.file(function(file) {
writer.write(file);
});
}, errorHandler);
});
Met de volgende code wordt een nieuw bestand gemaakt met de functionaliteit 'Opslaan als' en wordt de nieuwe blob naar het bestand geschreven met behulp van de methode 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);
});
Met behulp van de Chrome Sync Filesystem-API
Met behulp van synchronisatiebare bestandsopslag kunnen geretourneerde gegevensobjecten op dezelfde manier worden gebruikt als lokale offline bestandssystemen in de FileSystem API , maar met de toegevoegde (en automatische) synchronisatie van die gegevens met Google Drive.
Toestemming voor synchronisatiebestandssysteem toegevoegd
Om de Sync Filesystem API van Chrome te gebruiken, moet u de machtiging 'syncFileSystem' aan het manifest toevoegen, zodat u toestemming van de gebruiker kunt verkrijgen om persistente gegevens op te slaan en te synchroniseren.
"permissions": [
"...",
"syncFileSystem"
]
Synchroniseerbare bestandsopslag starten
Als u synchronisatiebare bestandsopslag in uw app wilt initiëren, roept u eenvoudigweg syncFileSystem.requestFileSystem aan. Deze methode retourneert een synchroniseerbaar bestandssysteem dat wordt ondersteund door Google Drive, bijvoorbeeld:
chrome.syncFileSystem.requestFileSystem(function (fs) {
// FileSystem API should just work on the returned 'fs'.
fs.root.getFile('test.txt', {create:true}, getEntryCallback, errorCallback);
});
Over de status van bestandssynchronisatie
Gebruik syncFileSystem.getFileStatus om de synchronisatiestatus voor een huidig bestand op te halen:
chrome.syncFileSystem.getFileStatus(entry, function(status) {...});
Statuswaarden voor bestandssynchronisatie kunnen een van de volgende zijn: 'synced' , 'pending' of 'conflicting' . 'Gesynchroniseerd' betekent dat het bestand volledig gesynchroniseerd is; er zijn geen lokale wijzigingen in behandeling die niet zijn gesynchroniseerd met Google Drive. Er kunnen echter wijzigingen in behandeling zijn aan de Google Drive-kant die nog niet zijn opgehaald.
'In behandeling' betekent dat er in het bestand wijzigingen in behandeling zijn die nog niet zijn gesynchroniseerd met Google Drive. Als de app online draait, worden lokale wijzigingen (vrijwel) onmiddellijk gesynchroniseerd met Google Drive en wordt de gebeurtenis syncFileSystem.onFileStatusChanged geactiveerd met de status 'synced' (zie hieronder voor meer details).
De syncFileSystem.onFileStatusChanged wordt geactiveerd wanneer de status van een bestand verandert in 'conflicting' . 'Conflicterend' betekent dat er tegenstrijdige wijzigingen zijn in zowel de lokale opslag als Google Drive. Een bestand kan deze status alleen hebben als het conflictoplossingsbeleid is ingesteld op 'manual' . Het standaardbeleid is 'last_write_win' en conflicten worden automatisch opgelost door het eenvoudige last-write-win-beleid. Het conflictoplossingsbeleid van het systeem kan worden gewijzigd door syncFileSystem.setConflictResolutionPolicy .
Als het beleid voor conflictoplossing is ingesteld op 'manual' en een bestand de status 'conflicting' heeft, kan de app het bestand nog steeds lezen en schrijven als een lokaal offline bestand, maar worden de wijzigingen niet gesynchroniseerd en blijft het bestand behouden. los van wijzigingen op afstand die op andere clients zijn aangebracht totdat het conflict is opgelost. De eenvoudigste manier om een conflict op te lossen is door de lokale versie van het bestand te verwijderen of de naam ervan te wijzigen. Dit dwingt ertoe dat de externe versie wordt gesynchroniseerd, de conflicterende status wordt opgelost en de onFileStatusChanged gebeurtenis wordt geactiveerd met de status 'synced' .
Luisteren naar wijzigingen in de gesynchroniseerde status
De gebeurtenis syncFileSystem.onFileStatusChanged wordt geactiveerd wanneer de synchronisatiestatus van een bestand verandert. Stel bijvoorbeeld dat een bestand wijzigingen in behandeling heeft en de status 'in behandeling' heeft. Mogelijk bevond de app zich in de offline-status, zodat de wijziging op het punt staat te worden gesynchroniseerd. Wanneer de synchronisatieservice de in behandeling zijnde lokale wijziging detecteert en de wijziging uploadt naar Google Drive, activeert de service de gebeurtenis onFileStatusChanged met de volgende waarden: { fileEntry:a fileEntry for the file, status: 'synced', action: 'updated', direction: 'local_to_remote' } .
Op dezelfde manier kan de synchronisatieservice, ongeacht de lokale activiteiten, wijzigingen op afstand detecteren die door een andere client zijn aangebracht, en de wijzigingen downloaden van Google Drive naar de lokale opslag. Als de wijziging op afstand bedoeld was om een nieuw bestand toe te voegen, wordt een gebeurtenis met de volgende waarden geactiveerd: { fileEntry: a fileEntry for the file, status: 'synced', action: 'added', direction: 'remote_to_local' } .
Als zowel de lokale als de externe kant conflicterende wijzigingen hebben voor hetzelfde bestand en als het beleid voor conflictoplossing is ingesteld op 'manual' , wordt de bestandsstatus gewijzigd in conflicting status, wordt deze losgekoppeld van de synchronisatieservice en wordt deze pas gesynchroniseerd het conflict is opgelost. In dit geval wordt een gebeurtenis met de volgende waarden geactiveerd: { fileEntry: a fileEntry for the file, status: 'conflicting', action: null, direction: null } .
U kunt voor deze gebeurtenis een luisteraar toevoegen die reageert op eventuele statuswijzigingen. De Chrome Music Player- app luistert bijvoorbeeld naar nieuwe muziek die is gesynchroniseerd vanuit Google Drive, maar nog niet is geïmporteerd naar de lokale opslag van de gebruiker op een bepaalde client. Alle gevonden muziek wordt gesynchroniseerd met die client:
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-gebruik controleren
Om de hoeveelheid gegevens te controleren die door de API wordt gebruikt, vraagt u de lokale sandbox-map van de app op of de gebruiksbytes die worden geretourneerd door syncFileSystem.getUsageAndQuota :
chrome.syncFileSystem.getUsageAndQuota(fileSystem, function (storageInfo) {
updateUsageInfo(storageInfo.usageBytes);
updateQuotaInfo(storageInfo.quotaBytes);
});
U kunt ook kijken naar de opslag van de synchronisatie-backend-service van de gebruiker (in Google Drive). Gesynchroniseerde bestanden worden opgeslagen in een verborgen Google Drive-map, Chrome Syncable FileSystem . De map wordt niet weergegeven in uw lijst 'Mijn schijf', maar is toegankelijk door te zoeken op de mapnaam in het zoekvak. (Houd er rekening mee dat het niet gegarandeerd is dat de lay-out van de externe map achterwaarts compatibel blijft tussen releases.)