I am trying to use CTCallCenter in a background application to receive CTCallCenter events. Is this possible?
Yes and No.... It's complicated.
If your application is running a background task, then yes you will get events in the background. The problem is that background task will timeout in ten minutes (currently). So you can only get call events for the first ten minutes after going into the background....
Related
I wanted to know how to make a service like WhatsApp, the service won't die after 1 minute, it will display a notification that is updated every 12 hours or every 1 minute (the user chooses it in the app).
How can I make the service where the message can be rejected, and the service will not die but will display another notification after a while?
I tried to use foreground. Is it the right way? I'm not sure, because according to the developers site, the foreground must display notifications all the time. I don't want that.
What should I do? Thank you for any help
I am new to mobile website development, and facing this issue where I want to refresh data on the website in every 30 sec which is invoked from the client side and server provides the data in response. Problem is when I close the browser or when the browser goes in background it stops working. Is there any thing we can do to make this thing possible?
Have a look at the Android Developers - Processes and Threads guide. You'll get a deeper introduction to how process life-cycles work and what the difference is between the states for background- and foreground processes.
You could embed your web app in a WebView. This way you could deal with the closing browser case: you could provide a means to "exit" the app that involves closing only your container activity. That way the timers you have registered in javascript will still be running in the 'WebViewCoreThread'. This is an undesirable behavior and a source of problems, but you can take advantage of it if you want (just make sure you don't run UI-related code there). I've never tested this in Kit Kat (which uses a different WebView based on Chrome) but works for previous versions, as I described here.
Now the user can always close any app. Even without user interaction, the OS can kill your app on low memory. So just give up on long-running apps that never end, because the OS is designed in such a way this is simply not possible.
You could go native and schedule Alarms using the AlarmManager.
Just checked this out on the Android KitKat WebView and as per Mister Smith's comments the javascript will continue executing in the background until the Activity is killed off:
Just tested with this running in a WebView:
http://jsbin.com/EwEjIyaY/3/edit
My gut instinct is that if the user has moved your application into the background, there seems little value in performing updates every 30 seconds, it makes more sense to just start updating again once the user opens the device up and cache what information you currently have available to you.
As far as Chrome for Android goes the same is happening, as Chrome falls into the background the javascript is still running.
If you are experiencing different behaviour then what exactly are you seeing and can you give us an example?
Team,
i'm developing an iOS application.
My requirement is to query for specific news service(REST API) in regular time interval.I wanted query the service twice for a day and update my sqllite db, even the applciation is in background state. My UI will be updated with data fetched from sqllite db, while the application is in foreground.
My question are,
Is it possible to run NSTimer in background continuously? if yes, is
there any maximum time limit for timer to run in background (say 10
mins or 60 mins)?
Is it possible to send request to download a file using
NSUrlConnection and save the file to documents directory, when the
application is in background ?
Your suggestions will be much helpful for my project design.
Thanks in advance.
What you are aiming for cannot be achieved on iOS:
Arbitrary apps cannot run in the background for an arbitrary amount of time.
You can try to mitigate some of this by using local notifications instead of NSTimer to schedule your updating. This will, however, only buy you a very limited amount of time to do your networking.
The question you should ask yourself at this point probably is:
If you are only updating twice a day, how bad can it be to initiate the download when your app becomes active?
Answering my own question, so that it will be helpful for others.
Ques 1: Is it possible to run NSTimer in background continuously?
Ans: Nstimer will not run while the application in background state. So there is no point of maximum allowed timer value in background. If the application enters into background while there is an ongoing process, [UIApplication beginBackgroundTaskWithExpirationHandler:] can be used to complete the ongoing process. The maximum time allowed by the OS with this handler is 10mins.
Ques 2: Is it possible to send request to download a file using NSUrlConnection and save the file to documents directory, when the application is in background ?
Ans:
Below given information is from Apple documentation. Detail info is found here
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background,such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that supportVoice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Info about running background process using VOiP type application can be found here
We are having a web application build using asp.net 3.5 & SQL server as database which is quite big and used by around 300 super users for managing around 5000 staffs.
Now we are implementing SMS functionality into the application which means the users will be able to send and receive SMS. Every two minute the SMS server of the third party is pinged to check whether there are any new messages. Also SMS are hold in queue and send every time interval of 15 to 30 minutes.
I want this checking and sending process to run in the background of the application all the time, even if the user closes the browser window.
I need some advice on how do I do this?
Will using thread will achieve this or do I need to create a windows service for it or are there any other options?
More information:
I want to execute a task in a timer, what will happen if I close the browser window, the task wont be completed isn't it so.
For example I am saving 10 records to the database in a time interval of 5 minutes, which means every 5 minutes when the timer tick event fires, a record is inserted into the database.
How do I run this task if I close the browser window?
I tried looking at windows service but how do I pass a generic collection of data to it for processing.
There really is no thread or service choice, a service can (and usually is!) multi threaded, a thread can start a service.
There are three basic choices you can:-
Somehow start another thread running when a user logs in -- this is probably a very poor choice for what you want, as you cannot really keep it running once the user session is lost.
Write a fully fledged windows service which is starts on OS startup and continues running unitl the server is shutdown. You can make this dependant on the SQLserver service, so it starts after the DB is available. This is the "best" solution but may be overkill for your purposes. Aslo you need to know the services API to write it properly as you need to respond correctly to shutdown and status requests.
You can schedule your task periodically using either the Windows schedular, or, preferably the schedular which is built in to SQLServer, I think this would be the most suitable option for your needs.
Distinguish between what the browser is doing and what's happening server-side.
Your Web App is sitting server-side waiting for requests from whatever browsers may be running, and servicing those requests, in servicing those requests I guess it may well put messages on a queue and have a look in a database for any new messages.
You want the daemon processor, which talks to the third-party SMS, to be triggered by time rather than by browser function. Either of your suggestions would work:
A competely independent service could run and work against the queues and database.
Your web app, which I assume is already a service, could spawn a thread
In either case we have a few technical questions of avoiding any race conditions between the browser-request processing and the daemon - but databases and queueing systems can deal with that.
So I would decide between stand-alone daemon and background thread like this:
Which is easier to implement? I'm a Java EE developer, I know in my app server I have an API for specifying code to be run according to a timer, the API deals with the threading issues. So for me that's very easy. I don't know what you have available. Timers are not quite as trivial as they may appear - so having a reliable API is beneficial. If this was a more complex requirement, where the daemon code were gnarly and might possibly interfere with the WebApp code then I might prefer to keep it conspicuously separate.
Which is easier to deploy and administer? Deploy separate Web App and daemon, or deploy one thing. In the Java EE world we could have a single Enterprise Application with all the code, so that's a single thing to deploy, start and control.
One other thing to consider: Scaling and Resilience. You might choose to have more than one copy of your web app running, either to provide fail-over capabilities or just because you need the extra power. In which case how many daemons would you have? Would it be a problem to have two daemons running? You might need some extra code to mediate between two daemons, for example log in the database the time of last work, each daemon can say "Oh, my buddy balready did the 10:30 job, I'll go back to sleep"
I am using the 'location' UIBackgroundMode to receive GPS background updates when the user presses the Home button. As a result, if the app is left in background mode overnight, the battery is consistently dead the next morning. I have told the locationManager to stopUpdatingLocation, but to no effect.
I understand Apple doesn't want developers to use exit - in fact it seems to have little effect on the app other than to take it to the background - but I can't afford to have the battery die if the user doesn't end the app.
Any suggestions?
Maybe you could register for a local notification that informs the user they should open the app to stop location tracking? It's not very elegant of course, it seems Apple should allow the developer to register for location updates for a specified length of time, maybe you could submit a feature request for that. I think Loopt monitors for 24 hours and then quits, maybe you could research into how they made it stop after 24 hours. I wish I could help more but I haven't messed with the location framework at all.
You could use a timer and/or background task, which would run after a set amount of idle time, and try to turn off the GPS then. So you can still have location tracking in the background of your app, but after 10-20 minutes, it turns off.