A part of my iOS app is to perform uploads of large files to a server. Internet connection of my users is not always ideal.
Is there any way I can perform resumable uploads?
P.S. Request type is HTTP, but if it doesn't support it, it's possible to switch.
check this out:
https://developers.google.com/youtube/2.0/developers_guide_protocol_resumable_uploads
Related
With the Dropbox Sync API there was a method [DBFile writeContentsOfFile] which would sync the file at a later time if the internet connection was offline.
Is there a similar function in the new Dropbox API v2?
I've found a method on DBFilesRoutes -uploadData:inputData:, which works fine for normal upload, but fails with an error if there's no internet connection...and unfortunately it doesn't sync later when the connection is restored.
Perhaps using DBFilesRoutes -uploadSessionStartData: is the solution (which I'll attempt shortly).
No, unfortunately the official Dropbox API v2 SDKs don't offer offline support like that. We'll consider it a feature request.
The difference between uploadData and uploadSessionStartData is that uploadData is for uploading files in one call, whereas uploadSessionStartData is used along with uploadSessionAppendV2Data and uploadSessionFinishData to upload larger files in multiple pieces.
How can we send large video files to WebDav Server from iOS app. Basically I am trying to record the video and need to send it to the WebDav Server. Do I need to send as a streaming video? What are the complexities that we need to consider while sending the large video files to WebDav server. I searched for solution but no luck so far. Do we need to use any WebDav clients available for iOS to send video files to WebDav Server ?
If you want to upload the video after it has finished recording then its an ordinary PUT which you can do with any webdav client. The size of the file is only an issue to the extent that size is for any type of file.
If you want to upload as its being recorded then thats quite difficult because most video formats have header information which cant be produced until the end of file is reached.
So if your requirement is to upload progressively you might need to encode to HLS (HTTP Live Streaming) which emits self contained video chunks (usually 3 second segments) and a playlist file that HLS clients know how to use to reassemble as a single continuous playback.
This is an efficient way to enable almost live one-to-many video streaming through a webdav server. I've implemented it on kademi.co, works a treat
I am building an app for iOS 7 that allows the user to select pictures and upload these to a server. In a perfect world the user would choose the pictures, press upload and be able to close the app.
I looked in to NSURLSession to establish this but it seems to only take a file. Is there any way i can send my NSData like in a NSURLRequest? Also, when not connected to the internet, is there any way i can make the app poll for an internet connection in the background and make it send the pictures when connection is established? I don't think was possible using earlier versions of iOS but iOS 7 seems to have some new options regarding background tasks.
Thanks in advance for any help!
A couple of thoughts:
You are correct that background uploads must use a file. So just save the NSData to a file (e.g. with writeToFile method), and then use that file path.
Regarding checking for Internet connection, the background NSURLSession takes care of that for you, so, no, you don't have to do that.
Regarding background uploads in earlier iOS versions, you could initiate the upload, but explicitly request a little more time to complete this finite-length task while the app runs in the background with UIBackgroundTaskIdentifier. See Executing a Finite-Length Task in the Background discussion in the App States and Multitasking section of the iOS App Programming Guide.
This isn't quite as robust as the new background NSURLSession functionality (which is more clever about applying discretionary logic so your app doesn't significantly adversely affect foreground apps, controlling whether it's permissible to do the upload over cell connection, allowing longer-length requests, working even if your app was terminated (for example, due to memory pressure), etc.). But UIBackgroundTaskIdentifier is a possible solution for iOS versions prior to 7 where you want to give an upload request a chance to complete even though the user has left your app.
Re: your comment about the "GOOD Dynamics SDK", I looked at it quickly. It does allow SDK-based app-to-app document sharing. I don't know if that means it writes a single encrypted on-disk file in the process, or if it uses an encrypted folder to store everything. If you had iOS access to that file, and a way to decrypt it on the server, then you'd have a chance of using the file-based background upload magic.
I´ve been struggling to get AirPlay to work with encrypted streams playing in AVPlayer.
Reading this page by Apple doesn´t do me much good.
Serve keys from a protected HTTPS realm. Before playback begins, your
app can use NSURLConnection to authenticate itself, providing
credentials that are kept hidden.
I could only get this to work in the simulator. Not on the device.
Use cookies over HTTPS. Your app can make a connection to an HTTPS
server and authenticate the application in an application-defined way.
Your server can then issue a cookie that applies to the key URLs. You
should set the cookie to expire long after playback is complete. The
server must then require the presence of a valid session cookie in
future GET requests for the keys.
For maximum reliability, if the expiration date is in the near future, the server should
update the cookie’s expiration date in its response to future GET requests.
Haven´t actually tried this since I don´t have direct access to the server setup, but I am going to if no other answers appear.
Specify the keys in the .m3u8 files using an application-defined URL
scheme. The app should register a custom NSURLProtocol to handle
requests for those URLs. The player then calls back into your app when
it needs to load a key URL; your app can then obtain the key using a
secure side channel and can provide it to the player.
This doesn´t seem to work because AVPlayer HTTP connections bypass the NSURLProtocol system completely. You just can´t intercept any of the HTTP requests made by the AVPlayer.
I would be eternally grateful if anyone has a way of solving the encryption key serving problem in a manner that works with AVPlayer and AirPlay.
Seems like the trouble I was wrestling with went away with the iOS 5.1.1 update and the following Apple TV update. The iOS 5.1.1 update was not enough to fix the issue on it´s own, but together with the subsequent Apple TV update all is fine and dandy once again.
It is now enough to implement your own loopback server as I have described in an earlier question.
I am currently developing an iPhone app, in which involves downloads of up to 300 mb.
I have been told by my hosting service that my server does not support range header requests. However, when I download a file from my server using a download client, like safari download manager, resume options are available and work.
Does this mean that they have a work around for servers that don't support range header requests and that I could possibly implement into my iPhone app? Or are they using a technique too complex to implement into the iPhone.
If you know of a technique code samples will be greatly appreciated.