Closed cfjedimaster closed 9 years ago
Oh wow, it does NOT unzip. I really thought it did.
And my first attempt to unzip failed, probably cuz I passed a string for destinationdir:
ContentSync.unzip(data.localPath, "kittenimages/", function() {
Ok, I apologize for the noise. data.localPath is a directory - it was so long in my Safari console I had assumed it ended with my zip and it was just the file.
Still not having any luck actually using any of these resources though. Here is what I've tried:
sync.on('complete', function(data) {
console.dir(data);
var imageUrl = "file://" + data.localPath + "/BXb4gfYIEAAZNcO.jpg";
console.log(imageUrl);
imageDiv.innerHTML = "<p>ray test <img src='" + imageUrl+"'>";
});
I've even tried making a directoryEntry object from data.localPath, but it fails too. I've completely been unable to actually use any assets from the zip so far. :\
Ugh, this is so frustrating. So is data.localPath a directory? Is it the zip file I downloaded? I've tried to open it as a dir (failed) and a file (failed) and nothing seems to work.
AHAH! Ok, so the issue was how I zipped. I zipped the directory in OSX by right clicking. This made a zip file with 2 entries, a _MACOSX type thing (not the exact name) and the folder itself. It was NOT a zip of images where each image was at root. I had to do a lot of digging but that I finally got it working so that given I've used ID kittenZip, I can easily address an image like so:
var imageUrl = "file://" + data.localPath + "/BXb4gfYIEAAZNcO.jpg";
imageDiv.innerHTML = "<p>ray test <img src='" + imageUrl+"'>";
So my take away from this is the docs should make it clear that given a source of zip file X and ID Y, your assets end up at data.localPath + (entry from X).
Hi @cfjedimaster
Ya, sorry - the docs could definitely be more clear on how to use. The whole zipping of an archive and what it should look like on unzip even caused us troubles when we were developing it - seems like everyone has their own idea how that should look. And to answer a few q's from above: 1) Do you need zip?
2) What's with the unzip function?
Are there any limits on the size of the zip file?
How is the unzip performance? From using the cordova-plugin-zip I know it can take minutes to unzip a folder with a couple of thousands of small map tiles.
No (virtual) limit for the size of the zip but obviously the bigger the slower it is to extract.
same performance as cordova-plugin-zip
While I know there is no hard and fast rule, I suggest the docs at least give a warning about watching the size of the zip and perhaps giving some guidance to how big is too big.
On Thu, May 21, 2015 at 7:46 PM, Anis Kadri notifications@github.com wrote:
No (virtual) limit for the size of the zip but obviously the bigger the slower it is to extract.
same performance as cordova-plugin-zip
— Reply to this email directly or view it on GitHub https://github.com/phonegap/phonegap-plugin-contentsync/issues/20#issuecomment-104462567 .
Raymond Camden, Developer Advocate for MobileFirst at IBM
Email : raymondcamden@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden
@cfjedimaster thank you for the debugging, I was hoping it would solve my issues as well, yet my first attempts failed
First of all, what's the "id" for? - I considered that it could be the zip folder name, but i'm guessing that's not the case
I've tested both naked zip files or foldered zip files, none worked
Can't import a script that I contentsync from a zip, I've also tested prepending "file:/" / "file://" - none worked
I guess I should also start with images first and go on from there :)
@kaansoral the id
is the extract folder indeed. On complete
you get a full path to that id
folder. In a future version you will get a file://
based URL. If by naked
you mean flat (no subfolders) then the content of your archive will just be extracted to PERSISTENT_STORAGE_PATH/ID
and you can access the content of your archive with that path. If your zip archive has subfolders than obviously you will access your subfolder(s) by using PERSISTENT_STORAGE_PATH/ID/subfolder
. PERSISTENT_STORAGE_PATH/ID
is what the sync
method always returns.
Thanks for the info :)
I've finally managed to solve the issue for my usage, here are my notes: 1) file:// gets prepended to the /User* folder, I was making it file://User instead of file:///User as it should have been 2) although I was just zipping files, the folder was automatically adopted, which I didn't notice (I'm using the "zip" command, I thought specifying files would zip them at the top level) 3) get parameters shouldn't be added to static files (duh :)
So it's all user error-ish :)
The docs for the complete event seem to imply that the plugin will unzip for you. I think it needs to be made more clear. To be honest, the section that begins: "ContentSync.unzip || Zip.unzip - ContentSync.download" is confusing.
For example: "However, it supports the same interface so you don't have to install both."
Both? So am I supposed to install another zip plugin? Or are you saying ContentSync has a zip/unzip API built in so if I need it for some random other purpose, I don't need to install a separate zip plugin?
It seems to imply that if you are using another zip plugin, it may interfere. When I read this, I thought, oh, so I'm supposed to unzip myself? But then the "complete" doc says your given paths so it must not be required. So then why does ContentSync have a download API? What's the point of it compared to sync?
I apologize for the vagueness of this bug - as I said - I'm a bit confused by this part. :)