What's the best approach to use background transfer to upload assets from gallery?
Seems like uploadTaskWithRequest:fromData: doesn't work with NSURLSession created with backgroundSessionConfiguration since it causes an exception: "Terminating app due to uncaught exception 'NSGenericException', reason: 'Upload tasks in background sessions must be from a file". Judging from the exception description background transfer shouldn't work with streamed upload tasks too.
Fair enough. uploadTaskWithRequest:fromFile: is the first thing that comes to mind when you think about uploading data that you already have on the disk. But the NSURLSession Class Reference tells us that this method works only with file urls, but when you get asset's url path it starts from "assets-library://asset/..." and providing this path doesn't work too.
So it seems that the only option left is to copy file from the assets library into a temporary directory, and provide its file url to uploadTaskWithRequest:fromFile:. But it doesn't make any sense because you already have asset file saved on your disk.
Am I missing something?
Update:
Talked with Apple engineer at Tech Talks event and he confirmed that background NSURLSession supports only file urls. So indeed, you need to copy asset library into a temporary directory, and provide its file url to uploadTaskWithRequest:fromFile: to upload it with background NSURLSession.
This behavior may change in the future though.
They also say somewhere in documentation that
Upload/download urls support only file http https schemes. Background supports only http/https.
I believe that core data and assets library urls despite being technically valid urls aren't really urls, and most likely aren't implemented by creating custom NSurlprotocol-s.
So I am inclined to believe that you should write the asset to some file and pass a URL to that file to upload task.
I'm working on a project that uploads assets as well and I have just begun converting it to nsursession using background session. So I'll try this out for myself later today to prove the theory.
Related
I have read Google Drive API documentation but I'm not able to understand the following:
Can files and folder be created and modified on drive in background of app?
My application needs working of drive in background.
For Files:
If you will check "Working with File Contents":
Lifecycle of a Drive file
The Drive Android API lets your app access files even if the device is offline. To support offline cases, the API implements a sync engine, which runs in the background to upstream and downstream changes as network access is available and to resolve conflicts.
Check this image from the document.
The lifecycle of a DriveFile object:
Perform an initial download request if the file is not yet synced to the local context but the user wants to open the file. The API handles this automatically when a file is requested.
Open the contents of a file. This creates a temporary duplicate of the file's binary stream which is only available to your application.
Read or modify the file contents, making changes to the temporary duplicate.
Commit or discard any file content changes that have been made.
If there are changes, the file contents are queued for upload to sync them back to the server.
Google API does support running in background. For folders there is no documentation regarding creating of folder can be done in background, but I think same implementation can be done.
I hope this helps.
I have a log server, where users upload archives and view their content online when needed. Currently the server unzips files, right after receiving them. Unfortunately, my peers consumed all the drive space I had. I can free up a lot of space, if there's a way of storing ZIP archives, but feeding them to users as HTML page (same as default Apache's file browser).
I know there are solutions relying on JS, like:
http://gildas-lormeau.github.io/zip.js/demos/demo2.html
https://stuk.github.io/jszip/
or I can unzip them on demand at server side and provide link to a temporary folder. However, some time ago I've heard a browser can view an archive content if proper headers are sent from Apache/nginx. Apache's mod-deflate doesn't help much here and I can't find other docs - perhaps it's not possible after all?
Cheers.
I have tried creating war file for a play2.1.1 application following the instructions given in the github link - https://github.com/dlecan/play2-war-plugin/
However it fetches the plugins files from online repository and its been referenced in the play program. This method works only if the internet is connected.
Can i download the actual plugin file from this site and save it in my local system and generate a play war file offline?
Partially Yes. You need to go online only once to get all the dependencies downloaded. Once you are done, then you can work completely offline. Also I would like to mention this link: http://brainstep.blogspot.in/2013/10/how-to-install-play-2-war-bare-minimum.html
There is no official way for doing this, but if that aren't to much files, you can use Fiddler Web Debugger to look what files get downloaded, save them to your hard disk and then activate Fiddler's Auto responder. Everytime the Application requests the Files from the Server, Fiddler replies with the Files on your Hard disk.
Folks:
I'm creating an app using Node Webkit. The purpose of this app is to display images and pdfs. The app needs to download those files from a central repository, and cache them locally. When the app runs offline, the files should still be available, and displayed.
On the face of it, this sounds like appcache is the answer - and that indeed is where I was heading when this was a pure webapp in a browser. However, now I've discovered node-webkit, and here we are.
node-webkit's GitHub wiki states:
"However, application cache is designed for browser use, for apps using node-webkit, it's less useful than the other two method, read HTML5 Application Cache if you want to use it."
But doesn't say why.
I've also researched node.js filesystem - but that seems like a whole magnitude of complexity above what I need.
Can anyone point me in a sensible direction?
Thanks.
It has to do with the nature of App Cache itself.
You specify a manifest file that lists all the static assets required for your app to run offline. You don't have any programmatic access to the cache to add and remove files via JS.
So for a node-webkit app, it'd make more sense to fetch these files and store them in the Application Support folder (Or AppData, depending on the platform). That's where the node.js part is really useful, the file IO stuff.
So i got successfully working Paperclip and S3 uploading in RoR 3, but it turns out that some images are prompted to download and others can be viewed in the browser. What determines this behaviour?
Part of this could be browser-specific behavior based upon the MIME file type that the server is sending your browser. .png files are most often the culprit for forced download. See this SO question about the issues between IE uploads, old MIME types, etc.
If it is inconsistent on the type of picture, there is a way you can force a file to be downloaded, but no good way to force an image to be viewed in the browser.
Edit: I know that the forced download isn't rails specific, so here is the rails-specific version
Is one of the following helps you?
Paperclip Force Download
Rails 'link_to' to Download An Image Immediately Instead of Opening it in the Browser
Both of them says to send the file to the browser as attachment.