How many issues need to be considered carefully if a large of content need to be downloaded in an iOS app ?
Here are my known issues:
Network , No limits for Wifi, but Apple has limit policy for cellular network. enter link description here
Background execution. Apple introduced multitasking for several cases, but no for downloading large content background. Here is a good analysis.
Newsstand provides good solution for this. But does that mean you need follow the Newsstand approach ? We do not want to build an newsstand type app.
What else issues do you think ? and what is the best solution for this sort of problem ?
I would lazy load only data as needed. When the user requests an area load revenant data.
If you want to preload do it in the background. I have seen 1.6Gb apps with lots of videos, embedded in main bundle, but that was for sales app that needed to have all videos ready to go and could not assume any active network connection.
Download the data you need in a background thread while your app is running. If your app is terminated or suspended before you get all the data, resume where you left off the next time the app is running. There are a number of ways that you can do that; one good one is to break your data up into smaller chunks that can be downloaded sequentially.
Related
This might be asking for the moon but here goes...
Is it possible to have an iOS app receive data and then forward it all while running in the background?
We're a restaurant currently using an ordering system that uses a main iPad as the till, with a second iPad in the kitchen to receive orders, and another third iPad used by the servers to take orders. Orders are sent to the main till which relays orders to the kitchen.
Works great... Unless someone switches app on the main till iPad to our other (necessary) hosting app, then all hell breaks loose and all orders stop getting sent.
Developer (small team) has told us it's impossible to solve but I have done some digging into recent Apple APIs that allow simple tasks to run in the background and have seen a few promising options, or perhaps it's possible via the External Accessory Framework, or even syncing via iCloud? A question for the more knowledgable than me, but is there currently a workaround to solve this that I could suggest or are they right in that it's currently impossible in iOS?
Yes there are ways to have an app in the background receive data, generally using either:
beginBackgroundTaskWithName:expirationHandler:
or
beginBackgroundTaskWithExpirationHandler:
Take a look at the Background Execution section in the documentation for more info...
I work as a software developer, but I am absolutely new to Apple in general. We have the following case in a project, and we have not been able to figure out a solution for it, I would really appreciate some advise to find a solution (or drop the case if not possible)
A (potential) customer with multiple retail stores is interested in having a very simple app to display some content (this could an image or html, nothing too complicated) and periodically update this content from a server (this requirement is important). So it is very simple case, to use the device screen as advertising space
But here is the catch, users should be able to go out of this app and check out the device's system and other apps, and then the content should come back on the foreground when the device is idle. So basically we need something like a screensaver app that fetches the content (images) from a server and keeps them updated.
We have been looking at the guided access mode, but we are not sure it fulfills the requirements, because of the following issues
- Allowing the user to check out the device system and other apps. As far as we understood guided access restricts the device to one app.
- Re-launch the app (or bring it to the foreground) when the device has been idle for a period of time.
Note that we should account for a variety of devices (iPhone and iPads) with different OS versions
I appreciate your help and ideas. Thanks.
Apple does not allow apps to run continuously in the background except for a small limited group of exceptions. (music playing apps, for example.)
It's possible to set up your app to pretend to be a music playing app, and stay running in the background, but that means you will not be allowed on the app store.
Your client may be able to use the enterprise program to create apps for use in their retail stores. Enterprise apps don't have to go through the app store approval process.
I did this for a client recently (for an enterprise app.) As I recall I would have the app request background processing as soon as it moved to the background, and when it was notified that it's background time was ending, I would play a short "silence" sound and request another block of background time. Unfortunately it was work for hire and the contract ended, so I did not retain the source code.
In the Apple documentation about 'Fetching Small Amounts of Content Opportunistically' (https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html#//apple_ref/doc/uid/TP40007072-CH4-SW56) the following is written:
Apps that download small amounts of content quickly, and accurately
reflect when they had content available to download, are more likely
to receive execution time in the future than apps that take a long
time to download their content or that claim content was available but
then do not download anything.
When downloading any content, it is recommended that you use the
NSURLSession class to initiate and manage your downloads.
How does iOS decide whether there was something downloaded or not, if I am not using NSURLSession? The communication between my app and our backend happens over XMPP. I'm afraid that maybe iOS would think that nothing wasn't downloaded and limit execution time in the future, even if we did retrieve content over the XMPP socket.
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.
In the iPhone apps, network traffic via cellular network usually will cost users money by sending network request etc, so we need try to avoid such architecture or technical solutions for the apps to avoid cost much money for users.
Does that make sense ? And also try to look for any policy from Apple about this, any clues ?
As I know Apple push notification should be better than such polling approach which need send request to server periodically.
What are the alternative solutions in such cases ?
You could test to see if the user if on Wifi or the cellular network (use Reachability for this). If they are on the cellular network warn them that you are going to be using a lot of data.
It's also important to only load data when necessary. Don't download all your data when the app loads. Do it when the view appears (and do it in a background thread to prevent the UI locking).
You should optimise any data you will be downloading. e.g. if you are going to download a load of images or audio files download a compressed (zip) file containing them and then unzip it on the device.