Okay, so Apple apparently has this thing where if the app takes too long to load, iOS will automatically quit the app or something. So when I'm building my iPhone app, I have quite a few high resolution images, which take a while to load, and they never finish before the app is automatically killed. Can anyone help with this?
Thanks!
From the iPhone Application Programming Guide: "Initialization time is not the time to start loading large data structures that you do not intend to use right away ... If your application requires additional time at launch to load data from the network or do other tasks that might be slow, you should get your interface up and running first and then launch the slow task on a background thread."
As Alex said, I recommend you to load resources on a background thread. However, be careful to use UIKit on a background thread. For the most part, UIKit classes should be used only from an application’s main thread. You should use thread-safe API.
For example, UIImage +imageWithContentsOfFile: is thread-safe. UIImage +imageNamed: is not thread-safe.
(From Developer Forums thread)
which take a while to load ...
Not just app start up... If you want a responsive app, that app shouldn't do anything that takes more than a few dozens of milliseconds, synchronously, on the main UI thread or run loop.
Related
I am making an app, which needs to keep tracking user's location every time. It can also work in the background mode. The issue is When I use other apps for several times. The other app may cause lots of memory. My app sometimes be terminated by the system. There are no crash logs. So I want to know some reasons. Is there any way to avoid my app to be terminated? Very appreciate for your help.
You can't prevent the app the be terminated, but what can you do best to keep it alive is when it enters in background free as much memory as you can - cached images, files... Also stop any running timers, UI updates and everything time consuming. By following the MVC rules, the best implementation is to create a separate class (model) that's only responsible for location updates (with CLLocationManager inside, and the class implements its delegation methods). So the only thing in background you should do is collecting the location points received by the CLLocationManager and nothing else. Also implement the method -applicationWillTerminate in you AppDelegate. This method is called only when the app is in background and it's going to be terminated (either by the OS or the user) and inside persist the location points in CoreData for example or however you do it... I have such an approach and so far my app has lived for 24h (with charging of course) without being killed.
App running in the background depend upon memory usage, battery life etc.When there are many app running in the background, your app may get terminated.I do not think you can run your app permanently in background.
My app takes a long period of time during the startup, while the splash screen is shown. I assume that It is so due to the size of what the iOS has to load, including libraries. My question is, can I load those in the moment the user actually wants to use it, so it makes the startup time shorter?
Are there other ways to do it shorter?
Thanks a lot.
All 3rd party libraries are statically linked to your app. In theory you can lazy load only Apple's own weakly bound libraries. I am not aware how you can control this process on iOS. It's certainly possible on Mac.
sure you can as long as you don't need them directly.
LazyLoad is not limited to what you apply it too, for example if you have a huge Opengl scene you can chose not to laod its textures until the user actually click on the button you need.
The downside of this is that the waiting time to open whatever requires a lazyload will be moved further down the app (when the user wanted to play he will have a longer loading time).
What you could try is to launch Thread that handles the loading at startup and from the thread you do a setBooleanLibXFinishedLoading this way your app will only have to wait for all the booelan to be set to proceed.
This should reduce the apparent waiting time for the user while optimizing the time actually spend loading.
hope this helps
Jason
My app contains many graphics and sounds. it's actually running very well - only if I go back in my app after a long time my app stops responding for about 2-7sec
I release my Images and sound (and all the rest) as soon as possible to keep the apps memory consumption as low as possible
how can I fix it?
thanks in advance
Your best bet would be to spawn a background thread to load all the resources back into your app. At least that way the rest of the app should be responsive (save the elements you're loading).
A good place to start learning about using threads with iOS and Objective-C would be the Concurrency Programming Guide.
In my iPhone app I would like to run several queries when the
application is in background.
I already use ASIHttpRequest to make the queries, that works fine but
now I try to find a way to trigger them in background.
In the app delegate, I have added a call to the method making the request:
[self getItemsFromServer]
getItemsFromServer runs an asynchronous request (on the simulator I
saw the log of this methods once I get back the application to the
foreground).
How can I use some kind of timer to have this method ran every 10
minutes (I just need to run it 4 or 5 times, not each 10 minutes until
it goes back to foreground :-) )?
thanks a lot,
Best Regards,
Luc
iOS4 allows your app to run for X amount of time, granted that iOS4 grants you the time you request. Check out: Completing a Long-Running Task in the Background.
Specifically,
Any time before it is suspended, an application can call the beginBackgroundTaskWithExpirationHandler: method to ask the system for extra time to complete some long-running task in the background. If the request is granted, and if the application goes into the background while the task is in progress, the system lets the application run for an additional amount of time instead of suspending it
You could probably use Task Finishing to do that. In iOS you can mark a thread as finishing and give it a specific time to live. This would let you do a few more calls to your web server.
Have a look at Executing Code in the Background
Actually, you are specially not allowed to make general HTTP calls while in background. The only apps that can be active in the background are those that play audio, do location or are running VOIP calls. I believe Apple's whole philosophy with background is that apps shouldn't be doing 'work' other than these limited cases because there are limited resources available. THe suggested way to work around this is to use (ugh) notifications or just do a refresh when your application wakes up. The doc that willcodejavaforfood references explains this.
I'm writing an app with an image upload feature. Right now I'm using NSURL POST like: 125306.
When the app is closed as far as I can tell all of the uploads abort and the threads die. Is there
1) a way to make these upload threads persist when the app is no longer in the foreground?
2) an iPhone OS service that will accept requests to queue a job and run it in a mode managed by the OS?
EDIT: This is an old answer from 2009. Current iOS (2016) has background URL tasks. See NSURLSessionUploadTask.
Original answer follows:
You aren't allowed to run in the background on an iPhone (as per Apple's Guidelines). Your app will be rejected from the AppStore if you do.
As has been failry well documented, no background processes are allowed using the SDK.
As noted, you cannot have a background process - a good compromise would be to resize the photo down to a size that could be transferred in a reasonable amount of time (user configurable would be best), and display an activity indicator of some kind so the user would know the upload was in progress.
An even better solution would be the resize, along with a progress indicator giving the percentage currently uploaded - but that involves some custom low-level HTTP code.
After app suspending you only have ~10 mins to do the job.
You should make a background process thread when app is suspended.
And you have no garanties that os will keep app alive. It depends on process complexity.