I have to download large amount of data (anywhere between 300MB - 1GB).
I am currently using **NSURLConnection**to download the data. But, now i am looking at a scenario where the user might loose the internet connection during the download process. Currently i am restarting the entire download process in this scenario, which i think is a very bad way of downloading and a waste of user bandwidth.
Is there a process in which i can manage the downloads with Pause/Resume functionality while downloading.
Here's a tutorial of how to do this on IOS.
Also check documentation. This will require your server to support range headers.
this needs synchronization both at server as well as client side. and i allready told u to use chunks. definetely chunks is the only solution if you want to pause. you will send the server with a chunk id to stop till this i'll get remaing next and next time you will ask from that id.
FIXED SOLUTION :
Fixed broken link and here is the working Tutorial to resume FIle Download file in iOS.
You can use "NSURLSession to pause and resume
Related
I have two 50KB files saved in iCloud Drive. Using FileManager, saved in an iCloud container.
The problem is that they take forever to upload. I waited 2 hours and they are still in this waiting to upload status. Both my iPhone and iPad having this issue.
Is there a way I can force it upload? Or at least put it into priority queue.
I'm building a note app sync feature. And those slow upload makes sync impossible.
I ran into a problem like yours and tried to find the solution. So, I contacted directly to Apple Support.
Here's the suggestion:
First, you have to make sure that your OS version is up to date and your iCloud storage has enough space.
Next, you go to System Preference > Apple ID > uncheck a checkbox in front of iCloud then check it back.
I am after some suggestions on how to reduce the final app size that gets submitted to apple?
Or is there any way to have stuff download after the app is isntalled? so that we can keep the app under 20 meg, but then the app downloads the rest of the program after the user has installed it and run the application?
ta
Daz
If your application uses a lot of image resources, your application could download those images instead of building them into the application.
Theoretically possible. Your app can access the file system, so it can make and save, and later read files.
The deal-breaker I see is that for most purposes, Apple probably wouldn't allow it.
They test the program as-is when you submit it, and they'll notice that it just sits there and tries to download a bunch of stuff from your server. If this takes more than, say, 30 seconds, they'll reject it for usability problems.
If the content downloaded could have been bundled with the program, they'll probably have a problem with that. If you could argue that the downloaded content changes rapidly and is a feature of your app, it might fly, but only if you keep it small..
Sure this is totally possible. Since it is most likely some sort of media that is causing a large file size, either images, video, or audio, you could definitely download them after the fact or supply a download button for users to add these features as "extra" content, if they are not critical to the operation of your app.
One thing to consider is that some users are not on an unlimited data plan. So for politeness, they should know what you are doing.
Also, if you are just over the limit, you might also be able to ship the application with the resources in a zip archive and then decompress the archive in the Documents directory.
In many applications images take lion share of the download size, and they can be greatly reduced with ImageAlpha and ImageOptim.
Check out this case study halving download size of Tweetbot by converting images to a more efficient PNG variant.
I have a location based iOS app and I want to interact with a server every x minutes.
I read this post: Send Data Every 10 minutes
But I have to send an empty header to my server even if there is no location update for a while because I have to read any pending commands from my server and it only writes back if you write first.
This has to work even if the app is running background.
What should be the best way to perform this? Using a timer?
I've already made this kind of stuff on Android but I'm a little stuck on how to do here.
Cheers,
Thierry
You can use a NSTimer when the app is running, but you can't do that when the app is in background. The iOS reference contains all the possible uses of multitasking: link
As you can see, there's a small amount of possible operations (voip, audio or location) that are able to wake up your app.
The docs don't seem to offer any guarantees - I'm just wondering if anyone's had any experience of uploading a large amount data after a user 'backgrounds' an iPhone app.
E.g., recording some audio or video and uploading it while there's the possibility that the user will start another app. Is is reasonable to expect to be able to be able to upload several MB of data in the background, perhaps using the VOPI UIBackgroundMode, which should keep sockets active?
First, uploading anything that is not VoIP data in a VoIP background mode violates Apple's guidelines and will probably get your app rejected. But you still have the option of using the normal background task completion API that gives your app another 10 minutes (at the moment, the amount might change in a future release) to finish a task like an upload.
If a foreground app uses a large amount of bandwidth, it is likely that the OS will give it priority over the background task.
Of course, you cannot rely on your upload being finished. If you run out of time, the system will notify you and you should try to resume the upload when the user reactivates your app. But you can't rely on a stable internet connection anyway, even if your app is in the foreground, so I don't really see the difference.
NO, this is not possible. i agree that it creates problems when you have a long operation to make but it is defiantly not possible.
Our lovely app that downloads mp3s from our server into a local file on the phone then plays from that file was rejected for using too much bandwidth.
I understand the rejection (we are downloading rather than streaming) and don't quibble with their decision... our first priority was quality of user experience.
I am just wondering... what do I do now?
There are no hard and fast rules... Apple just says, "Must not in Apple's reasonable judgment excessively use or unduly burden network capacity or bandwidth".
Anyone have data on what Apple considers reasonable data transfer rates?
Should I fill up the buffer file in short spurts? Should stream the file at a constant rate (and how would I limit the transfer rate from within the app?)
Any and all suggestions are welcome.
Thanks
I have talked with Apple Developer support, and just FYI. You are only allowed to stream 1 MB per minute over the Cellular network. Support suggest that you test your app in the following way:
"The basic measurement methodology is to turn off all background updating (particularly Mail's automatic mail downloads and Calendar updates), reset the transfer statistics in "Settings:General:Usage:", and then launch your application. Let it run for a fixed amount of time (five minutes is reasonable), and then exit your application. Once you've finished the test, the numbers listed under "Cellular Network Data" in "Settings:General:Usage:" are what you should focus on reducing.
Using what I just described, I'd suggest 4.8 MB every 5 minutes as the guideline you use to ensure your application stays within our bandwidth requirements."
Hope that helps at least a little.
Have you considered HTTP Live Streaming? It's built into OS 3.0.
Basically, you split your media into small (say, 10 second) snippets and put it on a standard web-server. Then you create little text 'meta-descriptor' files in EXTM3U format that point out where the bits are. The interesting thing is that you can create multiple versions of each snippet at different bit-rates. So if your bandwidth is good, the iPhone player dynamically chooses the higher bit-rates but when it's low it automatically switches to the lower bit-rate version of the snippet. It does this on-the-fly to adapt to changing conditions.
So if you split your MP3 into multiple 10-second bits at say, 3 different bit-rates then when the user is connected through WiFi they get the high-quality stuff but if they're on 3G or EDGE they get progressively lower-quality (and smaller sized) content.
If this violates your downloadable media concept, then perhaps you can use the same trick and keep multiple size files for each connection type. Then if you're on WiFi (or get a fast turnaround on a heartbeat ping to the server) download the big file vs. medium or small size ones.
Here's a decent step-by-step on segmenting content. They focus on video but it should work with audio content as well.
I would suggest throttling the bandwidth on the network/http request when connected to cellular, and having no throttle on wifi.
A combo of using Reachability to detect the network status, and implementing your http request using CFNetwork with a sleep until the next second whenever you have already downloaded as much as allowed per second should get you there.
You should check out this project, either to use, or just to see an example of how to code this well:
http://allseeing-i.com/ASIHTTPRequest
The ASIHTTPRequest class implements this, using either the old or 2.0 version of Reachability, and also provides a class level throttle, so even if you have multiple concurrent downloads and uploads, so long as all of them go through ASIHTTPRequest, they will be properly taken together and throttled properly.
A bit more on how to use this here:
http://allseeing-i.com/ASIHTTPRequest/How-to-use#bandwidth_throttling
Lots of good stuff in this (and no, I am not the author of any of it).
On a more serious note, what is it trying to do? There are many markets for iPhone outside of the US which don't have good download rates for phones, nor are the download cap sizes good, so having an app do lots of downloading isn't a good thing.
Could you possibly drop the data rate on your mp3 or some such? Make it optional to do the downloading with a warning that it will use your download?
YOu could not download the mp3 unless you are on wireless, and inform them of that. If you the mp3 are too important, then just tell them it only works on wireless, or include a few mp3 on the device. But 30min of mp3 is ridiculous, that is about what, 30meg.... think about it, 30 meg is just too much.