The Problem
I am trying output a file from a Chrome Packaged app (using chrome.fileSystem) that I am developing, but all the files are being saved are being created, but with no content no matter what I do. I have researched this for hours and can only seem to find people using the same basic code that I am, and that I can't get to run. Am I missing something obvious here? Is this code running for everyone else, and I should just try to run it on a friends computer? Any help would be appreciated!
What I Have Done So Far:
I am using the code below (from the Chrome developer documentation) in one of my javascript files to try and write some text to a file that the user specifies. As far as I can tell, this should write "1234567890" to whichever file I specify when I run the program, but all of the files are being created properly, but they don't have any content.
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);
});
I have also set the following permissions in my manifest.json file:
"permissions": [
{"fileSystem": ["write"]}
]
Thanks in advance for all your help!
If the errorHandler function isn't defined, that could be the problem. Your code would then crash after the file was created but before the blob was written to it.
Related
EDIT: I found the issue, when I copied the code I also duplicated the function. So I had cloud function "A" and "A Copy" and whenever I would pass information through the respective Pub/Sub, both functions are called and only one goes successfully through. I only did this because I thought having backup code somewhere would be safer and didn't expect it to make it not work.
So I've had a Google Cloud function running for the past 4 months.
Never any issues.
It uploads data I pass to it to FireStore.
I went to edit the code, but before I edited the code I made sure to backup the old code **index.js** and **package.json** just incase something broke.
Added a couple of new lines of code and of course the new code wasn't working so I reverted back to the old code.
However now the old code isn't working now and I'm getting:
Error: Cannot find module 'node-pre-gyp/lib/pre-binding'
so I commented everything and debugged as much as I could and found:
db.collection('LiveExamples5').add
({
Device: split[1],
Index: split[5],
Temperature: temp,
Humidity: split[9],
Raw: split[11],
Resistance: split[13],
VOC: split[15],
VDD: split[17],
Time: Timezz,
});
This is the piece of code that uploads the passed data to Firestore causes the error.
It's strange since this is the old code it's now causing this error and not uploading anything to FireStore now.
I'm not even sure how to install modules into Google Cloud functions.
Any help would be greatly appreciated.
Try adding the dependency of node-pre-gyp to the package.json file.
I'm incredibly new to HTML/Javascript/API's and im trying to make my first chrome extension using coinmarketcaps' public API.
API: https://api.coinmarketcap.com/v2/ticker/?limit=12&sort=rank&convert=ETH
My Code:
console.log("Running");
function setup() {
loadJSON('https://api.coinmarketcap.com/v2/ticker/?
limit=12&sort=rank&convert=ETH', gotData, 'jsonp');
}
setup();
function gotData(data){
console.log(data);
list = data;
}
gotData();
Essentially what I want to do is load in the data and then print the data to my console to make sure that it is in fact loaded. The error that I'm getting when i check the background.js console after uploading the extension is 'loadJSON is not defined'
I don't know if im missing a package or am unable to use such a command but after looking online for a while I can't seem to figure it out. Another thought that I had was maybe it can't be used in a background.js file. Also, I am using Atom software for this project. Let me know if you need any more information, any help is appreciated.
I have a strange problem over here. I have a project built with Parse.com as a backend (using cloudcode to verify some things when a connection to the database is made). Everything works just as it should do.
But here comes the problem. Another developer reported to me that there is something wrong because he is getting 'undefined' every time he tries to call request.object.get('KEY')in CloudCode. This developer uses the exact same codebase as I do.
So I decided to have a look at it. While with my Parse account, every application works fine (even newly created ones), with the Parse account of the other developer, not a single new application we created seems to work with the exact same code. And it is getting even stranger - creating a completely new Parse account and a new application produces the same errors while my personal account and applications continue to work fine.
So what is the problem? We are using CloudCode, and here is sample code (in javascript) of a beforeSave method:
Parse.Cloud.beforeSave('Activity', function(request, response) {
var currentUser = request.user;
var objectUser = request.object.get('fromUser');
if(!currentUser || !objectUser) {
response.error('An Activity should have a valid fromUser.');
} else {
response.success();
}
});
And every time request.object.get('KEY') returns undefined, for every key I previously defined in the iOS code before uploading the PFObject.
Note that with my personal account everything is fine...
I have already seen this thread, however deleting ACL's didn't do the trick. request.object.get() stays undefined while request.useris defined for every tested Parse account except mine.
EDIT 1
I also had a look at the activity object just before it is uploaded, and there all the fields are properly set.
EDIT 2
After removing the cloud code completely, the objects are correctly being uploaded to Parse, with all the fields being the way they were set via the iOS client. So it seems that something is wrong with Parse's cloud code, but as soon as an object passes through cloud code, it looses all its fields.
Finally I was able to solve this. This is definitely a bug in Parse's Javascript SDK. I changed the Javascript SDK version in the global.json back to version "1.4.2" instead of "latest", uploaded this to the cloudcode folder and everything went back to normal.
You can also test other versions, maybe v1.5.0 is working too, but as soon as I found out v1.4.2 worked fine, I didn't try out more recent versions.
EDIT
So, I discovered, that Parse must have changed something in their command line tool. It seems that the global.json file isn't there anymore if you create your CloudCode folder with the most recent version of their command line tool. However, you can manually create it and upload the complete folder to your Parse app.
This is how my CloudCode folder looks like, just for example:
CloudCode folder contains three subfolders
• cloud - containing cloud code files
• config - containing the global.json file
• public - containing the index.html file
The global.json file contains these lines of code:
{
"global": {
"parseVersion": "1.4.2"
},
"applications": {
"YOUR_PARSE_APPS_NAME": {
"applicationId": "YOUR_APP_ID",
"masterKey": "YOUR_APP_MASTER_KEY"
},
"_default": {
"link": "YOUR_PARSE_APPS_NAME"
}
}
}
I am fumbling around with the free Chrome Dev Editor on my Chromebook. I am trying to use the fileSystem to read and write .txt files. It is all very wrapped up, not at all like in C. I can no more tell if I am even allowed to do something, let alone where the proper place is to find out how.
I think the files I can see using the Files thingy are in the sandbox that I am allowed to play in (meaning, folders that are accessible by the app?) The root is called Downloads. Sure enough, if I use all the dot calls and callback arguments for the read, as in the examples at developer.chrome.com/apps/filesystem, it works. But I have to have a prompt
every time for both reads and writes.
A little more Googling came up with this trick: (I think it was here in stackoverflow, in fact) a chrome.runtime call, getPackagedDirectoryEntry, that seems to give me a handle to the folder of my app. Great! That's all I need to not have to go through the prompting. For the readfile, anyway.
But then trying to apply the same trick to the writefile did not work. In fact, it did nothing discernible. No errors, no complaints. Nothing. Even though the write file with prompting works fine (so presumably I have the permissions and Blob construction right.) What to do?
Here is my code:
function test(){
// Samsung 303C Chromebook - Chrome Dev Editor - /Downloads/Daily/main.js
// prompted write
chrome.fileSystem.chooseEntry({type:'saveFile'},function(a){
a.createWriter(function(b){
b.write(new Blob(["Programming fun"],{type:'text/plain'}));
},function(e){trace.innerText = 'error is ' + e;});
});
// unprompted read
chrome.runtime.getPackageDirectoryEntry(function(a){
a.getFile('text.txt',{},function(b){
b.file(function(c){
var d = new FileReader();
d.onloadend = function(){trace.innerText = this.result;};
d.readAsText(c);
});
});
});
// unprompted write - why not?
chrome.runtime.getPackageDirectoryEntry(function(a){
a.getFile('new.txt',{create:true},function(b){
b.createWriter(function(c){
c.write(new Blob(["Miss Manners fan"],{type:'text/plain'}));
},function(e){trace.innerText = 'error is ' + e;});
});
});
}
To be fair, Filesystem API is a big mess of callbacks and it's not unreasonable to get drowned in it.
It's not currently documented, but chrome.runtime.getPackageDirectoryEntry returns a read-only DirectoryEntry, and there is no way to make it writable (it's specifically blacklisted).
You probably don't see an error, because it fails at the getFile stage, for which you don't have an error handler.
Unfortunately, for a Chrome App the only option to write out to a real filesystem is to prompt the user. However, you can retain the entry and ask only once.
If you don't need to write out to the real filesystem but need only internal storage, HTML Filesystem API can help you (yes, it's marked as abandoned, but Chrome maintains it since chrome.fileSystem is built on it).
Extensions additionally have access to chrome.downloads API that enables writing to (but not reading) the Downloads folder.
P.S. What you see in Files app is your "real" local filesystem in ChromeOS + mounted cloud filesystems (e.g. Google Drive)
You can use the basic web Filesystem API. First, add the "unlimitedStorage" permission. Then, copy the packaged files to the sandboxed filesystem, like this:
chrome.runtime.getPackageDirectoryEntry(function(package) {
package.getMetadata(function(metadata) {
webkitRequestFileSystem(PERSISTENT, metadata.size, function(filesystem) {
package.copyTo(filesystem.root)
})
})
})
Summary
Normally I could download a bunch of files, but Chrome Apps won't show the download shelf when a download occurs. What would be the best way of getting around this limitation of Chrome Apps?
Ideas
I could go about this by creating a zip file, but this would require the user to perform an extra step of unzipping the file.
I'm able to silently download the files, and so I could display a prompt to the user when the file is downloaded, but this would require the user to manually search for the file in their downloads folder.
What I've Learned
Everywhere on the internet tells me to use Chrome's download API, but this only works for Chrome extensions and not Chrome apps.
I can't bring up a save as window because 50 save as windows for 50 files is unacceptable
I can, however, bring up a prompt using chrome.fileSystem.chooseEntry({'type': "openDirectory"} to ask the user to choose a directory, but I can't find a way of saving to that directory.
My question is basically the same as How can a Chrome extension save many files to a user-specified directory? but for a Chrome app instead of an extension.
Project and Example Code
The app I'm building will be the same as this webpage I've built, but with a few modifications to make it work as a web-app.
This is how my website solves the problem
let example_pic = "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABcAAAAWCAYAAAArdgcFAAAABmJLR0QA/wD/AP+gvaeTAAAACXBIWXMAAC4jAAAuIwF4pT92AAAAB3RJTUUH3wQGEjEAJqiN6gAACAlJREFUOBEB/gcB+AFHNgf/DQoBAAoBBwAA+wIA/QABAPcG/AAB+QMAAPb/AAf2AAAA+/8A6AH9AP0NAAAGCAEAAPf8AALj+wAZBwQATWE9AFKFcwAAADoA/wC1AIlslgC5s8YA+vT9AAT3+/8AAPQBAAEC+gACBgIABgkOAAH8/gD1+PwAAvkIAP8BAAD9AfcA/w3/APYIAwD+CQIACAb6APj//gAJBw8ADRwkAAAAEwAAAAgA6OYLAOfV9gD04v0A9AIAAAT29v0A/QcAAAQIAwALAv8A+/v7APwCAgD3+/oAAAH2AAL9AwADC/8AAQcDAAYJAQAEAgYA+v8CAP4I+gDe+PYAubXGAPHu+gAACRUA0MXaAMTN0wDwAAAAA/4AAAEiFQP/FxEBABQLBwAF/AUA9AoDAP3+/AD4+vsA+v4BABD8AQAA/gAA9AEAAPQCAgANDAAABggJAAgA+gD37vgABvkKAAfz8wD6/f4A7e78AO39AAABAAAADwAAAAT4+/0A9fMCAAv0AwD3/wIA9QoGAPYH+gACBv8ABP4AAP4DAAAHAAAAA/sAAAMF/gAB/AEAAP7yAPT5/gAA8AQA+vv5APoB/wD0+vwA8P0AAAUAAAAKAwAADRIAAAQJAQAA8/j+APr/9QAGAAEABwMSAPb/AwAE+fwACAD/AAAC/wDx+gEAAAX/AAwAAAD57wAA/PX+AAj+AwD7AAAA/AL7AP/9+wD6+QAABgkAAAX8AAAPDgQAEBf8AAEjEQz/9vv0AAMGAAAKBgEA/PkCAPsGAgD1BAIADQgBAAj8AAD19AAAEQQAAAkJAADy+QAA7/v+ABUEAAAPAf4A/Pv+APgD/gABAAAABwAAABIJFQAJDQIAFyYIAAQUEQ8A6Pb0APD3AAD77f8ABwYEAP3+AQD1A/wA7vYBAAz/AQAM/QAA+vwAAPz6AAAICgAADAUAAAEA/QD8AgEA/wX/AAP+BQAADQIACgYJABQZGgAZERYACxz1AAQgKBQACvD8APfy+wDw6QQA8/f8AP8A7wANA/8A/v8BAAH/AQD8+gEA9/oEAAgEAwDy//gA+gQAAAwG/gAB/QAAAwQFAAgOFQAIDAUAFB4IABcUGwAbDRMADw8CAAQZGx4A/RAFAAPw/AAPBg4A8/gBAPT86gD8/egADP/5AP3+/QAIAggAA/8BAAkAAwD3AvcABwn/AAoHBwAWAQYABwoQAA8VFQAKDxoA+w3zAAgO9gAGBwMAFAYfAAQcHhwAA/L9APYJ9QAUDQ0A7ev+AOzvEwD6/vgA+ALyAAT9BQABDg0ADP3+AA4A9wD5BwwABRIRAAYACwAVDx4AD/8FAAoBBQAKDQgA+P/4AAPwAQD5/e8A3wPwAAQH6/sAFQAMAAII/wAABAAAC/7/ABkPBAD4+wkA+PsBAAkJDQAC8vcADAAMAAcKCgD+CSEA/AT5AAD3AQAH/PkAFAgLAPz68wAJ9+0AEf/8APz9BQD3+gQA/vr9AAQD5+AADvz0AAAB/wAABQEA+/oBAAcAAgARBwoAAQkGAO7x8QAC/fwADQ0MAAEJEAD1//gA//z2APz9DAAEAQEAAPvpAAP9AAAGANgACfUCAPr+HAACAQQAAP/9AAQA69gAAQb+APYBAQD8/v4AAwQVAAMCBQAH//8ACAQHAPv9+gASCgQABAYCAPf9CAAA+/4A+wYBAA0FBQDw+/MA//XoAP789AAJ/P0ADgUXAOwHAQD8+PIA9/v4AAQCB/cA+/oJAP37/gAADAAAEQMCAAIKCQD19vsAB/30ABUQFwD7+u4A+PvyAPz5AQANBf4A8AAAAPf66gD9/fkAAP/uAA8E/wD2/PwA7v34AAoDBQD9CQEAAwAGAAQMGiMA8vD0AAr47AD++gIA/gPtABQFAwD8DAcA/gcMAAz/BAD/CxUA/Pn7ABMJ/gD9/PoA9vr+APX38gD9+fMABQcEAPMNGwAGCvYABvgLAAcF9wAFBP4A8fgEAAIACAQAEhALAAoSHwD9BQ4ACgL4APv0+gD4BAAA+wgNAO0C/QD5+QUA+wYMAPQPEAD5CA8A+QYDAAECCAADB/wA+P4CAPT39AD96vUAFQcLABIIAAAICQgA//8GAAQD+QQAAwIAAAADCADyAgEA9PTsABoA8QD7CAkAEAMBAPoH/wAABgEABwYOAAn8AAACD/sA/P8KAP79AQD9+/cAAff+AAn7/AAQBiIA+/IAAPsREAD+CxEAAxP9AAT8AfgA+v//AAUA/AAYEQAA/AIeAO/59gAH+fUA9/f+AAgCCAACCAMACgb8AAAIBQD09QoAAgIGABEVAgD95w0A/v7yAP0AAAD2+vwA/AcAAPkHDQD9/AoABwABAAT87PoABhEOAP0C+wAWBgEA9QoJAPvpBgAD/vkA+e3+AAgRAQAG9wUA9v8TAAAH9wD9/ggA8/f3AAX/EAALBAEA7QgGAPT1BQD//v4ACxH/AAMJAQADAgEA/ATkAAQHCwkABAENABMJDQD2+esA9gDwAPsAAgATCxQABAUGAAQCBwDtAv8ABvz7APv5AgAJC/wADvr8APr9/wANFwwA+PD5AAT//gACB/4A+Qn7AAUD+AASDAYA9AEQAAQCAg4A+/z2APX4AAD4AAkAA/jvAAf9/QDy8u4ADhEOAPYE9wAFAhEAB/n5AAgCAgAF9f4ACg0DAPX3AQD4BQUAFBIMAAATAQD499gACff+AAj8+AAE/AYAGQcXADGWlu04c4CnAAAAAElFTkSuQmCC"
let a = document.createElement("a");
a.href = example_pic;
document.body.appendChild(a)
a.click();
window.URL.revokeObjectURL(a.href);
a.remove()
I can, however, bring up a prompt using chrome.fileSystem.chooseEntry({'type': "openDirectory"}) to ask the user to choose a directory, but I can't find a way of saving to that directory.
That's what you need to work on.
Suppose you declare all the sub-permissions for the fileSystem API:
"permissions": [
{"fileSystem": ["write", "retainEntries", "directory"]}
]
Then you can:
Get an entry from the user:
chrome.fileSystem.chooseEntry({'type': "openDirectory"}, function(dirEntry) {
// Check for chrome.runtime.lastError, then use dirEntry
});
Retain it, so you can reuse it later without asking the user again:
dirEntryId = chrome.fileSystem.retainEntry(dirEntry);
// Use chrome.storage to save/retrieve it
chrome.fileSystem.restoreEntry(dirEntryId, function(entry) { /* ... */ });
Using the HTML FileSystem API, create files in the directory:
dirEntry.getFile(
"test.txt",
{create: true}, // add "exclusive: true" to prevent overwrite
function(fileEntry) { /* write here */ },
function(e) { console.error(e) }
);