I have made an app that runs in the background. The purpose is to intercept incoming calls. After a while Android kills the service/app if it's not "active" for a while. Any way to avoid this in basic4android?
Set the service to be a foreground service.
Run Service.StartForeground from the service module
When you are finished processing use:Service.StopForeground to stop the service from being a foreground service.
The easiest way to avoid this problem is to place a notification icon in the top bar. Android will not kill processes that have a notification icon unless the phone is running very short on memory.
However, you may want to make this icon an option to the user (default: on), because higher end phones won't kill processes unless they have a memory shortage anyway.
Unfortunately, I don't know how to implement this.
[edit]
You could also make the app do something completely pointless every 15 minutes, like set a useless variable. This would classify the application as active to the system. You'd still have to worry about low memory situations, though.
Related
I am developing an iphone application and I think that it's business logic requires a service to be always running in background.
The service needed is to get the acceleration of the device and notify or perform a certain action when that acceleration becomes a certain value.
Is that allowable in the Apple policies, or is there any idea about a solution?
What cydia development possibilities to help me ?
Dbramhall left out one important thing:
You can't guarantee that your app won't be killed, the OS can kill apps that are in the background at will if it requires more memory.
So if at all possible i wouldn't rely on making sure it can run its process in the background and before you ask "How can i stop this?". Well you shouldn't I've never tried it myself because i don't know the effects it has on the OS.
Also if you stop it from being killed in the Background, if it is going to be on the app store then it won't pass evaluation process, because it breaks the OS
Well, an application can run in the background and Apple perfectly accepts this however the user will obviously be be able to close the application (or should be able to) via the multi-tasking bar and this will end the application. Period.
Apple will not accept an application that runs constantly regardless of whether the user has is in background state as this drains the battery, heats the device etc. So an application can run in the background so long as the user can quit it when close it from the multi-tasking bar however it cannot continue to run after the user closed it via multi-tasking - if it does continue, Apple will reject the application.
Also, see 2.16 of the Apple Store review guidelines: https://developer.apple.com/appstore/resources/approval/guidelines.html#functionality
I am running my iPod touch application and then go in background and change the device language from Settings application and try to bring that application on foreground. My application gets restarted and I do not land on the screen where I left the application when I went into the background.
Is this because a KILL signal is sent by settings application when language was changed? Is it the desired behavior?
I wasn't aware the switching the language would cause apps to be terminated, but that's not shocking. It's a very straightforward way to get what the user wants. Your problem isn't the language change, though. The problem is that you're not responding correctly to a notification of termination. You can be terminated at any time when you're in the background, and it's your job to deal with it.
Your application delegate should implement applicationWillTerminate: (or you can observe UIApplicationWillTerminateNotification wherever it is convenient). When you receive this, you should save off sufficient information to get yourself back to where you were when you restart. As much as possible, you should make it look to the user that you did not terminate. The easiest place to save state is usually in NSUserDefaults, but you can use any mechanism you like.
Handling application restart is one of those things that separates excellent iOS applications from "good enough."
Suppose I have an iOS app that is actually running in the background (for one of several legal reasons, such as background audio, requested time, etc.). What things might cause the OS to close (kill) this app instead of just running or suspending it? How can I avoid them? How can I reliably trigger them (within this app) using public APIs?
Your app might be killed if it uses too much memory, if it does not call endBackgroundTask: when the expiration handler (specified when calling beginBackgroundTaskWithExpirationHandler:) is called, if the user explicitly kills it, if the app throws an exception, calls exit, triggers an EXC_BAD_ACCESS or other signal, and so on. There are probably other reasons, too.
To avoid these, don't use too much memory, call endBackgroundTask: when required, make an app that users won't want to kill, and don't throw exceptions, call exit, access invalid memory locations, and so on.
There isn't a way to reliably trigger "user explicitly kills the app". For the others, you could allocate tons of memory, refuse to call endBackgroundTask:, use [NSException raise:... format:...], call exit, or create random garbage pointers and follow them. You probably shouldn't actually do any of these, though.
I'm not sure what you're asking - it sounds like you want to be able to terminate other applications, which (thankfully) simply isn't possible on the iOS platform due to sandboxing, etc.
However, the most likely reason your own application will be killed whilst it's running in the background is if it's using a large amount of memory, etc. and doesn't respond to the didReceiveMemoryWarning calls by shedding resources that are no longer required.
In terms of automatically triggering these, the simplest way would be to use the "Simulate memory warning" option within the "Hardware" menu on the simulator.
I am trying to take advantage of iPhone 4 multitasking feature. I want to run app in background and frequently send http request to send/receive data, is it possible?
Surprisingly, there is actually very little time-slicing going on in the "multi-tasking" iOS 4.x. What goes on instead is really just application suspend / resume. When an application is sent to the background upon the user tapping the home button, it will stop getting execute cycles after a short while (*).
(*) There are a few exceptions. Applications which declare themselves as "VoIP providers", location-based apps, and music apps can get background execute cycles, presumably only though to perform those very specific operations in response to corresponding events (like a "significant change in location" occurring). Some apps apparently try to stretch the rules and find undocumented or not-strongly-documented techniques to continue getting background execute cycles.
And the "requested running time" that Undeadlegion mentioned is limited in duration.
The reality is that on iOS4, applications are not allowed to run continuously in the background.
#Undeadlegion has suggested a plausible way to achieve your goal. To be more clear, take a look at my previous answer to a similar question at SO, iphone - Connecting to server in background
It is possible to request running time while your app is backgrounded.
See Multitasking Developer's Guide
Although, depending on the intent of your http requests, push notifications may be a viable alternative.
This may be necessary because you aren't providing audio, voip, or location services, so your app can't run in the background indefinitely.
Ever since the first beta came out I’ve been trying to find out if “real” multitasking is possible — i.e. can you put a program in the background and have it hang on to a network connection indefinitely?
I’m thinking about IM or IRC apps, for example. I’ve compiled an app myself on iOS 4, and without changing a thing it appeared to stay running in the background, but for all I know it was just suspended to memory.
The docs say the best you can do is request up to 10 minutes, but in the developer presentation they showed off Skype sitting in the background and then notifying the user that a call was coming in. Does anyone know for sure how this all works?
It appears the answer is no. The API for Skype is a very special case, called the "voip" mode, and requires special behavior, such as marking the socket in use for VoIP.
You can receive alarm notifications in the background (such as time passed). The amount of time you are in the background running state is severely limited by the OS.
Android's background model is complete and in many ways much nicer.
Apple has a guide named "Supporting Multitasking In Your Applications" which you should be able to locate.
Apple's iOS 4 developer docs outline this all very clearly.
When your app is closed or switched away from, it is almost immediately "suspended", meaning the OS freezes the app's state. When the user switches back to your app, your code keeps running just where it kept off. You don't need to add any code to your app to do this, just compile it against OS 4.
The above is true in most cases. There are two reasons the "suspended" model may not apply:
1) If the device starts to run low on memory, the OS will start terminating suspended apps that haven't been switched to in a while, without warning. This is why it's in your best interest for your app to remember it's state as well, so if your app is terminated, then re-opened, the user doesn't really notice because it still returns to right where they left off.
2) Your app uses one of the "background" APIs. These are for audio playback, VoIP services, or location services. In this case, your app is allowed to continue running in the background but only has access to those APIs. Additionally, your app can designate certain long-running tasks as "background tasks" that need to be completed before the app is suspended or terminated, like uploading pictures to Flickr or rendering a video, etc.
The "background task" method doesn't cover pinging servers indefinitely, as there is a time limit for the task, after which it will be forcibly halted. Apps that need that sort of functionality are expected to implement push notifications, just as before.
That should clear this up. All in all I think it's a pretty elegant solution to multitasking on a mobile device.
iOS 4 applications can either be running or suspended. The operating system will try to keep as many requested applications as possible in memory, while all other applications are suspended.
Applications that run in the background can access features such as navigation, audio, and VOIP (but NOT instant messaging). So it looks like you might be out of luck.
-- PC World Multitasking on Apples iPhone 4
It is possible for apps to request background time. Read the docs. I would say it iOS is "controlled multitasking".
You can create a long running background task, I believe these can include networking features. Just have to set the background task flag on the work block.
https://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/BackgroundExecution/BackgroundExecution.html
the OS can limit exactly how much time you get though... it will tell you when your time is up giving you a chance to cleanup nicely.
iOS 4 has "real" multitasking to some extend. There are two things to consider:
The UI event loop is single tasking. So only the front app executes on the UI event loop. Not a big deal: detach your main code form the UI event loop (maybe you need to redesign your app).
The OS "may" terminate your app if some criteria are met (e.g. low memory).
Currently one of these criteria is that execution time is limited to 10 minutes (real time not cpu time). However I expect this to change and see better criteria for background app termination (I hope to).
Apart from this you can have timers (event loops) in background.
There is no real multitasking in iOS 4.2 even. because apps will only be allowed to finish the task related to states..for small interval of time and then it will be in suspended state.. If you will set background task for long interval of time then... it will behave unexpectedly like no method will be called when you will try to run the app from anywhere..
You may be interested in this blog post that outlines how "multitasking" works in systems such as iPhone OS 4 and Android.
in fact u can do this, although it's not allowed by Apple. u gotta set up a toolchain in ur mac and use some unofficial SDK...
check http://code.google.com/p/iphone-backgrounder/ for more information
You should use the Push Notifications framework for the feature set you are creating!